- From: Steve Speicher <sspeiche@gmail.com>
- Date: Wed, 17 Jul 2013 16:46:28 -0400
- To: Raúl García Castro <rgarcia@fi.upm.es>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CAOUJ7JrhrDaKCHotVGofy1ypytxsZQgwRWWtKWWqXV3L9SXJSQ@mail.gmail.com>
On Wed, Jul 17, 2013 at 11:30 AM, Raúl García Castro <rgarcia@fi.upm.es>wrote: > 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<https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html> >> [2] - https://dvcs.w3.org/hg/ldpwg/**raw-file/default/ldp.ttl<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<https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-diff-20130715.html> >> > > Dear Steve and John, > > Hi Raúl, You'll find embedded clarifications and various +1's where I made changes based on your suggestions. Others there are suggestions in here (first section of email) that would be good to get additional feedback on. - Steve Speicher > The document and the specification have significantly improved. > Thanks for the feedback and comments. > > 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? > Seems reasonable to me. How about? Page resource - An HTTP resource whose representation is a subset of the triples in an 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. > 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): 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 > > 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. > > 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. > Other things (change or ignore them): > > Abstract > -------- > A set of best practices > -> > This document describes a set of best practices > +1 > > 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". > +1 > > 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 > I've just been carrying over Tim's typo, removed. > > 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) > just linked it > > of faculty members. Each faculty member > -> > of faculty members, each faculty member > +1 > > the POST operation. See section 5.4 . > -> > the POST operation (see section 5.4). > +1 > > any subsequent page. See section 4.9 . > -> > any subsequent page (see section 4.9). > +1 > > Terminology > ----------- > and conventions in the section 4. . > -> > and conventions in section 4. > +1 > > The response page may or may not include > -> > The response representation? may or may not include > +1 > > 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. > Adding to editor's backlog if can get to it. > > 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) > +1 > > 4.3 > and [HTTP11] makes it optional > -> > and [HTTP11] makes it optional. > +1 > > 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 > +1 > > 4.6 > carefully read section 4.2 . > -> > carefully read section 4.2. > > defined in section 4.8 . > -> > defined in section 4.8. > Add to backlog, respec is introducing this. > > 4.9.1 > ttp:// > -> > http:// > +1 > > there is only two > -> > there are only two > +1 > > 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) > +1 > > 5.1.1 > The first paragraph talks about inlining but without referring to the > previous inlining section. > going to leave as-is since inlining as at risk > > 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. > +1 > > 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". > We define it in terminology > > 5.2.4 An LDPC MUST > -> > 5.2.4 An LDPC representation MUST > +1 > > 5.2.5 An LDPC MUST > -> > 5.2.5 An LDPC representation MUST > +1 > > 5.2.8 LDPCs SHOULD NOT > -> > 5.2.8 LDPC representations SHOULD NOT > +1 > > 5.4.4 > servers may allow the creations of LDPCs > -> > servers MAY allow the creation of LDPCs > (2 changes) +1 > > 5.4.11 and 5.5.4 > I would remove them, do not add anything new from 5.2.9 > No change as I see John intentionally did this. > > > 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 >
Received on Wednesday, 17 July 2013 20:46:55 UTC