>> 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 <[email protected]> > To: Martin Nally <[email protected]> > Cc: [email protected] > Subject: Re: [oslc-core] Oslc-Core Digest, Vol 14, Issue 13 > Message-ID: > <ofdcc9c20a.a48bf120-on8525785a.004e7f52-8525785b.000d1...@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 > [email protected] > >
