Re: reviewing SHOULD and MUST in LDP paging

On Mon, Jul 15, 2013 at 5:45 PM, Ted Thibodeau Jr <tthibodeau@openlinksw.com
> wrote:

> All --
>
> Regarding "4.9.2 HTTP GET"
> at
> <https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#http-post-1>
>
> 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".
>
> 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
>
> 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>
>       .
>
> ======
>

I tried out this suggestion and agree it is an improvement in organization
so I made the change.  Though I didn't accept your last rewrite for *.4.3
as it introducing new inferencing language that I think we may not want
here.

In summary, here's the section changes:
  4.10.2.5->4.10.2.4.3
  4.10.2.6->4.10.2.4.1
  4.10.2.7->4.10.2.4.2

- Steve Speicher


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