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

Hi,

here some comments from the Apache Marmotta (incubating) project:

4.1.8 "LDPR server responses must use entity tags (either weak or strong 
ones) as response ETag header values.": I do not remember the concrete 
resolution of this issues, but I'd prefer to say SHOULD until a standard 
ETag calculation would be specified. And this would be aligned with 
4.4.2 too.

4.2.3: Here I miss a reference to RFC 2616 Section 12 (HTTP/1.1 Content 
Negotiation).

4.4.1: We still think this would be ignored by many implementations, 
since mixing metadata about the resource itself and the server status 
could be a potential conflict, specially because DC Terms is wide-spread 
and used in many applications. Anyway it is fine for us to keep the 
"MAY" there.

4.9: Beside the simple linked list structure for linking pages, maybe 
could be also added there something like "The page resource 
representation MAY have triples with the subject of the page, predicates 
ldp:prevPage, ldp:firstPage or ldp:lastPageof and object being the URL 
for the respective pages."

4.9.2 I think custom page size is out of the spec, so I'd add something 
"Page size MAY be decided by LDPR servers". The same could be applied 
for the name of the parameter to retrieve concrete pages: p, page or 
whatever.

5.3: Personally I find the explanation a bit difficult to read and 
understand. But since I have no better proposal, I'm fine with it. 
Maybe, adding a new paragraph saying something like "LDPC results 
ordering MUST be as defined by SPARQL SELECT’s ORDER BY clause 
[SPARQL-QUERY]" would allow to simplify some of the point in that section.

5.3: What about adding something like "The Client MAY specify the object 
for ldp:containerSortCriteria and ldp:containerSortCriterion."? The 
question is how.

5.3.1: I'd change the link to the example ("as in the example") to refer 
the concrete example, I think example 6. Currently does not work when 
printing.

5.4: For a non-LDPR POSTed to the LDP server, the server may create a
corresponding LDPR. The non-LDPR may Link (HTTP-Header) to it's
associated LDPR using the "meta"-relation - why not add the also an
inverse Link (HTTP Header) using e.g. the "content"-relation?

4.10 & 5.10: We may need more thinking about this feature. It is a cool 
idea, but again mixing resource and server status data. In case of 
having more open questions about this, I'd prefer to keep out.



Find the full thread at http://markmail.org/thread/c3hnbjpet4f5lxde

Sorry, because in the last weeks it has been a bit hard for me to find 
time for contributing the working group. Even if I have some questions, 
I can clearly say the specification has significantly evolved from the 
previous draft published.

Best,
Sergio

On 15/07/13 20:22, Steve Speicher 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
>

-- 
Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at

Received on Friday, 19 July 2013 13:01:22 UTC