Some points in editor's draft that we might want to discuss our understandings of

4.1.10 LDPR servers MUST advertise their LDP support ...
During the F2F someone (Sandro maybe?) said that we should state that the 
ldp:Resource link header is roughly equivalent to rdf:type=ldp:Resource... 
at least that's how I interpreted what I heard, and I reflected that in 
the draft using the "notionally equivalent" language.   It's chafing a bit 
- I don't think they are in fact equivalent.  A non-LDPR server "dumb RDF 
store" might happily serve up a document with rdf:type=ldp:Resource, and 
*without* the header.  A client should not expect behaviors like "must 
serve Turtle" from such an implementation, so they're clearly not 
equivalent.  This counter-example in fact might illuminate things in one 
of the accompanying documents.


4.9 Paging
Should we say anything about pages (ordinarily at least) not being 
updatable (PATCH is pretty much the only game in town once the resource is 
paged, at least in the server-initiated paging case, and you'd patch "the 
resource being paged" not the page).  This might well be in the deployment 
guide/similar.


4.9 Paging
Should we add a HEAD section with just the first paragraph from 4.6 HTTP 
HEAD, pointing them to GET?  And should both point to OPTIONS as well, 
given Steve's recent email about the "duplication" between HEAD and 
OPTIONS alongside HTTP's dependency between GET and HEAD.  5.7 HTTP HEAD 
seems to have the right content, so maybe it's align with 4.6 and ?add? 
4.9.x HEAD.


4.9.2.4 LDPR servers that support paging MUST include in the page 
representation a representation for the LDPR, such that: 
"LDPR" should be "page resource" I think.


4.9.2.4 LDPR servers that support paging MUST include in the page 
representation a representation for the LDPR, such that: 
Note that this one ends with a colon.  Prior to renumbering, the following 
3 constraints were nested under this one, so instead of 4.9.2.5-.7 they 
would have been 4.9.2.4.1-.3.  Not sure if this is just removing the 
colon, or re-nesting.  It reads fine to me either way.


5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of 
ldp:membershipPredicate, 
5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of 
ldp:membershipPredicateInverse, 
5.2.10 Some LDPC's have membership object's that are not directly URIs 
minted upon LDPC member creation, 
I found these particularly hard to read.  And I perpetrated the 
SortCollation paragraphs.  Links to examples might be an 80-20 solution.


5.5.1 LDPC servers SHOULD NOT allow HTTP PUT to update a LDPC’s members; 
5.5.3 LDPC servers SHOULD NOT allow HTTP PUT requests with member 
information in the request representation. 
"update a LDPC’s members" sounds very close to "member information", 
especially I suspect for those outside our particular asylum.
In the first case I think we are talking about membership triples, which 
is now formally defined (has been for many months) in Terminology, perhaps 
use that formally defined term.
In the second case I think we are talking about inlined content (also now 
formally defined), so we have the option to use those terms now, and/or to 
refer to 4.10.2 Use with Care's provenance paragraph.  Given the 
general-case arbitrary relationship between a HTTP request-URI and the 
subject(s) of triples that comprise its state, I'm not sure how a client 
could meet 5.5.3 (it's on the server I realize, but it's the client 
submitting the request). 


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario