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

On Thu, Jul 18, 2013 at 9:03 AM, Raúl García Castro <rgarcia@fi.upm.es>wrote:

> 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).
>
> I have not made any changes for this.

I'm not sure what you are proposing to be changed.  I have an idea but not
sure if this is something that is truly broken (from a normative spec point
of view) or just needs a bit more clarity in editing.


>
>      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<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.
>
> I added this.

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

I didn't hear any objections so I made these changes.

Thanks for the feedback,
- Steve Speicher


>
>
> Kind regards,
>
> --
>
> Dr. Raúl García Castro
> http://delicias.dia.fi.upm.es/**~rgarcia/<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
>