Re: LDP drafts for review in preparation of Last Call -- deadline July 22

On Fri, Jul 19, 2013 at 8:39 AM, Pierre-Antoine Champin <
pierre-antoine.champin@liris.cnrs.fr> wrote:

> Hi Steve,
>
> here is my review of the editor's draft.
>
> Unfortunately, I won't be on the call next monday to discuss it, but I'll
> try to check my mail if you have any comment/question.
>
>   pa
>
> Sec 1. Intro
>
> * "Containers are very useful in building application models" is not very
> clear. I would add "involving collections of homogeneous resources".
>
> Changed, I see that as an improvement.


>
> Sec 2. Terminology
>
> * (def of LDPC) "representing a collection of (...) triples" -> wouldn't
> that be "represented by"
>
 No change made.  Not sure it improves that much, we previously did a
fairly thorough development and review of this (Cambridge F2F2).  Also
haven't received any other feedback on this.


> * not sure all the "membership*" definitions should appear here... they
> are rather cryptic before reading the section on containers, and are not
> very useful until you get there... may be a definition of "membership",
> giving a brief overview, and pointing to the container section, would be
> enough
>
I see your point but also see the value in having it here for benefit of
normative definitions.


>
> * I agree with Raul that 'Page' should probably be defined in this section
>
Already done.


>
> Sec 4. LDPR
>
> * "What resource formats should be used" -> s/resource/representation/
>
Done


> Sec 4.2 LDPR - HTTP GET
>
> * 4.2.3 : MUST was supposed to be replaced by SHOULD according to the
> resolution of https://www.w3.org/2012/ldp/track/issues/53
>
> Already done, see earlier thread.


>
>
> Sec 4.3 LDPR - HTTP POST
>
> * a restriction should be added to the first sentence: if the LDPR is an
> LDPC, this specification *does* constrain the POST operation.
>
> No change made, 2nd paragraph covers this.


> Sec 4.4 LDPR - HTTP PUT
>
> * shouldn't accepted formats for PUT be specified? like Turtle MUST be
> accepted, other formats MAY be accepted (provided that they have an RDF
> interpretation -- at least in the context of that LDP server)
>
No change made. I'm mixed on this.  It is good to be clear whenever
possible. I'm not recalling details of any previous discussions.  Is this
really a problem?  One can assume if it can fetch the resource in a format,
it should be able to PUT it back if the server supports PUT.


> * 4.4.1 : "with the entitiy representation" -> "with the RDF graph
> represented by the entity representation"
>
> No change made.  We don't really use 'RDF graph' terminology much.


>
> Sec 4.9.1 Paging - Introduction
>
> * "any of its members" -> the notion of member is not really meaningful in
> the general context of LDPR. I would rather rely on the notion of "inlined
> resource", defined in sec. 2.
>
> Changed to "inlined resources" and added terminology reference.


>
> Sec 4.9.2 Paging - HTTP GET
>
> * should 4.9.2.1 and 4.9.2.2 really refer to section 4.9 ; it is strange
> and looks like an artifact of a previous organization of the document
>
> These should be fixed now.


> Sec 4.10 Inlining
>
> * 4.10.3.1 does not specifies any URI for the ldp:Page resource holding
> the ldp:inlinedResource predicates... It is a shame, as it prevents such a
> resource to "talk" about other resources that would happen to have ldp:Page
> (granted, this is a pathological use case, but still). I would suggest that
> the URI of that ldp:Page be either the Request-URI or the value of the
> Content-Location header field. The first option aligns with section 4.9,
> and the second one allows for "transparent" inlining while keeping things
> explicit. Note that clients can still choose to ignore this constraint and
> get their information from the first ldp:Page they find if they don't want
> to dig into the headers.
>
> No change made. Perhaps I'm missing how this isn't covered in (now)
4.11.3.2


>
> Sec 5.1 LDPC - Intro
>
> * "the objects of the membership triples define the members of the
> container" -> s/define/identify/ ?
>
Changed.

>
> * s/resoruces/resources/
>
Changed.

>
> * In exemple 5, either the URI of the resource should end with a '/', or a
> number of relative URIs need to be fixed:
>
>   - <assetContainer/> -> <nw1/assetContainer/>
>   - <liabilityContainer/> -> <nw1/liabilityContainer/>
>   - <.> -> <>
>
Changed.

>
> * In example 5, would this graph actually contain all the <o:asset> and
> <o:liability> triples? I would rather expect the clients to get those from
> each individual container...
>
Example 5 is just showing this as a possibility/optimization, hence the
member/resource inlining part.


>
> * after example 7 : "the membership triple of the form
> (.../assetContainer/, o:asset, .../a1)" -> the subject should rather be
> .../nw1
>
Changed

>
>
>
> Sec 5.2 LDPC - General
>
> * 5.2.2 is strangely stated; I would restate it as is: "LDPC membership is
> not exclusive; this means that the same resource..."
>
Changed.


>
> * 5.2.4 and 5.2.5 : "must contain one triple" -> "must contain *exactly
> one triple" ?
>
Changed.


>
> * 5.2.5.1 and 5.2.5.2 : the last sentence of each of those item is not
> really clear to me
>
On editor backlog

>
>
* 5.2.10 would deserve an illustrative example in section 5.1; I had to
> read it 4 or 5 times to understand it, although I new where this was coming
> from, having followed some the discussions on the mailing list...
>
> On editor backlog

>
> Sec 5.4 LDPC - POST
>
> * 5.4.7 seems to be a consequence of 5.4.8.1 . Also, it is a very special
> case (empty null URI in subject position), which I don't even know how to
> implement with off-the-shelf RDF parsers, so I'm for removing 5.4.7
> alltogether and keeping only 5.4.8.1 .
>
Due to other comments, 5.4.8.1 was moved to general.
No changes to 5.4.7.  I'm not sure about removing altogether, I know I've
been able to implement by computing the base URI and then invoking the
parser.

>
> * 5.4.13 "semantic" should be "semantics" (adj. vs. noun)
>
Changed.

Thanks for the feedback,
Steve Speicher


>
>
>
> On Mon, Jul 15, 2013 at 7:22 PM, Steve Speicher <sspeiche@gmail.com>wrote:
>
>>  In today's teleconference we agreed that we declared the latest working
>> draft [1] as ready for immediate review.  The idea is to gather enough
>> feedback by next Monday (July 22nd) to make a decision on going to Last
>> Call.  We also have published a vocabulary document [2] and HTML diff (from
>> March 7th 2nd PWD) [3].
>>
>>  The editors are still tweaking a few things but most items have been
>> completed.  The sooner that feedback is given the better, if the editors
>> receive a large number of comments late...we may not be able to process in
>> a timely way.
>>
>>  [1] - https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html
>> [2] - https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.ttl
>> [3] -
>> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-diff-20130715.html
>>
>>  - Steve Speicher
>>
>
>