Updates in the Editor's Draft

Dear all,

After reviewing the current version of the Editor's Draft, I have some 
comments.

In this email I include those related to rewriting sentences, which I 
suppose will not raise discussion, but would improve the document (i.e., 
these are changes that an editor can make in a future version of the 
document and would not significantly change the content).

4.1.10. I find the text quite confusing; this was also mentioned 
previously by Steve Speicher (6 July) and Leigh Dodds (11 July).
I understand it as: "links between resources MUST be represented using 
RDF triples", but I'm lost with the part about intermediate link resources.
I propose to rewrite it.

4.1.11. It says that "BPR servers may support additional standard 
representations", but Turtle is not mentioned until 4.2.2.
This restriction should be moved to another place (or move the 
restrictions on representations here).

4.5.1. Minor addition for completeness.
BPR servers must remove the resource identified by the Request-URI "in 
an HTTP DELETE request".

4.5.1. I would move the part related to the status codes on GET over 
non-existing resources to the GET section (4.2), since it is valid for 
any GET request.

4.8.3. rdfs:label is quite frequently used both in vocabularies and 
data. I don't see the benefit of restricting it just for vocabularies.
The need for rewriting this was already raised by Leigh Dodds (14 Jun) 
and Steve Speicher (6 July).

5.2. This section is labeled as non-normative. Is this correct or just a 
mistake?

5.2.4 + 5.2.5. The text could be interpreted as "A BPC MUST contain 1 
(or more) triples".
I would rewrite it saying that "A BPC must contain exactly one triple...".

5.3.4. Replace "The representation for any page, including the first, 
will include the URL for the next page." with "The representation for 
any page, including the first, MUST include the URL for the next page."

5.4.1. This is the only requirement imposed on clients in the 
"Container" part.
Initially, I think that dealing with BPCs instead of with BPRs should 
impose no further restrictions on clients.
I would rewrite it converting it into a BPC server requirement as in the 
rest of the HTTP methods (e.g., 4.4.1):
"If HTTP POST is performed on an existing BPC, BPC servers MUST create a 
resource with the entity representation in the body of the request. BPC 
servers MUST respond with status code 201 (Created) and the Location 
header set to the new resource’s URL."

5.4.9. I would put this as the final sentence of 5.4.8, since it just 
refers to the case of null relative URIs, doesn't it?

5.6.1. This restrictions says the same as 4.5.2. There is no need to 
repeat it for BPCs when it was already said for BPRs.

The terms "property" and "predicate" are used indistinctly in the 
document and in some places their use is mixed (e.j., 4.8 first paragraph).
I would use the term "property" when talking about properties and 
"predicate" when talking about statements.

The document must be reviewed to use consistently the terms "resource" 
and "resource representation".
A resource may not be a native RDF resource (even if it can be an RDF 
resource in some of its representations).
Therefore, I would try to avoid saying things such as "5.2.4 A BPC MUST 
contain one triple for the bp:membershipSubject predicate...".
And say "5.2.4 The representation of a BPC MUST contain one triple for 
the bp:membershipSubject predicate...".
For example, if you compare 5.2.4 and 5.2.7, they both impose 
restrictions on predicates and objects but one talks about the resource 
and the other about the representation.

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 Tuesday, 2 October 2012 14:10:10 UTC