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

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".



Sec 2. Terminology

* (def of LDPC) "representing a collection of (...) triples" -> wouldn't
that be "represented by"

* 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 agree with Raul that 'Page' should probably be defined in this section



Sec 4. LDPR

* "What resource formats should be used" -> s/resource/representation/


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



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.



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)

* 4.4.1 : "with the entitiy representation" -> "with the RDF graph
represented by the entity representation"



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.



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



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.



Sec 5.1 LDPC - Intro

* "the objects of the membership triples define the members of the
container" -> s/define/identify/ ?

* s/resoruces/resources/

* 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/>
  - <.> -> <>

* 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...

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



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..."

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

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

* 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...



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 .

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



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
>