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

Quick access to LC-2812 LC-2813 LC-2814 LC-2815 LC-2816 LC-2833 LC-2834 LC-2835 LC-2836 LC-2837 LC-2838 LC-2839 LC-2840

Comment LC-2834

Comment Shortname:

Commenter: Tim Berners-Lee <timbl@w3.org>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeLinked Data Platform 1.0 W3C Last Call Working Draft 30 July 2013 Abstract This document describes a set of best practices an... Status of This Document This section describes the status o... 5 February 2004 W3C Patent Policy Table of Contents 1. Introduction 2. Terminology 2.1 Conv... 1. Introduction This section is non-normative. This documen... 1. Introduction 2. Terminology Terminology is based on W3C's Architecture o... 2. Terminology Linked Data Platform Resource LDPR Linked Data Platform Container LDPC Membership triples Membership subject Membership predicate Page resource Non-member resource Resource inlining Member inlining 2.1 Conventions Used in This Document Sample resource repre... 2.1 Conventions Used in This Document 3. Conformance As well as sections marked as non-normative,... 4. Linked Data Platform Resources 4.1 Informative This sec... 4. Linked Data Platform Resources 4.1 Informative This section is non-normative. Linked Data... 4.1 Informative LDPRs 4.2 General 4.2.1 LDPR servers MUST at least be HTTP/1.1 co... 4.2 General 4.2.1 LDPR servers MUST at least be HTTP/1.1 conformant serv... 4.2.2 LDPR servers MUST provide an RDF representation for LD... 4.2.3 LDPR servers MAY host a mixture of LDPRs and non-LDPRs... 4.2.4 LDPRs SHOULD reuse existing vocabularies instead of cr... 4.2.4.1 LDPR predicates SHOULD use standard vocabularies suc... 4.2.5 LDPR representations SHOULD have at least one rdf:type... 4.2.6 LDPR servers MAY support standard representations beyo... 4.2.7 LDPRs MAY be created, updated and deleted using method... 4.2.8 LDPR server responses MUST use entity tags (either wea... 4.2.9 LDPR servers SHOULD enable simple creation and modific... 4.2.10 LDPR servers MUST advertise their LDP support by expo... 4.2.11 LDPR servers MUST NOT require LDP clients to implemen... 4.2.12 LDPR servers MUST assign the default base-URI for [RF... 4.3 HTTP GET 4.3.1 LDPR servers MUST support the HTTP GET M... 4.3 HTTP GET 4.3.1 LDPR servers MUST support the HTTP GET Method for LDPR... 4.3.2 LDPR servers MUST support the HTTP response headers de... 4.3.3 LDPR servers SHOULD provide a text/turtle representati... 4.3.4 LDPR servers MAY provide representations of the reques... 4.3.5 In the absence of special knowledge of the application... 4.3.6 In the absence of special knowledge of the application... 4.4 HTTP POST This specification adds no new requirements o... 4.4 HTTP POST 4.5 HTTP PUT This specification imposes the following new r... 4.5 HTTP PUT 4.5.1 If HTTP PUT is performed on an existing resource, LDPR... 4.5.2 LDPR clients SHOULD use the HTTP If-Match header and H... 4.5.3 LDPR clients SHOULD always assume that the set of pred... 4.5.4 LDPR clients SHOULD assume that an LDPR server could d... 4.5.5 An LDPR client MUST preserve all triples retrieved usi... 4.5.6 LDPR servers MAY choose to allow the creation of new r... 4.5.7 LDPR servers SHOULD allow clients to update resources... 4.6 HTTP DELETE This specification imposes the following ne... 4.6 HTTP DELETE 4.6.1 LDPR servers MUST remove the resource identified by th... 4.6.2 LDPR servers MAY alter the state of other resources as... 4.7 HTTP HEAD Note that certain LDP mechanisms, such as pag... 4.7 HTTP HEAD 4.7.1 LDPR servers MUST support the HTTP HEAD method. 4.8 HTTP PATCH This specification imposes the following new... 4.8 HTTP PATCH 4.8.1 LDPR servers MAY implement HTTP PATCH to allow modific... 4.8.2 LDPR servers SHOULD allow clients to update resources... 4.8.3 LDPR servers SHOULD NOT allow clients to create new re... 4.8.4 LDPR servers that support PATCH MUST include an Accept... 4.9 HTTP OPTIONS This specification imposes the following n... 4.9 HTTP OPTIONS 4.9.1 LDPR servers MUST support the HTTP OPTIONS method. 4.9.2 LDPR servers MUST indicate their support for HTTP Meth... 4.10 Paging 4.10.1 Introduction This section is non-normat... 4.10 Paging 4.10.1 Introduction This section is non-normative. It somet... 4.10.1 Introduction 4.10.2 HTTP GET In addition to the requirements set forth i... 4.10.2 HTTP GET 4.10.2.1 LDPR servers SHOULD allow clients to retrieve large... 4.10.2.2 LDPR servers MAY split the response representation... 4.10.2.3 LDPR servers that initiate paging SHOULD respond to... 4.10.2.4 LDPR servers that support paging MUST include a rep... 4.10.2.4.1 The page resource representation MUST have one tr... 4.10.2.4.2 The last page resource representation MUST have o... 4.10.2.4.3 The page resource representation SHOULD have one... 4.10.3 HTTP OPTIONS 4.10.3.1 LDPR servers MUST indicate the... 4.10.3 HTTP OPTIONS 4.10.3.1 LDPR servers MUST indicate their support for client... 4.11 Resource Inlining: Representing Multiple Resources in... 4.11 Resource Inlining: Representing Multiple Resources in a Response 4.11.1 Introduction This section is non-normative. Servers... 4.11.1 Introduction 4.11.2 Use with Care This section is non-normative. The bui... 4.11.2 Use with Care 4.11.3 HTTP GET In addition to the requirements set forth i... 4.11.3 HTTP GET 4.11.3.1 LDPR servers that support resource inlining MUST in... 4.11.3.2 LDPR servers that support resource inlining MUST in... 4.11.3.3 LDPR clients SHOULD avoid making HTTP GET requests... 4.11.3.4 LDPR clients MUST NOT assume that LDPR representati... 5. Linked Data Platform Containers 5.1 Informative This se... 5. Linked Data Platform Containers 5.1 Informative This section is non-normative. Many HTTP ap... 5.1 Informative # The following is a partial representation of # http://e... # The following is an elaborated representation of # http... # The following is the representation of # http://example... 5.1.1 Container Member Information 5.1.2 Retrieving Only Non-member Properties 5.1.3 Ordering 5.2 General The Linked Data Platform does not define how cl... 5.2 General LDPCs 5.2.1 LDPC servers MUST also be conformant LDPR servers. A L... 5.2.2 LDPC membership is not exclusive; this means that the... 5.2.3 The state of an LDPC includes information about which... 5.2.4 An LDPC representation MUST contain exactly one triple... 5.2.5 An LDPC representation MUST contain exactly one triple... 5.2.5.1 For a given triple T with a subject C of the LDPC an... 5.2.5.2 For a given triple T with a subject C of the LDPC an... 5.2.6 The representation of a LDPC MAY include an arbitrary... 5.2.7 The representation of a LDPC MUST have rdf:type of ldp... 5.2.8 LDPC representations SHOULD NOT use RDF container type... 5.2.9 LDPC servers SHOULD NOT re-use URIs, regardless of the... 5.2.10 Some LDPCs have membership objects that are not direc... 5.3 HTTP GET 5.3.1 The representation of a LDPC MUST contai... 5.3 HTTP GET 5.3.1 The representation of a LDPC MUST contain a set of tri... 5.3.2 LDPC servers MAY represent the members of a paged LDPC... 5.3.3 LDPC page representations ordered using ldp:containerS... page-ordering values 5.3.4 LDPC page representations ordered using ldp:containerS... 5.3.5 LDPC page representations ordered using ldp:containerS... 5.4 HTTP POST This specification imposes the following new... 5.4 HTTP POST 5.4.1 LDPC clients SHOULD create member resources by submitt... 5.4.2 After a successful HTTP POST request to a LDPC, the ne... 5.4.3 LDPC servers MAY accept an HTTP POST of non-RDF repres... 5.4.4 For servers that support create, LDPC servers MUST cre... 5.4.5 LDPC servers MUST accept a request entity body with a... 5.4.6 LDPC servers SHOULD use the Content-Type request heade... 5.4.7 In RDF representations, LDPC servers MUST interpret th... 5.4.8 LDPC servers SHOULD assign the subject URI for the res... 5.4.9 LDPC servers SHOULD allow clients to create new resour... 5.4.10 LDPC servers MAY allow clients to suggest the URI for... 5.4.11 LDPC servers that allow member creation via POST SHOU... 5.4.12 Upon successful creation of a non-RDF and therefore n... 5.4.13 LDPC servers that support POST MUST include an Accept... 5.4.14 LDPCs that create new member resources MAY add triple... 5.5 HTTP PUT This specification imposes the following new r... 5.5 HTTP PUT 5.5.1 LDPC servers SHOULD NOT allow HTTP PUT to update a LDP... 5.5.2 LDPC servers MAY allow updating LDPC non-membership pr... 5.5.3 LDPC servers SHOULD NOT allow HTTP PUT requests with i... 5.5.4 LDPC servers that allow member creation via PUT SHOULD... 5.6 HTTP DELETE This specification imposes the following ne... 5.6 HTTP DELETE 5.6.1 When a LDPC member resource originally created by the... 5.6.2 When the LDPC server successfully completes the DELETE... 5.6.3 When the conditions in 5.6.1 hold, and the LDPC tracks... 5.6.4 When a LDPC member resource originally created by the... 5.7 HTTP HEAD Note that certain LDP mechanisms, such as pag... 5.7 HTTP HEAD 5.8 HTTP PATCH This specification imposes the following new... 5.8 HTTP PATCH 5.8.1 LDPC servers are RECOMMENDED to support HTTP PATCH as... 5.9 HTTP OPTIONS This specification imposes the following n... 5.9 HTTP OPTIONS 5.9.1 LDPC servers SHOULD define a corresponding non-member... 5.9.2 When a LDPC creates a non-LDPR (e.g. binary) member (f... 5.10 Member Inlining: Returning All of a Container Page's M... 5.10 Member Inlining: Returning All of a Container Page's Members in a Response 5.10.1 Introduction 5.10.2 HTTP GET 5.10.2.1 LDPC representations that are member inlined MUST i... 5.10.2.2 LDPC clients SHOULD avoid making HTTP GET requests... 5.10.2.3 LDPC clients MUST NOT assume that LDPC representati... 6. HTTP Header Definitions 6.1 The Accept-Post Response He... 6.1 The Accept-Post Response Header Feature At Risk The LD... 6.1 The Accept-Post Response Header 6.1.1 The syntax for Accept-Post, using the ABNF syntax defi... 6.1.2 The Accept-Post HTTP header SHOULD appear in the OPTIO... 6.1.3 IANA Registration Template A. Acknowledgements This section is non-normative. The foll... B. References B.1 Normative references [DC-TERMS] Dublin... B.1 Normative references [DC-TERMS] Dublin Core Metadata I... [DC-TERMS] [HTML401] [HTTP11] [RDF-CONCEPTS] [RDF-SCHEMA] [RFC2119] [RFC3864] [RFC3987] [RFC4627] [RFC5023] [RFC5789] [RFC5988] [RFC6585] [SPARQL-QUERY] [SPARQL-UPDATE] [TURTLE] B.2 Informative references [LINKED-DATA] Tim Berners-Lee.... [LINKED-DATA] [RFC3986] [WEBARCH]
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:

