W3C home > Mailing lists > Public > public-ldp-wg@w3.org > July 2013

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

From: Raúl García Castro <rgarcia@fi.upm.es>
Date: Wed, 17 Jul 2013 17:30:05 +0200
Message-ID: <51E6B87D.7080603@fi.upm.es>
To: Steve Speicher <sspeiche@gmail.com>
CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
El 15/07/13 20:22, Steve Speicher escribió:
> 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

Dear Steve and John,

The document and the specification have significantly improved.

One weak point from my point of view is the inlining part: I don't like 
defining ldp:Pages for resource pagination and later tell people that 
ldp:Pages can be used for other "arbitrary" purposes such as inlining. I 
think that we should think more about other alternatives before putting 
that into the specification. Anyway, I can survive with the "At Risk" 
status.

Here you have some comments from my review:

Terminology. Should we include some definition of what a "page resource" 
or a "resource page" is?

4.6.2. "4.6.2 LDPR servers MUST support the HTTP response headers 
defined in section 4.8." But 4.8 does not define the response headers 
that must be supported.

5.5.1 and 5.5.3. Are they not the same? Maybe they can be merged into one

5.9.1. "... LDPC servers that define a non-member resource SHOULD 
provide an HTTP Link header ..." Shouldn't this be a MUST (as in 5.9.2)?

5.10.2.1. We have to clearly define true as "true"^^xsd:boolean (or 
"1"^^xsd:boolean)). I suppose that we are not referring to a literal.

Ontology. Unify naming of individuals (ascending, descending, 
MemberSubject); either all start with a capital letter or none. 
non-member-resource should be a property (it has a domain and a range) 
and should be written following the convention for other properties: 
nonMemberResource

Other things (change or ignore them):

Abstract
--------
   A set of best practices
   ->
   This document describes a set of best practices

Introduction
------------
"It provides some new rules as well as clarifications and extensions of 
the four rules of Linked Data [LINKED-DATA]."
Anyone reading this will expect finding "the fifth rule of Linked Data" 
in the document. I would just say "It provides clarifications and 
extensions..."
Later in the document the term "rule" is also used. Propose to use the 
term "requirement" instead of "rule".

   4. Include links to other URIs. so that they can discover more things
   ->
   4. Include links to other URIs, so that they can discover more things

   that read and write Linked Data.
   ->
   that read and write Linked Data resources (Linked Data Platform 
Resources in this specification).
   (so the term that is used in the next paragraph is introduced)

   of faculty members. Each faculty member
   ->
   of faculty members, each faculty member

   the POST operation. See section 5.4 .
   ->
   the POST operation (see section 5.4).

   any subsequent page. See section 4.9 .
   ->
   any subsequent page (see section 4.9).

Terminology
-----------
   and conventions in the section 4. .
   ->
   and conventions in section 4.

   The response page may or may not include
   ->
   The response representation? may or may not include

The word "canonical" is used twice in the document. Since we do not deal 
with URI canonicalization in the specification, I would remove the word 
and the meaning of the sentences is the same.

4.1.11
   Other specifications built on top of LDP MAY require clients
   ->
   Other specifications built on top of LDP may require clients
   (this is not a restriction on the specification products)

4.3
   and [HTTP11] makes it optional
   ->
   and [HTTP11] makes it optional.

   can be done via section 5.4 or section 5.5 to a LDPC
   ->
   can be done via POST (section 5.4) or PUT (section 5.5) to a LDPC

4.6
   carefully read section 4.2 .
   ->
   carefully read section 4.2.

   defined in section 4.8 .
   ->
   defined in section 4.8.

4.9.1
   ttp://
   ->
   http://

   there is only two
   ->
   there are only two

4.9.2
   "In addition to the requirements set forth in section (HTTP GET)"
   (Put the section number, since there are two GET sections for 
resources and containers)

5.1.1
   The first paragraph talks about inlining but without referring to the 
previous inlining section.

5.1.2 and 5.1.4
   These sections include the text: " This section is non-normative". 
Since section 5.1 is already stated to be non-normative that text can be 
removed (or it should be added to the other subsections).
   Besides, section 5.1.3 does not exist.

5.2.1
   Write the LDPC name in full (Linked Data Platform Container) at the 
beginning of section 5.2. Now LDPC is used before "Linked Data Platform 
Container".

   5.2.4 An LDPC MUST
   ->
   5.2.4 An LDPC representation MUST

   5.2.5 An LDPC MUST
   ->
   5.2.5 An LDPC representation MUST

   5.2.8 LDPCs SHOULD NOT
   ->
   5.2.8 LDPC representations SHOULD NOT

5.4.4
   servers may allow the creations of LDPCs
   ->
   servers MAY allow the creation of LDPCs
   (2 changes)

5.4.11 and 5.5.4
   I would remove them, do not add anything new from 5.2.9


Kind regards,


-- 

Dr. Raúl García Castro
http://delicias.dia.fi.upm.es/~rgarcia/

Ontology Engineering Group
Departamento de Inteligencia Artificial
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19
Received on Wednesday, 17 July 2013 15:30:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 17 July 2013 15:30:29 UTC