[oslc-core] Oslc-Core Digest, Vol 14, Issue 13
Frank Budinsky
frankb at ca.ibm.com
Tue Mar 22 11:40:53 EDT 2011
Hi Dave,
> 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 version in the proposal document is obsolete, and hasn't been updated
yet. We used to break up the ChangeLog list into multiple (nil terminated)
lists, one per page. This is what Martin proposed changing last week, and
we've been discussing ever since. Once we settle on a final design, I'll
update the document.
Thanks anyway, for reviewing the doc! It's pretty funny how obsolete a
document dated Mar 16 can already be :-)
Frank.
oslc-core-bounces at open-services.net wrote on 03/21/2011 10:22:45 PM:
> [image removed]
>
> Re: [oslc-core] Oslc-Core Digest, Vol 14, Issue 13
>
> Dave Steinberg
>
> to:
>
> Martin Nally
>
> 03/21/2011 10:26 PM
>
> Sent by:
>
> oslc-core-bounces at open-services.net
>
> Cc:
>
> oslc-core
>
> 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
> davidms at ca.ibm.com
>
>
> [image removed] Martin Nally ---03/18/2011 10:59:46 PM---Your
> solution looks attractive in this case, but I don't think it
> generalizes very well. Here are so
>
> [image removed]
> From:
>
> [image removed]
> Martin Nally <nally at us.ibm.com>
>
> [image removed]
> To:
>
> [image removed]
> oslc-core at open-services.net
>
> [image removed]
> Cc:
>
> [image removed]
> oslc-core at open-services.net, oslc-core-bounces at open-services.net
>
> [image removed]
> Date:
>
> [image removed]
> 03/18/2011 10:59 PM
>
> [image removed]
> Subject:
>
> [image removed]
> Re: [oslc-core] Oslc-Core Digest, Vol 14, Issue 13
>
> [image removed]
> Sent by:
>
> [image removed]
> oslc-core-bounces at open-services.net
>
>
>
>
> 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
>
>
> oslc-core-bounces at open-services.net 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:
> >
> > oslc-core-bounces at open-services.net
> >
> > Please respond to oslc-core
> >
> > Send Oslc-Core mailing list submissions to
> > oslc-core at open-services.net
> >
> > 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
> > oslc-core-request at open-services.net
> >
> > You can reach the person managing the list at
> > oslc-core-owner at open-services.net
> >
> > 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 <davidms at ca.ibm.com>
> > To: oslc-core at open-services.net
> > Subject: Re: [oslc-core] Updated ChangeLog Proposal
> > Message-ID:
> >
<OF839ABEF9.6883E059-ON85257857.007318F9-85257857.007B27F5 at 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
> > davidms at ca.ibm.com
> >
> >
> >
> >
>
>
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110322/12c878a8/attachment-0003.html>
More information about the Oslc-Core
mailing list