Feedback on section 4...

Feedback on section 4...

I'd suggets that the notion of "server" within the specification is 
unneeded as "Linked Data Platform Resources (LDPRs) are HTTP resources" 
- by removing the notion of "server" you can simplify the specification.

Further, LDPRs are RDF data model documents, which are always guaranteed 
to be in at least turtle. Since GET must be supported, and turtle must 
be supported.

Thus:

4.1 General
============================
- del 4.1.1 LDPR servers must at least be HTTP/1.1 conformant servers.
+ add 4.1.1 LDPRs must support at least HTTP/1.1

- del 4.1.2 LDPR servers must provide an RDF representation for LDPRs. 
The subject is typically the LDPR itself.
(it's void)

- del 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.
(it's void)

- simplify 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.
+ to 4.1.x Clients can access a LDPR using multiple URLs, for example 
when DNS aliasing is used. An LDPR must provide a canonical URL for 
itself using the Content-Location header. Clients should use that 
canonical URL to identify the LDPR.
(consider adding Link rel=canonical too)

4.1.5 and 4.1.6 make more sense when swapped over

- del 4.1.8
as it's nearly impossible for anybody to conform to, as it means only 
predicates which deref to text/turtle that conforms to the LDPR spec can 
be used. Further "whose representations are retrievable." is unneeded in 
the sentence "These predicate URIs must identify LDPRs whose 
representations are retrievable.", and "These predicate URIs must 
identify LDPRs" makes "Predicate URIs used in LDPR representations 
should be HTTP URLs." redundant. Further still "LDPR servers should 
provide an RDF Schema [RDF-SCHEMA] representation of these predicates." 
is made redundant by 4.1.5

- del 4.1.9 as already agreed at f2f

4.1.10 may require clarification, the first sentence appears to say that 
every LDPR must link to another LDPR in at least one triple, but the 
second sentence doesn't relate to that scenario.

4.1.11 remove "servers" and a typo "would be likely be common."

4.1.13 remove "servers"


4.2 HTTP GET
============================

- del 4.2.1 LDPR servers must support the HTTP GET Method for LDPRs.
+ add 4.2.1 LDPRs MUST support the HTTP GET Method.

- del 4.2.2 LDPR servers must provide an text/turtle representation of 
the requested LDPR.[TURTLE]
+ add 4.2.2 LDPRs must provide a text/turtle representation.

4.1.3 is already gone

4.2.4 and 4.2.5 can be reduced to one "LDPR clients must assume that any 
LDPR may have multiple values for rdf:type, and that those values may 
change over time." - however by 4.1.7 (LDPR representations should have 
at least one rdf:type set explicitly) the text would need to be "zero, 
one, or multiple values for rdf:type", which leads me to wonder if it's 
worth saying.


4.4 HTTP PUT
============================

4.4.1
"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."? 
this seems to pop up from nowhere, the spec doesn't explain anything 
about how they should be used, or that the server must control them. It 
also places a requirement for the server to always have an identifier 
for each person doing a PUT, and doesn't account for automated agents 
uploading on behalf of a human agent. Modified may not take in to 
account offline sync.. if it's supposed to be "last-modified" then a 
restriction where dcterms:modified values must match the Last-Modified 
of the server would do it, but seems very limiting and perhaps unneeded?

4.4.2 would be good to mention "If-None-Match: *", and it's "412 
(Precondition Failed)" not "412 (Condition Failed). No need to mention 
"LDPR clients"

4.4.3 seems informative rather than normative, primer stuff

4.4.4 can be reduced to "LDPRs MAY discard triples whose predicates the 
server does not recognize or otherwise chooses not to persist", but 
"does not recognize" could be considered bad form, requiring the data 
tier to have application tier logic in it, similarly it may want to add 
triples by inference or for data management. Thus I'd suggest something 
like "LDPRs MAY discard triples which violate their privacy or security 
policies, and MAY augment the graph with further triples by inference 
(such as rdf:type) or to indicate the LDPRs status (dcterms:modified, 
dcterms:creator)."
Do note though, that this clashes with 4.4.1 ("LDPR servers must replace 
the entire persistent state of the identified resource with the entity 
representation in the body of the request.")

- del 4.4.6 LDPR servers may choose to allow the creation of new 
resources using HTTP PUT.
+ add 4.4.6 LDPRs may be created using HTTP PUT.

- del 4.4.7, it's primer/intro stuff


4.5 HTTP DELETE
============================

4.5.1, the first sentence is redundant after you remove the word 
"server" .. eg: "LDPRs must remove themselves."
thus suggest:
"4.5.1 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. 
Clients should note that severs may reuse a Request-URI under some 
circumstances."

4.5.2 needs a reword as soon as you remove the word "server" - suggest:
"An HTTP DELETE request may alter the state of other resources."
the "for example..." isn't really needed


4.7 HTTP PATCH
============================
4.7.2 may be unneeded, as per 4.4.7


Summary:
============================
 From what I can tell, section 4 amounts to:
- Use HTTP/1.1 and text/turtle
- Always support HEAD/GET, optionally support PUT/PATCH/DELETE, and 
advertise these using Allow. OPTIONS of course, may need mentioned.
- Specify canonical URLs
- Support If-Match/If-None-Match and ETags
- Try to specify an rdf:type, and use common vocabs where you can.
- Be aware that other processes may change LDPRs
- LDPRs may conneg to appropriate alternative formats


General Notes:
============================
You may need to advertise that something is an LDPR (supporting 
PUT/PATCH/DELETE) via a header, and the URL to PUT/PATCH/DELETE may be 
different to the one you GET (for example https for state changing 
events, or when CDNs and reverse proxies are used to host LDPRs).

Best,

Nathan

Received on Saturday, 3 November 2012 11:48:39 UTC