Edit comment LC-2914 for Linked Data Platform (LDP) Working Group

Quick access to LC-2914 LC-2915 LC-2923 LC-2924 LC-2925 LC-2926 LC-2927 LC-2928 LC-2929 LC-2930 LC-2931 LC-2932 LC-2933 LC-2934 LC-2935 LC-2936

Comment LC-2914

Comment Shortname:

Commenter: Reto Gmür <reto@apache.org>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeLinked Data Platform 1.0 W3C Last Call Working Draft 11 M... Linked Data Platform 1.0 W3C Last Call Working Draft 11 Ma... Linked Data Platform 1.0 W3C Last Call Working Draft 11 March 2014 Abstract This document describes a set of best practices an... Abstract Status of This Document This section describes the status o... Status of This Document 5 February 2004 W3C Patent Policy Table of Contents 1. Introduction 2. Terminology 2.1 Conv... Table of Contents 1. Introduction 2. Terminology 2.1 Conventions Used in Thi... 1. Introduction This section is non-normative. This specifi... 1. Introduction 2. Terminology Terminology is based on W3C's Architecture o... 2. Terminology Linked Data Platform Resource Linked Data Platform RDF Source Linked Data Platform Non-RDF Source Linked Data Platform Container Linked Data Platform Basic Container Linked Data Platform Direct Container Linked Data Platform Indirect Container Membership Membership triples Membership predicate Containment Containment triples Empty-container triples 2.1 Conventions Used in This Document The namespace for LDP... 2.1 Conventions Used in This Document 3. Conformance As well as sections marked as non-normative,... 3. Conformance LDP client LDP server 4. Linked Data Platform Resources 4.1 Introduction This se... 4. Linked Data Platform Resources 4.1 Introduction This section is non-normative. Linked Data... 4.1 Introduction LDPRs Fig. 1 Samples of different types of LDPRs Fig. 2 Class relationship of types of Linked Data Platform... 4.2 Resource 4.2.1 General 4.2.1.1 LDP servers MUST at le... 4.2 Resource 4.2.1 General 4.2.1.1 LDP servers MUST at least be HTTP/1.... 4.2.1 General 4.2.1.1 LDP servers MUST at least be HTTP/1.1 conformant se... 4.2.1.1 LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]. 4.2.1.2 LDP servers MAY host a mixture of LDPRs, LDP-RSs an... 4.2.1.2 LDP servers MAY host a mixture of LDPRs, LDP-RSs and LDP-NRs. For example, it is common for LDP servers to need to host binary or text resources that do not have useful RDF representations. 4.2.1.3 LDP server responses MUST use entity tags (either w... 4.2.1.3 LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values. 4.2.1.4 LDP servers exposing LDPRs MUST advertise their LDP... 4.2.1.4 LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPR 4.2.1.5 LDP servers MUST assign the default base-URI for [R... 4.2.1.5 LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource. 4.2.1.6 LDP servers MUST publish any constraints on LDP cli... 4.2.1.6 LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints. For example, a serv 4.2.2 HTTP GET 4.2.2.1 LDP servers MUST support the HTTP G... 4.2.2 HTTP GET 4.2.2.1 LDP servers MUST support the HTTP GET Method for LD... 4.2.2.1 LDP servers MUST support the HTTP GET Method for LDPRs. 4.2.2.2 LDP servers MUST support the HTTP response headers... 4.2.2.2 LDP servers MUST support the HTTP response headers defined in section 4.2.8 HTTP OPTIONS. 4.2.3 HTTP POST Per [HTTP11], this HTTP method is optional... 4.2.3 HTTP POST 4.2.4 HTTP PUT Per [HTTP11], this HTTP method is optional a... 4.2.4 HTTP PUT 4.2.4.1 If a HTTP PUT is accepted on an existing resource,... 4.2.4.1 If a HTTP PUT is accepted on an existing resource, LDP servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request. LDP servers MAY ignore server managed properties such as 4.2.4.2 LDP servers SHOULD allow clients to update resource... 4.2.4.2 LDP servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs. 4.2.4.3 If an otherwise valid HTTP PUT request is received... 4.2.4.3 If an otherwise valid HTTP PUT request is received that attempts to change properties the server does not allow clients to modify, LDP servers MUST respond with a 4xx range status code (typically 409 Conflict). LDP servers SHOULD provide a corresp 4.2.4.4 If an otherwise valid HTTP PUT request is received... 4.2.4.4 If an otherwise valid HTTP PUT request is received that contains properties the server chooses not to persist, e.g. unknown content, LDP servers MUST respond with an appropriate 4xx range status code [HTTP11]. LDP servers SHOULD provide a correspo 4.2.4.5 LDP clients SHOULD use the HTTP If-Match header and... 4.2.4.5 LDP 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. LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detec 4.2.4.6 LDP servers MAY choose to allow the creation of new... 4.2.4.6 LDP servers MAY choose to allow the creation of new resources using HTTP PUT. 4.2.5 HTTP DELETE Per [HTTP11], this HTTP method is optiona... 4.2.5 HTTP DELETE 4.2.6 HTTP HEAD Note that certain LDP mechanisms rely on HT... 4.2.6 HTTP HEAD 4.2.6.1 LDP servers MUST support the HTTP HEAD method. 4.2.6.1 LDP servers MUST support the HTTP HEAD method. 4.2.7 HTTP PATCH Per [RFC5789], this HTTP method is optiona... 4.2.7 HTTP PATCH 4.2.7.1 LDP servers that support PATCH MUST include an Acce... 4.2.7.1 LDP servers that support PATCH MUST include an Accept-Patch HTTP response header [RFC5789] on HTTP OPTIONS requests, listing patch document media type(s) supported by the server. 4.2.8 HTTP OPTIONS This specification imposes the following... 4.2.8 HTTP OPTIONS 4.2.8.1 LDP servers MUST support the HTTP OPTIONS method. 4.2.8.1 LDP servers MUST support the HTTP OPTIONS method. 4.2.8.2 LDP servers MUST indicate their support for HTTP Me... 4.2.8.2 LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow. 4.3 RDF Source The following section contains normative cla... 4.3 RDF Source 4.3.1 General 4.3.1.1 Each LDP RDF Source MUST also be a c... 4.3.1 General 4.3.1.1 Each LDP RDF Source MUST also be a conforming LDP R... 4.3.1.1 Each LDP RDF Source MUST also be a conforming LDP Resource in section 4.2 Resource along the following restrictions in this section. LDP clients MAY infer the following triple: whose subject is ldp:RDFSource, whose predicate is rdfs:subClassOf, an 4.3.1.2 LDP-RSs representations SHOULD have at least one rd... 4.3.1.2 LDP-RSs 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.3.1.3 The representation of an LDP-RS MAY have an rdf:typ... 4.3.1.3 The representation of an LDP-RS MAY have an rdf:type of only one of ldp:RDFSource for Linked Data Platform RDF Source. 4.3.1.4 LDP servers MUST provide an RDF representation for... 4.3.1.4 LDP servers MUST provide an RDF representation for LDP-RSs. The HTTP Request-URI of the LDP-RS is typically the subject of most triples in the response. 4.3.1.5 LDP-RSs SHOULD reuse existing vocabularies instead... 4.3.1.5 LDP-RSs SHOULD reuse existing vocabularies instead of creating their own duplicate vocabulary terms. In addition to this general rule, some specific cases are covered by other conformance rules. 4.3.1.6 LDP-RSs predicates SHOULD use standard vocabularies... 4.3.1.6 LDP-RSs predicates SHOULD use standard vocabularies such as Dublin Core [DC-TERMS], RDF [rdf11-concepts] and RDF Schema [rdf-schema], whenever possible. 4.3.1.7 In the absence of special knowledge of the applicat... 4.3.1.7 In the absence of special knowledge of the application or domain, LDP clients MUST assume that any LDP-RS can have multiple values for rdf:type. 4.3.1.8 In the absence of special knowledge of the applicat... 4.3.1.8 In the absence of special knowledge of the application or domain, LDP clients MUST assume that the rdf:type values of a given LDP-RS can change over time. 4.3.1.9 LDP clients SHOULD always assume that the set of pr... 4.3.1.9 LDP clients SHOULD always assume that the set of predicates for a LDP-RS 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 their triples, and 4.3.1.10 LDP servers MUST NOT require LDP clients to implem... 4.3.1.10 LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [rdf11-concepts]. The practical im 4.3.1.11 A LDP client MUST preserve all triples retrieved f... 4.3.1.11 A LDP client MUST preserve all triples retrieved from an LDP-RS 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 4.3.1.12 LDP clients MAY provide LDP-defined hints that all... 4.3.1.12 LDP clients MAY provide LDP-defined hints that allow servers to optimize the content of responses. section 7.2 Preferences on the Prefer Request Header defines hints that apply to LDP-RSs. 4.3.1.13 LDP clients MUST be capable of processing response... 4.3.1.13 LDP clients MUST be capable of processing responses formed by an LDP server that ignores hints, including LDP-defined hints. Feature At Risk The LDP Working Group proposes incorporatio... 4.3.1.14 LDP clients SHOULD be capable of processing succes... 4.3.1.14 LDP clients SHOULD be capable of processing successful HTTP GET responses formed by an LDP server that independently initiated paging, returning a page of representation instead of full resource representation [LDP-PAGING]. 4.3.2 HTTP GET 4.3.2.1 LDP servers MUST provide a text/tur... 4.3.2 HTTP GET 4.3.2.1 LDP servers MUST provide a text/turtle representati... 4.3.2.1 LDP servers MUST provide a text/turtle representation of the requested LDP-RS [turtle]. 4.4 Non-RDF Source The following section contains normative... 4.4 Non-RDF Source 4.4.1 General 4.4.1.1 Each LDP Non-RDF Source MUST also be... 4.4.1 General 4.4.1.1 Each LDP Non-RDF Source MUST also be a conforming L... 4.4.1.1 Each LDP Non-RDF Source MUST also be a conforming LDP Resource in section 4.2 Resource. LDP Non-RDF Source may not be able to fully express their state using RDF. [rdf11-concepts] 5. Linked Data Platform Containers 5.1 Introduction This s... 5. Linked Data Platform Containers 5.1 Introduction This section is non-normative. Many HTTP a... 5.1 Introduction # The following is the representation of # http://exampl... # The following is a partial representation of # http://e... # The following is an elaborated representation of LDPR #... # The following is an elaborated representation of LDPC #... # The following is an elaborated representation of LDPC #... # The following is an elaborated representation of # http... Fig. 3 Class relationship of types of Linked Data Platform... Completed Request Effects Membership Containment LD... 5.1.1 Retrieving Only Empty-Container Triples The represen... 5.1.1 Retrieving Only Empty-Container Triples Request: 5.2 Container The following section contains normative clau... 5.2 Container 5.2.1 General The Linked Data Platform does not define how... 5.2.1 General LDPCs 5.2.1.1 Each Linked Data Platform Container MUST also be a... 5.2.1.1 Each Linked Data Platform Container MUST also be a conforming Linked Data Platform RDF Source. LDP clients MAY infer the following triple: whose subject is ldp:Container, whose predicate is rdfs:subClassOf, and whose object is ldp:RDFSource, but t 5.2.1.2 The representation of an LDPC MAY have an rdf:type... 5.2.1.2 The representation of an LDPC MAY have an rdf:type of only one of ldp:Container for Linked Data Platform Container. Non-normative note: LDPCs might have additional types, like any LDP-RS. 5.2.1.3 LDPC representations SHOULD NOT use RDF container t... 5.2.1.3 LDPC representations SHOULD NOT use RDF container types rdf:Bag, rdf:Seq or rdf:List. 5.2.1.4 LDP servers exposing LDPCs MUST advertise their LDP... 5.2.1.4 LDP servers exposing LDPCs MUST advertise their LDP support by exposing a HTTP Link header with a target URI matching the type of container (see below) the server supports, and a link relation type of type (that is, rel='type') in all responses to 5.2.1.5 LDP servers SHOULD respect all of a client's LDP-de... 5.2.1.5 LDP servers SHOULD respect all of a client's LDP-defined hints, for example which subsets of LDP-defined state the client is interested in processing, to influence the set of triples returned in representations of an LDPC, particularly for large L 5.2.2 HTTP GET Per section 4.2.2 HTTP GET the HTTP GET meth... 5.2.2 HTTP GET 5.2.3 HTTP POST Per [HTTP11], this HTTP method is optional... 5.2.3 HTTP POST 5.2.3.1 LDPC clients SHOULD create member resources by subm... 5.2.3.1 LDPC clients SHOULD create member resources by submitting a representation as the entity body of the HTTP POST to a known LDPC. If the resource was created successfully, LDP servers MUST respond with status code 201 (Created) and the Location head 5.2.3.2 When a successful HTTP POST request to an LDPC resu... 5.2.3.2 When a successful HTTP POST request to an LDPC results in the creation of an LDPR, a containment triple MUST be added to the state of LDPC. The containment triple whose subject is the LDPC URI, whose predicate is ldp:contains and whose object is t 5.2.3.3 LDP servers MAY accept an HTTP POST of non-RDF repr... 5.2.3.3 LDP servers MAY accept an HTTP POST of non-RDF representations (LDP-NRs) for creation of any kind of resource, for example binary resources. See the Accept-Post section for details on how clients can discover whether an LDPC supports this behavior 5.2.3.4 LDP servers that successfully create a resource fro... 5.2.3.4 LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any mode 5.2.3.5 LDP servers MUST accept a request entity body with... 5.2.3.5 LDP servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle [turtle]. 5.2.3.6 LDP servers SHOULD use the Content-Type request hea... 5.2.3.6 LDP servers SHOULD use the Content-Type request header to determine the representation format when the request has an entity body. 5.2.3.7 In RDF representations, LDP servers MUST interpret... 5.2.3.7 In RDF representations, LDP servers MUST interpret the null relative URI for the subject of triples in the LDPR representation in the request entity body as referring to the entity in the request body. Commonly, that entity is the model for the “t 5.2.3.8 LDP servers SHOULD assign the URI for the resource... 5.2.3.8 LDP servers SHOULD assign the URI for the resource to be created using server application specific rules in the absence of a client hint. 5.2.3.9 LDP servers SHOULD allow clients to create new reso... 5.2.3.9 LDP servers SHOULD allow clients to create new resources without requiring detailed knowledge of application-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs. LDP servers expose the 5.2.3.10 LDP servers MAY allow clients to suggest the URI f... 5.2.3.10 LDP servers MAY allow clients to suggest the URI for a resource created through POST, using the HTTP Slug header as defined in [RFC5023]. LDP adds no new requirements to this usage, so its presence functions as a client hint to the server providi 5.2.3.11 LDP servers that allow member creation via POST SH... 5.2.3.11 LDP servers that allow member creation via POST SHOULD NOT re-use URIs. 5.2.3.12 Upon successful creation of an LDP-NR (HTTP status... 5.2.3.12 Upon successful creation of an LDP-NR (HTTP status code of 201-Created and URI indicated by Location response header), LDP servers MAY create an associated LDP-RS to contain data about the newly created LDP-NR. If an LDPC server creates this asso 5.2.3.13 LDP servers that support POST MUST include an Acce... 5.2.3.13 LDP servers that support POST MUST include an Accept-Post response header on HTTP OPTIONS responses, listing post document media type(s) supported by the server. LDP only specifies the use of POST for the purpose of creating new resources, but a 5.2.4 HTTP PUT Per [HTTP11], this HTTP method is optional a... 5.2.4 HTTP PUT 5.2.4.1 LDP servers SHOULD NOT allow HTTP PUT to update an... 5.2.4.1 LDP servers SHOULD NOT allow HTTP PUT to update an LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code. 5.2.4.2 LDP servers that allow LDPR creation via PUT SHOULD... 5.2.4.2 LDP servers that allow LDPR creation via PUT SHOULD NOT re-use URIs. For RDF representations (LDP-RSs),the created resource can be thought of as an RDF named graph [rdf11-concepts]. 5.2.5 HTTP DELETE Per [HTTP11], this HTTP method is optiona... 5.2.5 HTTP DELETE 5.2.5.1 When an LDPR identified by the object of a containm... 5.2.5.1 When an LDPR identified by the object of a containment triple is deleted, the LDPC server MUST also remove the LDPR from the containing LDPC by removing the corresponding containment triple. 5.2.5.2 When an LDPR identified by the object of a containm... 5.2.5.2 When an LDPR identified by the object of a containment triple is deleted, and the LDPC server created an associated LDP-RS (see the LDPC POST section), the LDPC server MUST also remove the associated LDP-RS it created. 5.2.6 HTTP HEAD Note that certain LDP mechanisms rely on HT... 5.2.6 HTTP HEAD 5.2.7 HTTP PATCH Per [HTTP11], this HTTP method is optional... 5.2.7 HTTP PATCH 5.2.7.1 LDP servers are RECOMMENDED to support HTTP PATCH a... 5.2.7.1 LDP servers are RECOMMENDED to support HTTP PATCH as the preferred method for updating an LDPC's empty-container triples. 5.2.8 HTTP OPTIONS This specification imposes the following... 5.2.8 HTTP OPTIONS 5.2.8.1 When an LDPC server creates an LDP-NR (for example,... 5.2.8.1 When an LDPC server creates an LDP-NR (for example, one whose representation was HTTP POSTed to the LDPC) the LDP server might create an associated LDP-RS to contain data about the non-LDPR (see LDPC POST section). For LDP-NRs that have this assoc 5.3 Basic The following section contains normative clauses... 5.3 Basic 5.3.1 General 5.3.1.1 Each LDP Basic Container MUST also b... 5.3.1 General 5.3.1.1 Each LDP Basic Container MUST also be a conforming... 5.3.1.1 Each LDP Basic Container MUST also be a conforming LDP Container in section 5.2 Container along the following restrictions in this section. LDP clients MAY infer the following triple: whose subject is ldp:BasicContainer, whose predicate is rdfs:su 5.4 Direct The following section contains normative clauses... 5.4 Direct 5.4.1 General 5.4.1.1 Each LDP Direct Container MUST also... 5.4.1 General 5.4.1.1 Each LDP Direct Container MUST also be a conforming... 5.4.1.1 Each LDP Direct Container MUST also be a conforming LDP Container in section 5.2 Container along the following restrictions. LDP clients MAY infer the following triple: whose subject is ldp:BasicContainer, whose predicate is rdfs:subClassOf, and w 5.4.1.2 LDP Direct Containers SHOULD use the ldp:member pre... 5.4.1.2 LDP Direct Containers SHOULD use the ldp:member predicate as an LDPC's membership predicate if there is no obvious predicate from an application vocabulary to use.. The state of an LDPC includes information about which resources are its members, i 5.4.1.3 Each LDP Direct Container representation MUST conta... 5.4.1.3 Each LDP Direct Container representation MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is the ldp:membershipResource, and whose object is the LDPC's membership-constant-URI. Commonly the LDPC's URI is the membershi 5.4.1.4 Each LDP Direct Container representation MUST conta... 5.4.1.4 Each LDP Direct Container representation MUST contain exactly one triple whose subject is the LDPC URI, and whose predicate is either ldp:hasMemberRelation or ldp:isMemberOfRelation. The object of the triple is constrained by other sections, such 5.4.1.4.1 LDP Direct Containers whose membership triple pat... 5.4.1.4.1 LDP Direct Containers whose membership triple pattern is ( membership-constant-URI , membership-predicate , member-derived-URI ) MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is ldp:hasMemberRelation, and whose o 5.4.1.4.2 LDP Direct Containers whose membership triple pat... 5.4.1.4.2 LDP Direct Containers whose membership triple pattern is ( member-derived-URI , membership-predicate , membership-constant-URI ) MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is either ldp:isMemberOfRelation, and 5.4.1.5 LDP Direct Containers MUST behave as if they have a... 5.4.1.5 LDP Direct Containers MUST behave as if they have a ( LDPC URI, ldp:insertedContentRelation , ldp:MemberSubject ) triple, but LDP imposes no requirement to materialize such a triple in the LDP-DC representation. The value ldp:MemberSubject means t 5.4.2 HTTP POST 5.4.2.1 When a successful HTTP POST reques... 5.4.2 HTTP POST 5.4.2.1 When a successful HTTP POST request to an LDPC resu... 5.4.2.1 When a successful HTTP POST request to an LDPC results in the creation of an LDPR, the LDPC MUST update its membership triples to reflect that addition, and the resulting membership triple MUST be consistent with any LDP-defined predicates it expo 5.4.3 HTTP DELETE 5.4.3.1 When an LDPR identified by the o... 5.4.3 HTTP DELETE 5.4.3.1 When an LDPR identified by the object of a membersh... 5.4.3.1 When an LDPR identified by the object of a membership triple which was originally created by the LDP-DC is deleted, the LDPC server MUST also remove the corresponding membership triple.. 5.5 Indirect The following section contains normative claus... 5.5 Indirect 5.5.1 General 5.5.1.1 Each LDP Indirect Container MUST als... 5.5.1 General 5.5.1.1 Each LDP Indirect Container MUST also be a conformi... 5.5.1.1 Each LDP Indirect Container MUST also be a conforming LDP Direct Container in section 5.4 Direct along the following restrictions. LDP clients MAY infer the following triple: whose subject is ldp:IndirectContainer, whose predicate is rdfs:subClass 5.5.1.2 LDP Indirect Containers MUST contain exactly one tr... 5.5.1.2 LDP Indirect Containers MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is ldp:insertedContentRelation, and whose object ICR describes how the member-derived-URI in the container's membership triples is chosen. The m 5.5.2 HTTP POST 5.5.2.1 LDPCs whose ldp:insertedContentRel... 5.5.2 HTTP POST 5.5.2.1 LDPCs whose ldp:insertedContentRelation triple has... 5.5.2.1 LDPCs whose ldp:insertedContentRelation triple has an object other than ldp:MemberSubject and that create new resources MUST add a triple to the container whose subject is the container's URI, whose predicate is ldp:contains, and whose object is t 6. Notable information from normative references This secti... 6. Notable information from normative references 6.1 Architecture of the World Wide Web This section is non-... 6.1 Architecture of the World Wide Web 6.1.1 LDPC membership is not exclusive; this means that the... 6.1.1 LDPC membership is not exclusive; this means that the same resource (LDPR or not) can be a member of more than one LDPC. 6.1.2 LDP servers should not re-use URIs, regardless of the... 6.1.2 LDP servers should not re-use URIs, regardless of the mechanism by which members are created (POST, PUT, etc.). Certain specific cases exist where an LDPC server might delete a resource and then later re-use the URI when it identifies the same resou 6.2 HTTP 1.1 This section is non-normative. Reference: [HTT... 6.2 HTTP 1.1 6.2.1 LDP servers can support representations beyond those... 6.2.1 LDP servers can support representations beyond those necessary to conform to this specification. These could be other RDF formats, like N3 or NTriples, but non-RDF formats like HTML [HTML401] and JSON [RFC4627] would likely be common. HTTP content n 6.2.2 LDPRs can be created, updated and deleted using metho... 6.2.2 LDPRs can be created, updated and deleted using methods not defined in this document, for example through application-specific means, SPARQL UPDATE, etc. [SPARQL-UPDATE], as long as those methods do not conflict with this specification's normative r 6.2.3 LDP servers remove the resource identified by the Req... 6.2.3 LDP servers remove the resource identified by the Request-URI in response to a successful HTTP DELETE request. After such a request, a subsequent HTTP GET on the same Request-URI usually results in a 404 (Not found) or 410 (Gone) status code, althou 6.2.4 LDP servers can alter the state of other resources as... 6.2.4 LDP servers can alter the state of other resources as a result of any HTTP request, especially when non-safe methods are used ([HTTP11] section 9.1). For example, it is acceptable for the server to remove triples from other resources whose subject o 6.2.5 LDP servers can implement HTTP PATCH to allow modific... 6.2.5 LDP servers can implement HTTP PATCH to allow modifications, especially partial replacement, of their resources. No minimal set of patch document formats is mandated by this document or by the definition of PATCH [RFC5789]. 6.2.6 When the Content-Type request header is absent from a... 6.2.6 When the Content-Type request header is absent from a request, LDP servers might infer the content type by inspecting the entity body contents [HTTP11]. 6.3 RDF This section is non-normative. Reference: [rdf11-co... 6.3 RDF 6.3.1 The state of an LDPR can have triples with any subjec... 6.3.1 The state of an LDPR can have triples with any subject(s). The URL used to retrieve the representation of an LDPR need not be the subject of any of its triples. 6.3.2 The representation of an LDPC can include an arbitrar... 6.3.2 The representation of an LDPC can include an arbitrary number of additional triples whose subjects are the members of the container, or that are from the representations of the members (if they have RDF representations). This allows an LDP server to 6.3.3 The state of an LDPR can have more than one triple wi... 6.3.3 The state of an LDPR can have more than one triple with an rdf:type predicate. 7. HTTP Header Definitions 7.1 The Accept-Post Response He... 7. HTTP Header Definitions 7.1 The Accept-Post Response Header Feature At Risk The LD... 7.1 The Accept-Post Response Header 7.1.1 The syntax for Accept-Post, using the ABNF syntax def... 7.1.1 The syntax for Accept-Post, using the ABNF syntax defined in Section 2.1 of [HTTP11], is: 7.1.2 The Accept-Post HTTP header SHOULD appear in the OPTI... 7.1.2 The Accept-Post HTTP header SHOULD appear in the OPTIONS response for any resource that supports the use of the POST method. The presence of the Accept-Post header in response to any method is an implicit indication that POST is allowed on the resou 7.1.3 IANA Registration Template The Accept-Post response... 7.1.3 IANA Registration Template 7.2 Preferences on the Prefer Request Header 7.2.1 Summary... 7.2 Preferences on the Prefer Request Header 7.2.1 Summary Need to update normative reference once RFC... 7.2.1 Summary 7.2.2 Specification 7.2.2.1 The include hint defines a sub... 7.2.2 Specification 7.2.2.1 The include hint defines a subset of an LDPR's cont... 7.2.2.1 The include hint defines a subset of an LDPR's content that a client would like included in a representation. The syntax for the include parameter of the HTTP Prefer request header's return=representation preference [Prefer] is: 7.2.2.2 The omit hint defines a subset of an LDPR's content... 7.2.2.2 The omit hint defines a subset of an LDPR's content that a client would like omitted from a representation. The syntax for the omit parameter of the HTTP Prefer request header's return=representation preference [Prefer] is: 7.2.2.3 When LDP servers receive a request with conflicting... 7.2.2.3 When LDP servers receive a request with conflicting hints, this specification imposes no requirements on their behavior. They are free to reject the request, process it applying some subset of the hints, or anything else appropriate to the server. 7.2.2.4 This specification defines the following URIs for c... 7.2.2.4 This specification defines the following URIs for clients to use with include and omit parameters. It assigns no meaning to other URIs, although other specifications MAY do so. 7.2.3 Examples This section is non-normative. If we assume... 7.2.3 Examples # The following is the representation of # http://example... Clients interested only in information about the container (... Clients interested only in information about the container (... Clients interested only in information about the container (... 8. Security Considerations This section is non-normative. A... 8. Security Considerations A. Acknowledgements This section is non-normative. The foll... A. Acknowledgements B. Change History This section is non-normative. Summary of... B. Change History C. References C.1 Normative references [DC-TERMS] Dublin... C. References C.1 Normative references [DC-TERMS] Dublin Core Metadata I... C.1 Normative references [DC-TERMS] [HTTP11] [LDP-PAGING] [Prefer] [RFC2119] [RFC3864] [RFC3986] [RFC3987] [RFC5023] [RFC5234] [RFC5789] [RFC5988] [RFC6585] [WEBARCH] [rdf-schema] [rdf11-concepts] [turtle] C.2 Informative references [HTML401] Dave Raggett; Arnaud... C.2 Informative references [HTML401] [HTTPBIS-SEMANTICS] [LDP-UCR] [LINKED-DATA] [RFC4627] [SPARQL-UPDATE] [sparql11-query]
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

Hello,

I've notice that the latest published version suggest using RDF formats
that support multiple named graphs. For the net-worth example it suggests
using "one named graph for the net worth resource and then two others for
asset and liability containers".

I am irritated by this recommendation. First the specification mandates
the possibility to serialize as turtle which does not currently support
multiple named graphs.

But more importantly I don't see the reason of this splitting of the
information into many graphs and it seems to significantly restrict the
possibilities to implement LDP Servers.

The suggested three graph do not seem to represent three different
information sources with thus potentially contradictory statements. So in
this situation there is typically no quotation-use case with provenance
that must be preserved. Grouping into different graphs what can be safely
expressed in one graph seems to deny the expressive power of RDF and
suggesting that the grouping of triples into different graphs has a
significance beyond provenance.

With the previous published version it was possible to have an LDP
compliant server backed by a single graph. This would be my choice of
implementation if the data has a single provenance and the access
restrictions are the same for all the triples. This change in the new
version seems however to mandate implementation to be based on different
graphs for the different resources.

In my opinion this is a significant loss of flexibility. I would like for
simple implementations based on one graph to be possible. It can also be
useful for an implementation to be based on multiple graphs representing
different provenances or confidentiality but containing descriptions of
larger and possibly overlapping sets of resources. With the latter
approach the resource description accessed through LDP would contain more
or less triples depending on my access rights and the sources I've decided
to trust.

Cheers,
Reto

Related issues: (space separated ids)

WG Notes:

Resolution: The WG decided to remove references to named graphs by removing "named" in terminology section, removing paragraph in examples, and removing sentence in section 5.2.3.4 and 5.2.4.2 See http://www.w3.org/2013/meeting/ldp/2014-04-15#resolution_3

(Please make sure the resolution is adapted for public consumption)