Re: ldp-ISSUE-33 (pagination): how to structure functionality

On 12 Nov 2012, at 18:31, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello ashok.
> 
> On 2012-11-12 8:09 , "Ashok Malhotra" <ashok.malhotra@oracle.com> wrote:
>> FWIW, Odata has a different approach to pagination.
>> LDP suggests a separate URI for each page, for example .../#n
>> OData give you a pointer at the bottom of each page to the next page.
>> Not sure if there is a pointer to the previous page.  Need to check the
>> spec.
> 
> fwiw, rfc5005 does not tell you what the page URIs look like at all, and
> that's how things should be: URIs must be opaque. rfc5005 just says that
> if there is a link to a next page, it can be found following the "next"
> link. whether that points to .../page2 or .../page#2 or ...?page=2 is an
> implementation issue, and clients simply follow whatever link they find
> when they want to GET the next page.
> 
> interestingly, this only works if the semantics are fixed (such as "next
> page"). what this scheme doesn't support is parametrized semantics, such
> as "how to get to page 42". if this was to be supported, the proper web
> way would be to use a URI template, have a parameter in there that
> specifies the page number (which could interoperate with another parameter
> specifying the page size), and then clients could pick the parameter
> values they are interested in, instantiate the URI template, and the
> resulting URI would take them to page 42.

Of course 42 is the answer. But what was the question?

perhaps something like this can be done with POWDER?
The other way I think one could do this is with something like an RDF form.
Thinks of every page as containing a form.
Think of the form as a query to the user. 
Give it semantics: then you can think of a form as a SPARQL query to the user.
That query could be something like "which slice X of the answer do you want?"

then the robot/human can know the vocabulary of the query asked of it, and
can answer by POSTing to the collection.


> 
> for atom, a standardized mechanism for that latter approach (paging++ with
> parameters such as page size and random access to pages) does not exist
> (yet), but we're actively working towards such a thing. the current idea
> is that it uses and extends rfc5005, and then uses rfc6570 to define
> parameters that clients can use to compose meaningful URIs at runtime,
> purely based on runtime information found in URI templates.
> 
> cheers,
> 
> dret.
> 
> 

Social Web Architect
http://bblfish.net/