[oslc-core] Pagination

[Martin Nally]

> I think we need to rule out option #2 because OSLC paging won't work
> with fragments. The problem is when the server initiates paging
> (with a 301 redirect), because the ChangeLog is too big, GET
> <changeLog>#fragment may only return the first 100, say, and that
> may not even include the resource being requested.

I'm not emotionally attached to #2, but I don't think this is a good reason
to reject it - you are shifting the requirements back and forth. Where we
started was with the linked list of changelog page resources, each of which
held a list of change entries expressed using blank nodes. In this design,
the individual entries were explicitly not addressable - they did not have
URLs. Design #2 was not introduced to allow individual entries to be
addressed and fetched, it was only introduced to show that with a minor
change we could paginate the change log using the standard OSLC pagination
algorithm instead of introducing new pagination concepts. You now reject
this design because it doesn't support fetching an individual entry, but
then you propose instead a different design that doesn't support that
feature either.

I do think that your latest design is an improvement over design #1. Design
#1 used the ?oslc:paging=true URL, but returned something that was not
consistent with what the spec says should be returned for OSLC paging. Your
new design avoids creating the appearance of compatibility with OSLC paging
and then disappointing. Your new design disappoints is a different way -
the resource that said it was the changelog actually isn't - it's only the
first "segment" of the changeLog. That can be easily fixed by avoiding
claiming it's a full changelog in the first place, perhaps like this:

<https://.../ChangeLog?oslc:firstSegement>
  oslc-log:changes (
    [ a oslc-log:Creation ;
      oslc-log:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
      oslc-log:at "103"^^xsd:int
    ]
    [ a oslc-log:Update ;
      oslc-log:changed <https://.../com.ibm.team.workitem.WorkItem/22> ;
      oslc-log:at "102"^^xsd:int
    ]
    [ a oslc-log:Deletion ;
      oslc-log:changed <https://.../com.ibm.team.workitem.WorkItem/21> ;
      oslc-log:at "101"^^xsd:int
    ]) ;
  oslc-log:continuation <https://.../ChangeLog?pageno=2> .

Either this design or design #2 would appear to work fine, so long as
fetching an individual change entry isn't a requirement. #2 has the merit
of being less invention over what we already have, although I think your
design has the merit of being more straightforward.

If fetching individual entries is a requirement, we need something
different from either of these. The following would work:

A GET on  https://.../ChangeLog would produce:

   @prefix oslc: <http://open-services.net/ns/log#> .
   <https://.../ChangeLog> oslc:changes <https://.../ChangeLog/entry103>.

A GET on https://.../ChangeLog/entry103 would look like this

   @prefix oslc:    <http://open-services.net/ns/log#> .
   @prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
   <https://.../ChangeLog/entry103>
      rdf:first
         [a oslc:create ;
          oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
          oslc:at "103"^^xsd:int];
      rdf:rest <https://.../ChangeLog/entry102>.

This gives us the individually-addressable change entries we were looking
for. It also lets you go through the change log in order, but requires lots
of GETs. Since this isn't indexer-friendly, we we would probably need to
introduce https://.../ChangeLog?oslc:withAllReferencedListResources:

   @prefix oslc: <http://open-services.net/ns/log#> .
   @prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
   @prefix : <https://.../ChangeLog#>.
   <https://.../ChangeLog/includeAllListNodesAndEntries> oslc:changes :
   entry103.
   :entry103
      rdf:first
         [a oslc:create ;
          oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
          oslc:at "103"^^xsd:int];
      rdf:rest :entry102.
   :entry102
      rdf:first
         [a oslc:create ;
          oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
          oslc:at "103"^^xsd:int];
      rdf:rest :entry101.
   :entry101
      rdf:first
         [a oslc:create ;
          oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
          oslc:at "103"^^xsd:int];
      rdf:rest rdf:nil.

This resource can be paginated using the normal OSLC rules, but the server
still has to group the triples into pages according to list order to make
it friendly to indexers.

A while ago, Arthur suggested we should avoid lists entirely. We might
revisit this idea. The changelog might look like this:

A GET on https://.../ChangeLog would produce:

   @prefix oslc: <http://open-services.net/ns/log#> .
   <https://.../ChangeLog>
      oslc:change
        [a oslc:Creation ;
         oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
         oslc:at "103"^^xsd:int];
      oslc:change
        [a oslc:Creation ;
         oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
         oslc:at "102"^^xsd:int];
      oslc:change
        [a oslc:Creation ;
         oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
         oslc:at "101"^^xsd:int].

This is paginateable, which is is an improvement over the simplest design
with lists. It still requires a server to group entries into page by
sequence, which is the same. It requires a client to do a local sort within
a page, which might be slightly less nice than following list entry
pointers. If the entries are independent resources, then we still need the
server to provide a special resource that includes the RDF triples for each
of them. Overall, the problems seem similar whether we use lists or not.

Overall I'd vote for dumping the "individual entry addressability"
requirement and go with your updated list design for its simplicity and
directness (but not because the # design fails to provide individual entry
addressability).

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