[oslc-core] Oslc-Core Digest, Vol 14, Issue 18

[Martin Nally]

>> 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?

I don't like this way of thinking about resources. To me a resource has
state and the representation should reflect that state accurately and
completely, no more and no less. You can have a resource whose
representation includes some of the state of resource A and some of the
state of resource B, but then that is a different resource, distinct from
both A and B which remain simple and faithful to their state.

Best regards, Martin

Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690



> Message: 3
> Date: Mon, 21 Mar 2011 22:22:45 -0400
> From: Dave Steinberg <davidms at ca.ibm.com>
> To: Martin Nally <nally at us.ibm.com>
> Cc: oslc-core at open-services.net
> Subject: Re: [oslc-core] Oslc-Core Digest, Vol 14, Issue 13
> Message-ID:
>    <OFDCC9C20A.A48BF120-ON8525785A.004E7F52-8525785B.000D119F at ca.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> 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
>
>