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?action=diff&rev1=3&rev2=4 Comment: made bullets 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]. + * 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. + * 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. + * 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. + * 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. + * 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. + * 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] + * 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. + * 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. 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. + * 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 + * 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. - * 4.1.10 LDPRs must use at least one RDF triple to represent a link (relationship) to another resource. In other words, having the source resource’s URI as the subject and the target resource’s URI as the object of the triple represent the link (relationship) is enough and does not require the creation of an intermediate link resource to describe the relationship. + * 4.1.10 LDPRs must use at least one RDF triple to represent a link (relationship) to another resource. In other words, having the source resource’s URI as the subject and the target resource’s URI as the object of the triple represent the link (relationship) is enough and does not require the creation of an intermediate link resource to describe the relationship. [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. + * 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] + * 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. - * 4.1.13 LDPR server responses must contain accurate response ETag header values. + * 4.1.13 LDPR server responses must contain accurate response ETag header values. No. - * 4.2.1 LDPR servers must support the HTTP GET Method for LDPRs. + * 4.2.1 LDPR servers must support the HTTP GET Method for LDPRs. Yes - * 4.2.2 LDPR servers must provide an text/turtle representation of the requested LDPR.[TURTLE] + * 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] + * 4.2.3 LDPR servers should provide a application/rdf+xml representation of the requested LDPR.[RDF-SYNTAX] Yes.
