[oslc-core] Oslc-Core Digest, Vol 14, Issue 13
Martin Nally
nally at us.ibm.com
Fri Mar 18 22:59:07 EDT 2011
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
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
>
>
>
>
More information about the Oslc-Core
mailing list