[oslc-core] Oslc-Core Digest, Vol 14, Issue 13
Dave Steinberg
davidms at ca.ibm.com
Mon Mar 21 22:22:45 EDT 2011
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
From: Martin Nally <nally at us.ibm.com>
To: oslc-core at open-services.net
Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date: 03/18/2011 10:59 PM
Subject: Re: [oslc-core] Oslc-Core Digest, Vol 14, Issue 13
Sent by: 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110321/e04768aa/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110321/e04768aa/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110321/e04768aa/attachment-0001.gif>
More information about the Oslc-Core
mailing list