4.5.6. You allow servers which do not support PUT or PATCH or POST. Why? A client using such a server will have no write ability at all, and so your spec as a protocol delivers zero value on top of HTTP GET. Suggest change all to MUST, or make two levels of server, one which supports PUT and PATCH and no collections, and one which supports everything.

...

4.8 PATCH is optional. Suggest a MUST. PATCH is to first order the only thing LDP provides over WebDav.


4.8.2 MUST

Suggest specify a the subset of sparql-update we use at the moment as a mandatory patch format to get basic interop, with possible later extension to other languages.


*******

Something I mentioned in a mail a long time ago is the necessity of doing
atomic flag (P/V) operations with a PATCH.

To recap, you have to be able to do a form of DELETE triple(s) which will FAIL
and prevent any corresponding INSERT from happening. This is top be
able to allocate shared resources.

Eg DELETE { :x :nextID 4 } INSERT DATA { ?x :nexID 5 }.

Hmm. Maybe this is covered by the ETag system sufficiently.
If so, the case should be given as an worked example and put in as a test case.
A collaborative system which allows atomic flag setting is fundamentally more valuable
than one which doesn't.

Related issues: (space separated ids)

WG Notes:

Resolution: The LDP specification brings several features such as paging and containers that are useful even in case of a read-only server. As for PATCH, everybody wants it but given the lack of a standard PATCH format and the WG timeframe it is unpractical for LDP to make PATCH mandatory. The WG is however committed to encourage support for PATCH and will do so via the LDP Best Practices and Guidelines document the WG plans to publish as a Note. As soon as a standard PATCH format is available the WG will revise the LDP spec to make use of it.

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