>> 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] > > > >
