[OSLC] resource: storage vs representation--specifying variations in the form of the return from a GET

Cory Casanave cory-c at modeldriven.com
Mon Jan 18 17:19:55 EST 2010


The assumption being made below is that all information about a
particular resource resides in a singular data set.  This then "closes
the world" and does not provide a mechanism for other views or opinions
about said underlying resource.  The general thinking in the semantic
web is that we want to plan for an open world where anyone can say
anything about anything, anywhere.

 

There is a general confusion in web resources as to identities - which
can be the identity of a thing in the world (like a project) and the
identity of a particular graph of information about that thing in the
world (like a record about that project in a DBMS or XML file).  So when
you do a query you have to know what you are asking for.  Are you asking
for a particular data set's opinion about a process or anything known
about that process across some scope of resources?

 

While the former has been the norm, it is a very restrictive model.  The
second introduces some idea of "content" or "configuration" where the
trusted data sources are known.  So the REST query, if done in such a
context, should return all the information about a logical resource
across all of the data sets trusted in that context.  The way to
identify such a context or configuration would seem to be a potential
value-add for OSLC.

 

Note: I have not participated in this group but have been watching for a
few weeks.  I am quite active in the OMG effort that has goals similar
to OSLC, the "architecture ecosystem SIG" - 
http://www.omgwiki.org/architecture-ecosystem (AE SIG). We also have
open source technologies for architecture integration on
ModelDriven.org.

 

Regards,

Cory Casanave

Model Driven Solution

ModelDriven.org

OMG Board of Directors and Chair of AE SIG.

 

________________________________

From: community-bounces at open-services.net
[mailto:community-bounces at open-services.net] On Behalf Of Martin Nally
Sent: Monday, January 18, 2010 1:00 PM
To: Geoffrey M Clemm
Cc: community at open-services.net; community-bounces at open-services.net;
Andrew J Berner
Subject: Re: [OSLC] resource: storage vs representation--specifying
variations in the form of the return from a GET

 

I agree that accept headers are often the right solution, but it's less
clear to me that it's the right way to handle the example that Andy
brings up. Ideally, accept headers would only be used to choose between
representations that are equivalent, like XML, JSON and N3. A quartile
approximation of a distribution is not equivalent to a percentile
approximation - if I use PUT to update the distribution through the
quartile approximation, I will not subsequently be able to GET the
percentile representation and retrieve a useful result. If I were doing
Andy's example, I would create an URL for the distribution, and a
separate URL for quartile and percentile approximations of it, rather
than using content negotiation. the URLs might be <distributionURL> and
<distributionURL>?samplingRate=4 and <distributionURL>?samplingRate=100
or something,

By the reasoning above, you would conclude that we should not have used
content negotiation for the "compact" resource format used for fly-over
help (I forget the right name for these). If we were doing that over, I
would recommend using a different URL, not accept headers

Best regards, Martin

Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: (949)544-4691


 Geoffrey M Clemm---01/17/2010 07:54:12 PM---With HTTP, one requests a
variant of the representation with the ACCEPT header.

 
From:

 
Geoffrey M Clemm/Lexington/IBM at IBMUS


To:


Andrew J Berner/Dallas/IBM at IBMUS


Cc:


community at open-services.net, community-bounces at open-services.net


Date:


01/17/2010 07:54 PM


Subject:


Re: [OSLC] resource: storage vs representation--specifying variations in
the form of the return from a GET


Sent by:


community-bounces at open-services.net

________________________________





With HTTP, one requests a variant of the representation with the ACCEPT
header.
If one cannot encode the variant information in the ACCEPT header, I
suppose one could define a URL parameter for it. 

Cheers, 
Geoff 

From: 

Andrew J Berner/Dallas/IBM at IBMUS 

To: 

community at open-services.net 

Date: 

01/17/2010 06:04 PM 

Subject: 

[OSLC] resource: storage vs representation--specifying variations in the
form of the return from a GET 

Sent by: 

community-bounces at open-services.net

 

________________________________





