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

Hi Steve,

El 17/07/13 22:46, Steve Speicher escribió:

[..]

>     Terminology. Should we include some definition of what a "page
>     resource" or a "resource page" is?
>
> Seems reasonable to me. How about?
>
> Page resource -  An HTTP resource whose representation is a subset of
> the triples in an LDPR.

I'm not sure. I suppose that it is an LDPR also, isn't it?
And the representation of a page is not a subset of the resource 
representation, since it includes page-specific triples.
And we should also say that it is a type of resource that appears fully 
inlined in other resource representations.

Anyway, my attempt to improve the definition:

Page resource -  A special type of LDPR that is associated to another 
LDPR and whose representation includes a subset of the triples in the 
associated LDPR.

>     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.
>
> Well it does, indirectly.  If you follow the links from 4.8 it talks
> about 'firstPage'.  Also  4.8 does list explicitly the "Allow" header in
> 4.8.2.  So I feel like we are ok here.

OK.

>     5.5.1 and 5.5.3. Are they not the same? Maybe they can be merged
>     into one
>
> They are not the same, perhaps we need to make the difference more
> obvious.  Let me try to explain the difference (and I had to look
> closely to see it):

That would be good.

> 5.5.1 is about not allowing PUT on LDPC to change membership, that is all.
> For example, removing an asset from the net worth.
>
> 5.5.3 is about not allowing PUT on LDPC to change inlined member data
> For example, change the value of an asset to 200.
>
>
>     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)?
>
> No, these match the resolution of the corresponding issues.  Is there
> something you found that conflicts with a resolution?
 >
> 5.9.1 is optional in that a server may not support non-member properties
> slicing of a LDPC
> 5.9.3 is required as there is no other way for a client to discover the
> relationship

Well, more than a matter of resolutions it is a matter of how things 
appear at the end.

In the case of non-LDPR members, if some server associates them with a 
LDPR its behaviour is clearly defined (with a MUST).

In the case of non-member resources, if some server defines them its 
behaviour is not clearly defined (has a SHOULD) and a client could 
expect other behaviours.
Furthermore, the text says that if the Link header is not present 
clients must assume that the non-member resource does not exist, which 
interprets the SHOULD as a MUST (i.e., there is no other way of 
discovering the relationship).

>     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.
>
> I'm not sure which way would be recommended. Seems that Turtle has it
> as:
> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html#booleans
> I suppose we'd need to update the vocabulary document.

It won't hurt. And, in the specification we could also mention the 
xsd:boolean datatype so it is Turtle-independent.

>     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
>
> I'm for these changes, I think the convention we've been using should
> cause these changes:
> ascending => Ascending
> descending => Descending
> non-member-resource => nonMemberResource
>
> If I don't hear any objections soon, I think we should make the change.

Good.

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 Thursday, 18 July 2013 13:03:33 UTC