Re: reviewing SHOULD and MUST in LDP paging

On Jul 16, 2013, at 07:31 AM, Steve Speicher wrote:

> 
> On Mon, Jul 15, 2013 at 5:45 PM, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:
>> Regarding "4.9.2 HTTP GET"
>> at
> 
> <https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-PagingGET>
>  
>> Following comments use the renumbering which came after
>> today's call...
>> 
>> a. In 4.9.2.1  and 4.9.2.2, "section 4.8" should change to
>>    "section 4.9".
> I'm not seeing this problem.  Perhaps you had an early or cached copy.  Do you still see these problems?

These two have been corrected since my review.


>> b. subsections 4.9.2.5 through 4.9.2.7 should be nested one
>>    deeper -- i.e., renumbered to 4.9.2.4.1 through 4.9.2.4.3
> 
> Likewise, I'm not seeing these.

These remain.  The end of 4.9.2.4 is "such that:" which should
lead into bullets or otherwise more deeply nested sections, so
there's a definite end to that requirement list, which I believe 
to be all three subsections that currently follow within 4.9.2 
(i.e., the current 4.9.2.5 to 4.9.2.7).


>> c. I think excerpting the relevant triples from the complete
>>    example in 4.9, under each sub-section, will help *greatly*
>>    in comprehension and correct adoption.  Also, if we're going
>>    to mandate an "rdf:type" predicate, then any examples should
>>    display that -- not the sugared "a" predicate.
>> 
>> d. The mix of MUST and SHOULD definitely feels off in these
>>    three subsections, which I think is due to their ordering,
>>    not to any of these MUST/SHOULD being incorrect.  I suggest
>>    the following substitution for the current 4.9.2.5 through
>>    4.9.2.7 --
>> 
>> ======
>> 4.9.2.4.1  The page resource representation MUST have one triple
>>          with the subject of the page, predicate of ldp:nextPage
>>          and object being the URL for the subsequent page.
>> 
>>    <http://example.org/customer-relations?firstPage>
>>          ldp:nextPage  <http://example.org/customer-relations?p=2>
>>       .
>> 
>> 4.9.2.4.2  The last page resource representation MUST have one
>>            triple with the subject of the last page, predicate
>>            of ldp:nextPage and object being rdf:nil.
>> 
>>    <http://example.org/customer-relations?p=2>
>>          ldp:nextPage  rdf:nil
>>       .
>> 
>> 4.9.2.4.3  Given the presence of the ldp:nextPage triples
>>            described above, an LDP client could infer that
>>            each page containing such *is* in fact an ldp:Page,
>>            but this does not guarantee the URI of the resource
>>            which description is being paged over.  Therefore,
>>            to lower the burden on LDP clients and increase data
>>            fidelity, the page resource representation SHOULD
>>            include two additional triples: one to indicate its
>>            type, whose subject is the URL of the page, whose
>>            predicate is rdf:type and object is ldp:Page; and
>>            one to indicate the LDPR which description is being
>>            paged, whose subject is the URL of the page, predicate
>>            is ldp:pageOf, and object is the URL of the LDPR.
>> 
>>    <http://example.org/customer-relations?firstPage>
>>            rdf:type  ldp:Page
>>       ;  ldp:pageOf  <http://example.org/customer-relations>
>>       .
>> 
> ======
> These all seem reasonable to me.

I hope that clarifies...

Regards,

Ted



--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
         10 Burlington Mall Road, Suite 265, Burlington MA 01803
     Weblog   -- http://www.openlinksw.com/blogs/
     LinkedIn -- http://www.linkedin.com/company/openlink-software/
     Twitter  -- http://twitter.com/OpenLink
     Google+  -- http://plus.google.com/100570109519069333827/
     Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers