> 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. [email protected] 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: > > [email protected] > > 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 <[email protected]> > > To: Martin Nally <[email protected]> > > Cc: [email protected] > > Subject: Re: [oslc-core] Oslc-Core Digest, Vol 14, Issue 13 > > Message-ID: > > <ofdcc9c20a.a48bf120-on8525785a.004e7f52-8525785b.000d1...@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 > > [email protected] > > > > > > > > > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
