[oslc-core] Pagination

Tue Mar 22 11:02:45 EDT 2011

>> The extreme example would be burying a label for the changelog on the
hundredth page.

Pagination is not the mechanism for handling this use-case. One option for
handling this use-case is called "selective properties" in the OSLC Core
spec. It would use a GET on <url>?oslc.properties=rdfs:label. Pagination
solves a different problem. Pagination solves the problem that a resource
is large and I don't want to get it all in one response. A classic
application is pagination of a query result. I want to get it in pages,
perhaps because I want to display the pages incrementally to a user and I
do not want to have to get the whole thing before I display the first page
of results. If we used pagination for ChangeLog (not the current design) it
would represent a slight twist on this, because we'd be asking the server
to match the content of pages to the list structure of a property so I can
truncate fetching pages without going all the way to the end. If we thought
a it harder about it, we could probably express a general rule for how list
structure of property values should influence page content.

>> Moreover, it could actually require caching the entire model of each
page

I don't know what a "model" is, but I think I know what you mean. If your
use-case is that you need to see all the triples of a resource to process
its meaning - for example by displaying a graph of blank nodes and links
that spans the whole representation of the resource - then pagination will
not help you. Your problem is that, unlike with the query results example,
you cannot make sense of information on the first page without seeing the
information on subsequent pages. You might as well just GET the whole
resource, or alternatively you might be able to use query to get some
subset that allows you to display the graph.

Best regards, Martin

Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690

> ------------------------------
>
> Message: 3
> Date: Mon, 21 Mar 2011 22:22:45 -0400
> From: Dave Steinberg <davidms at ca.ibm.com>
> To: Martin Nally <nally at us.ibm.com>
> Cc: oslc-core at open-services.net
> Subject: Re: [oslc-core] Oslc-Core Digest, Vol 14, Issue 13
> Message-ID:
>    <OFDCC9C20A.A48BF120-ON8525785A.004E7F52-8525785B.000D119F at ca.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Hi Martin et al.,
>
> Thanks for considering our idea and for the thoughtful reply. I should
say
> again that my line of discussion here stems from our general lack of
> comfort with the all-purpose paging mechanism in OSLC Core. We've been
> trying to think about where paging does and doesn't make sense from the
> consumer perspective. Since it comes up in your more complicated
changelog
> example, maybe I'll jump to that matter first.
>
> It seems to us that the additional properties (changeLogProp1,
> changeLogProp2, etc.) don't play well with paging in general. How does
the
> provider know which properties will matter most to a particular client in
a
> particular scenario, and how many GETs should a client have to do in an
> attempt to obtain values for the properties it cares about? The extreme
> example would be burying a label for the changelog on the hundredth page.
A
> less extreme, more complicated example would be if a client needs to make
> use of a particular subset of statements to represent some information
> graphically. These properties could be spread across pages, which would
> necessitate caching. Moreover, it could actually require caching the
entire
> model of each page if the object of such a statement was a resource.
>
> In our opinion, lists are also not good candidates for use with paging
> because they intrinsically support being split across multiple models.
That
> said, you raised two very good points:
>
> 1. It is true that, in the solution I proposed, doing a GET on
> https://.../ChangeLog/b4 would yield statements about not just that
> resource but also about https://.../ChangeLog/b5,
https://.../ChangeLog/b6,
> etc. However, I don't think that including these additional statements in
> the representation yielded means that resource isn't a simple list
anymore.
> There are no additional statements anywhere that make it any more or less
> list-like than when we started giving it an identity. Rather, I'd say
that
> with this approach, we have to deal with a question that's not uncommon
> with REST and RDF: when I service a GET on resource A, can/should I
include
> statements about other objects that are closely related to A and if so,
> which ones/how many?
>
> 2. We hadn't thought about the situation in your last example, with the
two
> different lists in a changelog before, but it's an interesting one. If we
> assume that the additional properties aren't going to be split up (for
the
> reasons discussed above), the problem is reduced to two lists, each with
> its own URI from which further entries can be retrieved. It seems to me
> that's not a bad situation at all, especially if you're a client that's
> only interested in one of those lists (and can possibly do fewer GETs as
a
> result).
>
> The place where we do see the need for the paging mechanism is with
> containers and with multiple statements that share the same subject and
> predicate. Both of these are conceptually similar to a list, but they
have
> no intrinsic support for splitting values across models.
>
> Do these thoughts make sense to anyone else? We thought we'd put them out
> there, and if they do, maybe it would be possible to improve the core
spec
> by including limits on where clients can expect the paging mechanism to
be
> used. As well, perhaps other specs could be more specific in where they
use
> the mechanism and how graphs are expected to be split up.
>
> On another note, I noticed that in the latest version of the Indexing
> proposal that I saw, the changelog example with paging is different from
> the version that was discussed in this thread in that the paged version
of
> the URI (https://.../ChangeLog?oslc.paging=true) is used in the subject
of
> the oslc:changes statement. I'd expect it would be the basic URI
> (https://.../ChangeLog), and that's what has been used in this thread. I
> thought I'd point that out just in case it's a mistake that hasn't been
> corrected yet.
>
> Cheers,
> Dave
>
> --
> Dave Steinberg
> IBM Rational Software
> davidms at ca.ibm.com
>
>
>
>