When it comes to RDF, validation means several different things. There is syntactical validation (and the triple you included in your message is syntactically correct). Trellis currently does syntactic validation: if you POST syntactically invalid RDF, the request is rejected with a 400 Bad Request. There is also SHACL and ShEx validation that work on the semantics of the RDF. Trellis does not implement this, but adding this is possible; more on that below.
For syntactically valid RDF, Trellis will accept whatever triples are sent by a client and persist those. So, if a client POSTs syntactically valid (but semantically invalid, as in your case), Trellis generally won't do any manipulation, checking or validation on those triples. And as a note, Turtle prefixes are not required to end in a / or # character; the Turtle grammar
for prefixes requires only an IRIREF
. Though you are correct, it is certainly common for prefix definitions to end in a / or # (OTOH, I know of certain patterns where that is not the case, especially for referencing the 'current document' as in @prefix : <> .
That said, there is a mechanism for validating the incoming RDF in Trellis. In fact, there is some minimal validation that happens to RDF, but only based on what LDP formally requires (e.g. ldp:membershipResource must point to an in-domain IRI -- it can't be a literal or any arbitrary IRI; ldp:hasMemberRelation must point to an IRI, which can't be ldp:contains; there are a few such rules). Those validation rules are all part of a class that implements Trellis' ConstraintService API
. The Trellis code is structured in such a way that any number of ConstraintService implementations can be injected into the runtime. The deployable artifacts that you see with Trellis releases contain only the trellis-constraint-rules
artifact (i.e. the minimal LDP validation rules), but if one wished to do any sort of more complex validation (including SHACL or ShEx), that would be the place to do it. That would also mean writing some Java code and building your own deployable artifact, though technically, you could just drop a jar file into the classpath of your deployed Trellis and it should work.
I would point out, though, that issue that motivated this comment (a missing trailing slash in a prefix) is actually rather tricky. The IRI that is produced is a valid IRI and hence it is syntactically valid Turtle, and so the only real way to catch it would be to have a SHACL/ShEx rule that explicitly requires the foaf:name triple in the resource; your resource does not contain foaf:name and so the SHACL/ShEx validator would produce an error.
Hope that helps,