Edit comment LC-2835 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-2835

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.9.1 Servers must support the OPTIONS method. Why? Should there be a basic level
of functionality which any LDPR allows and which does not require OPTIONS polling?

OPTIONS is expensive: another round trip.

Always avoid an extra round trip if you can.
We need this system to move really fast.
Round trips show up as user interface sluggishness, user task inefficiency, and lost/bored users.

Note that OPTIONs is resource-specific. (Unless you use some sort of wildcard extension
or a POWDER label say). You have to do it for every fresh URI you find.

The Linked Data operation is a GET. Is the basic operation for an LDP-capable client always OPTIONS, GET, or GET, OPTIONS?

Maybe key headers can be put into the HEAD and GET response.

Maybe the class of resource announced with Link: rel=type
can have a URI which can be looked up itself and cached.
and will give the set of features in a standard way.

Suggest define a core LDP protocol which does NOT use OPTIONS, by assuming that
the core functionality is enough for clients to do what they need.
Clients needing extensions maybe can use OPTIONS. But maybe POWDERR should be preferred.

Related issues: (space separated ids)

WG Notes:

Resolution: OPTIONS is not required to achieve this. It could be used in cases when a client wants a low-cost means to learn more about the resource identified by the URI if it hasn't already done a GET. If it has done a GET and kept the header information, there is no need to use OPTIONS.

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