[oslc-core] Pagination

Tue Mar 22 14:27:15 EDT 2011

> Pagination solves the problem that a resource
> is large and I don't want to get it all in one response.

What makes pagination of the (latest proposed) ChangeLog different, is that
the "resource is NOT large", it's actually quite small, although it
includes a reference to another resource, which happens to be the start of
linked list of resources, which collectively represent the ChangeLog. The
ChangeLog data graph, not the resource, is what's large.

Normally, and consistent with Martin's definition, paging has been used to
break up the contents of a single resource, and in fact, it's most useful
when that content is a large number of values of a single multi-valued
property, like rdfs:members in the queryBase case.

Once the thing being paged spans multiple resources, it almost doesn't seem
to fit the same model. Now, instead of "resource paging", we're talking
about "data graph paging", and in our case, more specifically, "linked-list
data graph paging". Maybe, as Dave suggested, the OSLC core spec needs to
describe the places where paging can/should be expected?

Frank.

oslc-core-bounces at open-services.net wrote on 03/22/2011 11:02:45 AM:

> [image removed]
>
> Re: [oslc-core] Pagination
>
> Martin Nally
>
> to:
>
> oslc-core
>
> 03/22/2011 11:08 AM
>
> Sent by:
>
> oslc-core-bounces at open-services.net
>
> Cc:
>
> oslc-core, oslc-core-bounces
>
> >> 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
> >
> >
> >
> >
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110322/c711e7f8/attachment-0003.html>