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=4&rev2=5 Yes. - 4.2.4 In the absence of special knowledge of the application or domain, LDPR clients must assume that any LDPR may have multiple values for rdf:type. + * 4.2.4 In the absence of special knowledge of the application or domain, LDPR clients must assume that any LDPR may have multiple values for rdf:type. Yes. (For the limited code where clerezza acts as client) - 4.2.5 In the absence of special knowledge of the application or domain, LDPR clients must assume that the rdf:type values of a given LDPR may change over time. + * 4.2.5 In the absence of special knowledge of the application or domain, LDPR clients must assume that the rdf:type values of a given LDPR may change over time. Partially. DbPedia client makes no assumption on persistence but Resource providers doesn't update. + + * 4.4.1 If HTTP PUT is performed on an existing resource, LDPR servers must replace the entire persistent state of the identified resource with the entity representation in the body of the request. The only recognized exception are the properties dcterms:modified and dcterms:creator that are never under client control - LDPR servers must ignore any values of these properties that are provided by the client. Any LDPR servers that wish to support a more sophisticated merge of data provided by the client with existing state stored on the server for a resource must use HTTP PATCH, not HTTP PUT. + + [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 + + * 4.4.3 LDPR clients should always assume that the set of predicates for a resource of a particular type at an arbitrary server is open in the sense that different resources of the same type may not all have the same set of predicates in its triples, and the set of predicates that are used in the state of a resource is not limited to any pre-defined set. + + Yes. For thelimited number of Clerezza modules that act as client. + + * 4.4.4 LDPR clients should assume that a LDPR server could discard triples whose predicates the server does not recognize or otherwise chooses not to persist. In other words, LDPR servers may restrict themselves to a known set of predicates, but LDPR clients must not restrict themselves to a known set of predicates when their intent is to perform a later HTTP PUT to update the resource. + + 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) + + * 4.4.6 LDPR servers may choose to allow the creation of new resources using HTTP PUT. + + [SPEC: should probably be LDPR instead of Resource] + + * 4.4.7 LDPR servers should allow clients to update resources without requiring detailed knowledge of server-specific constraints. It is common for LDPR servers to put restrictions on representations – for example, the range of rdf:type, datatypes of predicates and number of occurrences of predicates in triples, but servers should minimize those restrictions. In other words, LDPR servers need to enable simple modification of LDPRs. Enforcement of more complex constraints will greatly restrict the types of clients that can modify resources. For some server applications, excessive constraints on modification of resources may be required. + + Yes, Clerezza poses no restriction at all, arbitrary triples can be added + + * 4.5.1 LDPR servers must remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI must result in a 404 (Not found) or 410 (Gone) status code, until another resource is created or associated with the same Request-URI. + + No. DELETE is not supported + + * 4.5.2 LDPR servers may alter the state of other resources as a result of an HTTP DELETE request. For example, it is acceptable for the server to remove triples from other resources whose subject or object is the deleted resource. It is also acceptable and common for LDPR servers to not do this – behavior is server application specific. + + N/A + + * 4.6.1 LDPR servers must support the HTTP HEAD method. + + Yes but not very smart (same processing as for GET. + + * 4.6.2 LDPR servers must indicate their support for HTTP Methods by responding to a HTTP HEAD request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header “Allow”. + + ? + + + * 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 + + * 4.7.2 LDPR servers should allow clients to update resources without requiring detailed knowledge of server-specific constraints. It is common for LDPR servers to put restrictions on representations – for example, the range of rdf:type, datatypes of predicates and number of occurrences of predicates in triples – but server enforcement of detailed, domain-specific constraints will greatly restrict the types of clients who can update resources. + + N/A + + + [SPEC: wondering that section 5 is non normative, despite the many MUST and SHOULD statements] +
