[oslc-core] Pagination

[Martin Nally]

Good point, Frank. I think there are 3 cases:

   Obviously, if the list nodes are blank nodes, then they are not
   independent resources - they are just part of the state of the
   changelog. This is simple, but the chagelog is now large and it can't be
   paginated.
   If the list nodes are resources, but they have URLs of the form
   <changeLogURL>#<list node fragment id>, then the list nodes are now real
   resources with URLs, but there is a standard relationship between the
   changelog and the list nodes based on the W3C definition of fragment
   identifiers. Fragment identifiers have always been a bit problematic,
   but the meaning of the relationship is something like "the
   representation of the list nodes will be inside the representation of
   the change log", which is a rather odd sort of relationship, but an
   important one. Now the changeLog is still large (since its
   representation includes the representation of all the list nodes, by
   definition), but it can be paginated using the standard OSLC pagination
   mechanism.
   If the list nodes are resources, but they have URLs of the form
   <changeLogURL>/<list node id>, then the list nodes are now real
   resources with URLs, and there is absolutely zero relationship implied
   by standard web theory between the changelog and the list nodes, or
   between the list nodes themselves. The relationship between them is the
   same as the relationship between martin, martingale and martini - they
   share the same first 6 letters of the name that is all. In this design
   you would expect the changelog resource to be small - the representation
   of the changeLog should reflect the state of changeLog (by theory of the
   WWW), and by adopting this pattern, we have specifically chosen to
   exclude the listNodes from the state of the changeLog itself. In this
   design, we can still invent new resources that include information on
   [the state of] multiple list nodes but these resources are not the
   changelog, and are not the list nodes, and are not the standard "pages"
   defined by the OSLC pagination specification either - they are something
   entirely  new and different.

When I brought this up, I was advocating design 2 because it exploits what
we already have, but given how complex the ensuing discussion has become,
I'm getting discouraged. Maybe the discussion has had value in clarifying
some of the ideas in OSLC paging. Design #1 can't be paginated, and #3 is
something brand new (and subtle), so I think the options are to use #2 or
stick with Frank's original design, which was simple and understandable
although it was new.

Best regards, Martin

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


Frank Budinsky <frankb at ca.ibm.com> wrote on 03/22/2011 02:27:15 PM:

> [image removed]
>
> Re: [oslc-core] Pagination
>
> Frank Budinsky
>
> to:
>
> Martin Nally
>
> 03/22/2011 02:27 PM
>
> Cc:
>
> oslc-core, oslc-core-bounces
>
>
> > 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.
>