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

Tue Jan 19 09:40:59 EST 2010

Andy,

Recall that you POST the Estimate resource which refers to the Scenario 
resource. The Scenario describes one possible way to run a project (e.g. 
"as soon as possible" or "limit headcount to 8"). You then estimate 
metrics for a given Scenario and POST Estimate resources that contain 
probability distributions.

You could PUT an Estimate resource to modify it.

The Estimate contains a probability distribution in some format, e.g. 
Triangular, Quantile, etc. One can compute the quantiles from a given 
distribution so you can assign a meaning to requesting percentiles for any 
Estimate, but that is really an operation the service would perform.

A simple example would be to ask for the mean or standard deviation of any 
Estimate. That information may not be explicitly represented in the 
Estimate resource, but an application could define the meaning. The 
application would become a Statistics service. Perhaps a cleaner way to 
design this would be to have a new Statistics resource that accepted 
queries involving Estimate resources, and computed statistics for them.

Arthur Ryman, IBM DE
Chief Architect, Rational Project and Portfolio Management
Office: 905-413-3077, Cell: 416-939-5063
Assistant: Nancy Barnes, 905-413-4182 

Andrew J Berner <ajberner at us.ibm.com> 
Sent by: community-bounces at open-services.net
01/18/2010 01:43 PM

To
Martin Nally <nally at us.ibm.com>
cc
community at open-services.net, community-bounces at open-services.net
Subject
Re: [OSLC] resource: storage vs representation--specifying variations in 
the form of the return from a GET

Again, the answers may be resource specific.  Martin, you're certainly
right that you can't PUT a quartile representation and GET a percentile
one.  But in this particular case (but probably not in other examples, 
like
the flyover), the resolution of that is you don't PUT the quartile or the
percentile.  You don't PUT the probability distribution either.  It is
derived from what in the OSLC estimation interface is being called a
Scenario (yes, it's an overloaded term we know).  You can GET and PUT the
scenario, that creates the probability distribution, which is then
available through a URL that other resources can link to and GET.  Then my
description is about what the result of that GET call should be and how 
the
consumer specifies that, since the underlying mathematical representation
is not tractable to "ordinary" consumers.

Even in the quartile/percentile case, there's a glimmer of this issue.  If
instead of parametric techniques to derive the probability distribution,
you directly PUT the percentile approximation of the answer, you could
derive the quartile representation, but, as Martin points out, not the
other way around (other than by making an assumption of segment wise
linearity, for the mathematically minded---but that's not the point here).
So you cannot have two independent URLs for them that both allow PUT and
GET.  Interesting side variant on my problem!

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

|------------>
| From:      |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Martin Nally/Raleigh/IBM                             |

>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Geoffrey M Clemm/Lexington/IBM at IBMUS        |

>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Andrew J Berner/Dallas/IBM at IBMUS, community at open-services.net, 
community-bounces at open-services.net         |

>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |01/18/2010 12:01 PM                        |

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

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

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

 Sent   community-bounces at open-services.net 
 by: 

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

_______________________________________________
Community mailing list
Community at 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

_______________________________________________
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/20100119/a5f7c1f8/attachment-0003.html>