Dear Wiki user, You have subscribed to a wiki page or wiki category on "Clerezza Wiki" for change notification.
The "LinkedDataPlatform" page has been changed by RetoBachmannGmuer: http://wiki.apache.org/clerezza/LinkedDataPlatform New page: A page to describe in how far Clerrezza complias with W3C [[http://www.w3.org/TR/ldp/|LDP]] best practices for a read-write Linked Data architecture. Looking at the various requirements * 4.1.1 LDPR servers must at least be HTTP/1.1 conformant servers [HTTP11]. Yes. * 4.1.2 LDPR servers must provide an RDF representation for LDPRs. The subject is typically the LDPR itself. 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. * 4.1.3 LDPR servers may host a mixture of LDPRs and non-LDPRs. For example, it is common for LDPR servers to need to host binary or text resources that do not have useful RDF representations. Yes. * 4.1.4 Clients can access a LDPR using multiple URLs, for example when DNS aliasing is used. A LDPR server must respond to each of those requests using a single consistent URL, a canonical URL, for the LDPR which may be found in the response's Location header and potentially also in the representation of the LDPR. Clients should use that canonical URL to identify the LDPR. 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. * 4.1.6 LDPR predicates must use well-known RDF vocabularies as defined in section 4.8 Common Properties wherever a predicate’s meaning matches one of them. 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. * 4.1.7 LDPR representations should have at least one rdf:type set explicitly. This makes the representations much more useful to client applications that don’t support inferencing. 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. As arbitrary triples can be uploaded there's no mechanism enforcing meaningfull dereferenceability of the type statements.