An issue that has come up in several of the workgroups I'm attending:
The
storage of a resource may be very different from the XML representation
of
the resource you GET from the URL.  The spec defines the representation
you
GET and PUT, not the underlying storage mechanism.  The XML
representation
specified in the OSLC spec may be derived by the server from the data
stored.

This raises a question about the spec:  Have we been specifying ways of
GETting alternate representations of the same resource?  I'm wondering
if
there shouldn't be a somewhat standardized way to do this, although the
specifics will be resource dependent.

As I look over some of the specs, it seems we are defining a single XML
format for each resource.  In some cases, that may make sense--the
resource
IS the XML document.  But in other cases, the resource is more abstract.
Even if we expect the stream returned by an OSLC GET call to always be
an
XML document, there may be variations in the XML representation of a
particular resource that could be important to be specified by the
request.

One example of this is will show up in the Estimation OSLC spec: the
representation of estimated duration (or other key metrics) of a
project.
It's not a single number, but rather a probability distribution, so you
can
say the probability of completing the project in that amount of time.
It's
a formalized representation of something like this:  "it's 50% likely we
can complete it in 24 months, but if you want to be 75% confident, plan
for
35 months and it's barely possible it could take over 4 years.  There's
a
25% chance you can get lucky and finish in 16 months, but the 12 month
schedule you asked for is impossible!  The least it will be is 14
months."

Although "probability distribution" is an abstract mathematical
construct,
the XML representation that will be in the estimation OSLC spec is a
quantile representation, which will be "good enough" for consumers.  It
will be an XML representation of some of the values of the probability
distribution, but it can be at various granularities.  It will list the
values of the distribution for evenly spaced percentages as a sequence
of
values in the XML document--the client can figure out which percentage
each
represents based on the number of elements and the order of the
elements.
Here's an example of the informal description above, based on a similar
example from the WIKI:

          <ems:QuantileFunction

    ems:metric="http://open-services.net/software-metrics/duration
<http://open-services.net/software-metrics/duration> "
             ems:unitOfMeasure="month" ems:numberOfQuantiles="4">
             <ems:low>14</ems:low>
             <ems:quantile>16</ems:quantile>
             <ems:quantile>24</ems:quantile>
             <ems:quantile>35</ems:quantile>
             <ems:high>50</ems:high>
          </ems:QuantileFunction>


Now, for some purposes, a client may want a representation of the
distribution at a fairly high granularity, like the one above, at the
25%,
50% and 75% probabilities, maybe to get a ballpark of how risky the
schedule will be.  For other purposes, a client may want a
representation
at a detailed granularity, getting each percentage probability, perhaps
to
answer the question, "what's the probability I can finish by Dec 1?" and
get an answer like "68%".  I'll spare you the similar but much longer
XML
representation of the same resource (the probability distribution) but
with
100 quantiles  :-).

This is just an example; I suspect each workgroup has examples like
this,
where there can be different levels of detail or other variations
returned
by a GET, all formatted by the interface provider from the same abstract
resource.  It's related, but not quite the same I think, as the standard
issue of "partial retrieves" in queries (which I've started to hear
described as the "shape of the returned set").  So there needs to be a
way
for the consumer to negotiate with the provider, or, more simply, just
tell
the provider how the consumer wants the resource represented, even if
all
the representations are in XML.

Even though the "choices" of representation are resource dependent (e.g.
"number of quantiles" for a probability distribution), is there a
general
technique we'll use in the various OSLC specs to specify requested
variations?

Andy Berner
Lead Architect, ISV Technical Enablement and Strategy
IBM Rational Business Development
972 561-6599
ajberner at us.ibm.com

Ready for IBM Rational software partner program -
http://www.ibm.com/isv/rational/readyfor.html
<http://www.ibm.com/isv/rational/readyfor.html> 


_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net
<http://open-services.net/mailman/listinfo/community_open-services.net> 

_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100118/bed38c76/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 73 bytes
Desc: image003.gif
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100118/bed38c76/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 73 bytes
Desc: image002.gif
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100118/bed38c76/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100118/bed38c76/attachment-0002.gif>


More information about the Community mailing list