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

On Mon, Jul 15, 2013 at 11:52 AM, John Arwe <johnarwe@us.ibm.com> wrote:

> 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.
>
> No action taken, see Arnaud's note.

*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.
>
> No action taken, will leave for BP doc.

>
> *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.
>
>
Fixed up ldpr-HTTP_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.
>
Changed LDPR to page resource


> 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.
>
> Fixed already

>
> 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.
>
> No action taken, due to lack of cycles.  Added to editor backlog/todo.

>
> 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).
>
Changes made:
5.5.1 normative reference to membership triples
5.5.3 normative reference to member inlining

Thanks,
Steve Speicher

>
> Best Regards, John
>
> Voice US 845-435-9470  BluePages<http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
> Tivoli OSLC Lead - Show me the Scenario
>
>