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] From: Martin Nally <[email protected]> To: [email protected] Cc: [email protected], [email protected] Date: 03/18/2011 10:59 PM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 14, Issue 13 Sent by: [email protected] 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>. 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] > > > > _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
