A page to describe in how far Clerrezza complias with W3C LDP best practices for a read-write Linked Data architecture.
Looking at the various requirements ("Yes" means that Clerrezza satisfies all should and must level requirementst)
4.1.1 LDPR servers must at least be HTTP/1.1 conformant servers \[HTTP11\]. \\ |
Yes.
Yes. All resources in Clerezza can directly be dereferenced in all supported RDF formats with the excepion of binary resources where the RDF description can be got at alternative URI. The reason for this is that system should behave consistently when an RDF and a non RDF file is uploaded so this are treated non-LDPR resources.
Yes.
There's currently no support for the same resource to be retrieved from multiple URIs.
4.1.5 LDPR predicates should use standard vocabularies such as Dublin Core \[DC-TERMS\], RDF \[RDF-PRIMER\] and RDF Schema \[RDF-SCHEMA\], whenever possible. LDPRs should reuse existing vocabularies instead of creating their own duplicate vocabulary terms. \\ |
Yes. Clerezza uses mostly existing vocabularies like FOAF and SIOC for permissions.
Uh? What's the difference to 4.1.5?
4.1.6.1 LDPRs must use the predicate rdf:type to represent the concept of type. The use of non-standard type predicates, as well as dcterms:type, is discouraged. \[DC-RDF\] \\ |
Yes.
Partially. Resources generated by Clerezza conform to the requirement but its possible to insert arbitrary data.
The description of any named resource in the content graph is served if a get request for that resource is sent against the clerezza instance and the URI is not handled by a dedicated Jax-RS resource and the resource if not of a type for which a Typehandler is registered. When addin triples to the content graph there's no mechanism enforcing that all named resources have an RDF type statement.
4.1.8 Predicate URIs used in LDPR representations should be HTTP URLs. These predicate URIs must identify LDPRs whose representations are retrievable. LDPR servers should provide an RDF Schema \[RDF-SCHEMA\] representation of these predicates. \\ |
Partially. Triples generated by Clerezza should conform to the requirement but its possible to insert arbitrary data.
As arbitrary triples can be uploaded there's no mechanism enforcing meaningfull dereferenceability of the type statements.
4.1.9 LDPR representations must use only the following standard datatypes. RDF does not by itself define datatypes to be used for literal property values, therefore a set of standard datatypes based on \[XMLSCHEMA11-2\] and \[RDF-PRIMER\] are to be used: xsd types + rdf-xml \\ |
Partially. With the exception of the [WebId] module \[verify\] literals generated by Clerezza conform to the requirement but its possible to insert arbitrary data. |
\[REC!\] This requirements seems to imply that the properties have a preferred direction, which contradict http://dig.csail.mit.edu/breadcrumbs/node/72. Clerezza does not currently enforce a link it is possible to add to the contentgraph a triple with a subject IRI not otherwise used and a literal object. The resources generated by clerezza do have at least a type statement, would this qualify as link? |
4.1.11 LDPR servers may support additional standard representations. These could be other RDF formats, like N3 or NTriples, but non-RDF formats like HTML \[HTML401\] and JSON \[RFC4627\] would be likely be common. \\ |
Yes.
4.1.12 LDPRs may be created, updated and deleted using methods not defined in this document, for example through application-specific means, SPARQL UPDATE, etc. \[SPARQL-UPDATE\] \\ |
Yes.
No.
Yes
4.2.2 LDPR servers must provide an text/turtle representation of the requested LDPR.\[TURTLE\] \\ |
Yes
4.2.3 LDPR servers should provide a application/rdf+xml representation of the requested LDPR.\[RDF-SYNTAX\] \\ |
Yes.
Yes. (For the limited code where clerezza acts as client)
Partially. DbPedia client makes no assumption on persistence but Resource providers doesn't update.
\[SPEC: This should probably say LPDR instead of resource in the first sentence\]. No. Clerezza will treat any entity body of a PUT request as a binary resource, that will be stored encoded in a literal of the content graph so that subsequent get request will return the same entity body as in the put request. |
4.4.2 LDPR clients should use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDPR servers should require the HTTP If-Match header and HTTP ETags to detect collisions. LDPR servers must respond with status code 412 (Condition Failed) if ETags fail to match if there are no other errors with the request. \[HTTP11\] \\ |
No
Yes. For thelimited number of Clerezza modules that act as client.
N/A.
4.4.5 A LDPR client must preserve all triples retrieved using HTTP GET that it doesn’t change whether it understands the predicates or not, when its intent is to perform an update using HTTP PUT. The use of HTTP PATCH instead of HTTP PUT for update avoids this burden for clients \[RFC5789\]. \\ |
N/A. A client that could use this principle is the javascript Discobit editor, it does not currently use PUT (but a revoke/assert via post)
\[SPEC: should probably be LDPR instead of Resource\] |
Yes, Clerezza poses no restriction at all, arbitrary triples can be added
No. DELETE is not supported
N/A
Yes but not very smart (same processing as for GET.
?
4.7.1 LDPR servers may implement HTTP PATCH to allow modifications, especially partial replacement, of their resources. \[RFC5789\] No minimal set of patch document formats is mandated by this document. \\ |
Not implemented
N/A
\[SPEC: wondering that section 5 is non normative, despite the many MUST and SHOULD statements\] |
Sections 5.3-5.9 are normative.