- From: Raúl García Castro <rgarcia@fi.upm.es>
- Date: Thu, 18 Jul 2013 15:03:07 +0200
- To: Steve Speicher <sspeiche@gmail.com>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
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