Your solution looks attractive in this case, but I don't think it generalizes very well. Here are some examples to show why.
First, lets assume in your example that the URL of page1 is https://.../ChangeLog>?oslc:paging=true. The URL of your page2 is https://.../ChangeLog/b4. Lets extend the example to include a b5. I'm guessing your approach would be to extend https://.../ChangeLog/b4 to look like this @prefix oslc: <http://open-services.net/ns/core#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix : <https://.../ChangeLog/>. :b4 rdf:first [ a oslc:create ; oslc:changed <https://.../com.ibm.team.workitem.WorkItem/20> ; oslc:at "100"^^xsd:int ]; rdf:rest :b5 . :b5 rdf:first [ a oslc:create ; oslc:changed <https://.../com.ibm.team.workitem.WorkItem/20> ; oslc:at "99"^^xsd:int ]; rdf:rest rdf:nil . Now ask yourself "what sort of a beast is https://.../ChangeLog/b4 ?". We know something about b4 already from RDF - in particular we know that b4 is an rdf:List. We know that from this definition, particularly the line in red. <rdf:Property rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#rest";> <rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/> <rdfs:label>rest</rdfs:label> ? <rdfs:comment> The rest of the subject RDF list after the first item. </rdfs:comment> <rdfs:domain rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#List"/> <rdfs:range rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#List"/> </rdf:Property> When we look at the representation of b4, we see the triples :b4 rdf:first ... and :b4 rdf:rest which is pretty consistent with what you would expect to find in the representation of an RDF List. However, we also see :b5 rdf:first ... and :b5 rdf:rest which is information about a different list. What sort of beast is this that contains information about 2 different lists? It isn't looking like a simple list any more - it must be something else, something more complicated. It actually looks as though it's trying to be a list and a page at the same time - a bit of a mushy sort of thing. RDF permits a resource to have two types at the same time, but that doesn't necessarily make it a good idea. Lets extend the example further. Lets assume that a changeLog has two lists, a list of changes and list of errors - proposed changes that were rejected because they failed validation for security or content. The changeLog also has 100 properties of its own. So now https://.../ChangeLog> ?oslc:paging=true is going to look like this: <https://.../ChangeLog> oslc:changes :b1. :b1 rdf:first [ a oslc:create ; oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ; oslc:at "103"^^xsd:int ] ; rdf:rest :b2 . :b2 rdf:first [ a oslc:update ; oslc:changed <https://.../com.ibm.team.workitem.WorkItem/22> ; oslc:at "102"^^xsd:int ] ; rdf:rest :b3 . :b3 rdf:first [ a oslc:delete ; oslc:changed <https://.../com.ibm.team.workitem.WorkItem/21> ; oslc:at "101"^^xsd:int ] ; rdf:rest :b4 . <https://.../ChangeLog> oslc:changeErrors :e1. :e1 rdf:first [ #stuff here ] ; rdf:rest :e2 . :e2 rdf:first [ #stuff here ] ; rdf:rest :e3 . :e3 rdf:first [ #stuff here ] ; rdf:rest :e4 . <https://.../ChangeLog> <changeLogProp1> value1. <https://.../ChangeLog> <changeLogProp2> value1. <https://.../ChangeLog> <changeLogProp3> value1. <https://.../ChangeLog> <changeLogProp4> value1. <https://.../ChangeLog?oslc:paging=true> oslc:nextPage <https://.../ChangeLog/page2>. A client faced with this more complex example now has to chase down three different "continuation resources". The rest of the changes list is to be found at https://.../ChangeLog/b4 which is one of these "I'm a list node and a page too" resources. The rest of the errors list is at https://.../ChangeLog/e4, which is another of these "I'm a list node and a page too" resources, and the remaining properties of https://.../ChangeLog are at https://.../ChangeLog/page2, which is a Page. This doesn't look very attractive to me. By contrast, the OSLC paging design has simple consistent concepts and generalizes well. Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: +1 (714)472-2690 [email protected] wrote on 03/18/2011 06:25:24 PM: > [image removed] > > Oslc-Core Digest, Vol 14, Issue 13 > > oslc-core-request > > to: > > oslc-core > > 03/18/2011 06:27 PM > 4 > Sent by: > > [email protected] > > Please respond to oslc-core > > Send Oslc-Core mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Oslc-Core digest..." > > > Today's Topics: > > 1. Re: Updated ChangeLog Proposal (Dave Steinberg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 18 Mar 2011 18:25:11 -0400 > From: Dave Steinberg <[email protected]> > To: [email protected] > Subject: Re: [oslc-core] Updated ChangeLog Proposal > Message-ID: > <of839abef9.6883e059-on85257857.007318f9-85257857.007b2...@ca.ibm.com> > Content-Type: text/plain; charset="us-ascii" > > > Hi, > > Forgive the interjection. Marcelo Paternostro and I have been lurking on > and discussing this thread. We've implemented an RDF-based system together > and are now tasked with moving it to an OSLC solution. We're looking at the > OSLC specs pragmatically from the consumer's point of view, and hopefully, > more often than not, we'll be able to ask some thought-provoking questions > here. And so, we thought it might be helpful to share our reaction to this > discussion. > > To be honest, we've never really understood the general applicability of > the paging technique defined by the Core spec. We do see that providing > data in manageable quantities is an important concern, but it seems to us > that it's not necessarily obvious how to best carve up data in such a way > that it still remains meaningful in any given case. We'd think it should be > incumbent upon anyone who wishes to use this mechanism to carefully > consider how it would be applied to particular RDF models. > > So, it's nice to see this discussion of a concrete application of paging. > This case, where information is conveyed by a long, ordered list, certainly > seems to be one that lends itself to being broken up like this. But another > thing we've noticed about this case is that the list itself could be > considered sufficient to convey the paging. Once we've added addressable > identities to the entries in the list, the client could recognize the case > where the object of an rdf:rest is not rdf:nil and is not the subject of > any other statements, and simply do a GET on its URI to obtain the next > "page." > > If the client can be counted on to do this, the OSLC paging statements just > disappear from Frank's example. The simplified version looks like this > (note that I've also switched ChangeLog prefix to use a slash): > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> PAGE 1 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > @prefix oslc: <http://open-services.net/ns/core#> . > @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . > @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . > @prefix : <https://.../ChangeLog/>. > > <https://.../ChangeLog> oslc:changes :b1. > :b1 rdf:first > [ a oslc:create ; > oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ; > oslc:at "103"^^xsd:int > ] ; > rdf:rest :b2 . > :b2 rdf:first > [ a oslc:update ; > oslc:changed <https://.../com.ibm.team.workitem.WorkItem/22> ; > oslc:at "102"^^xsd:int > ] ; > rdf:rest :b3 . > :b3 rdf:first > [ a oslc:delete ; > oslc:changed <https://.../com.ibm.team.workitem.WorkItem/21> ; > oslc:at "101"^^xsd:int > ] ; > rdf:rest :b4 . > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> PAGE 2 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > @prefix oslc: <http://open-services.net/ns/core#> . > @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . > @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . > @prefix : <https://.../ChangeLog/>. > > :b4 rdf:first > [ a oslc:create ; > oslc:changed <https://.../com.ibm.team.workitem.WorkItem/20> ; > oslc:at "100"^^xsd:int > ]; > rdf:rest rdf:nil . > > Does this approach sound reasonable, or does the paging mechanism add > something here? > > Cheers, > Dave > > -- > Dave Steinberg > IBM Rational Software > [email protected] > > > >
