[Oslc-recon] requirement that a provider MUST provide an oslc:serviceProvider property for its resources

[Tuan Dang]

The scenario ( 
http://open-services.net/wiki/reconciliation/Scenario-Coverage-Report/ ) 
calls for reporting on the delta between
monitored resources and discovered resources.

We'd be able to determine if a reconciled resource has a reconcilable 
resource from a monitoring SP and a reconcilable resource from a 
discoverySP

Thanks ! T

Tuan Dang
Tivoli OSLC governance, OSLC Reconciliation workgroup lead, Tivoli Common 
Data Model
Internet: tdang at us.ibm.com
phone: (919) 224-1242 T/L 687-1242




From:   Tuan Dang/Raleigh/IBM at IBMUS
To:     oslc-recon at open-services.net, 
Date:   02/20/2013 03:03 PM
Subject:        [Oslc-recon] requirement that a provider MUST provide an 
oslc:serviceProvider property for its resources
Sent by:        "Oslc-Recon" <oslc-recon-bounces at open-services.net>



In the spec : 
> Reconciliation service providers MUST provide a oslc:serviceProvider 
property for their defined resources that will be the URI to a Service 
Provider Resource. 


Discussion so far: 

>From Mike Fiedler whom I asked about the same req in the Automation spec 
>The reason it is there is for the benefit of the consumer.   For the V2 
automation scenarios, the thought was that a Service Provider is the 
starting point for generic >discovery of query capabilities, creation 
factories and delegated UIs.  Strictly speaking, I guess it does not have 
to be a MUST, but consumers would require "special" >knowledge to know 
which URLs to hit on the provider for these services. 
.. 
>OK, I understand.  Some folks are bigger fans of the Service Provider 
concept than others.   My feeling, from having been a consumer of 
providers from many domains, is that they provide consumers with a 
well-known starting point for interacting with a provider and figuring out 
what it can or cannot do. 


Reply from John Arwe: 
>I think we're mentally asking the question "what scenario leads to its 
inclusion" - channel Martin ;-)  .  It may be an unstated one (that either 
should be rendered explicit >and adopted, or should be explicitly 
disowned).  If it's got anything to do with fanboi-ism, we're already off 
The Path. 
>It would be easier perhaps if there was one (in Core maybe) that drove 
the need.  Otherwise we need to do so w/in each domain.  My strawman for 
Recon follows. 
>What I could hear between the lines here is looking at things from the 
client end, a point of view not necessarily where the Recon weenies would 
start.  They start from: >you have 2 things and you want to know if 
"they're really the same" or not, based on their properties.  Dicey 
business in URL space, but routine in meatspace. 
>If OTOH you start from (ala "it was a dark and stormy night.  a shot rang 
out."): "someone hands you a URL, what now?"  then you'll get a different 
answer.  If >(distancing ourselves from the Tivoli *implementation* for a 
moment) you get a URL, you GET its representation, and it turns out that 
it is of a type that has reconciliation >rules and it also "is 
reconcilable" (satisfies a set of property-existence and content format 
constraints), ... now what?  The usual OSLC scenario approach is a brute 
>force "how would a user do it" one, as a starting point ("the simplest 
thing that could possibly work", as Bill Higgins was wont to say).  We 
have a least on scenario in >Reconciliation, the fabled coverage report. 
Does that drive a need for oslc:SP in a non-Tivoli implementation? May-be. 

>Simplest form of coverage report is for just this 1 input URL, who has 
data about "it" (by which I mean, the set of URLs that is output from the 
reconciliation process... to >an omniscient observer with perfect 
reconciliation results in hand, which URLs would reconcile with the input 
URL).  For each of those, what you'd need for a coverage >report is 
(minimally) product name and link to its details.  Here, I think that 
means scavenge around through every SP you know how to find (doesn't 
matter how you find >them), query each for its resources of the same type, 
GET each, decide if same/different from your starting point.  There is NO 
guarantee that the set of SPs you >already know about includes the one who 
minted the input URL, so how do you find it (for product name) if not via 
oslc:SP?  That seems like a good scenario to render >explicit.  It does 
make a jump from SP to product, so just use "provider title" instead of 
"product name", done. 

Thanks ! T

Tuan Dang
Tivoli OSLC governance, OSLC Reconciliation workgroup lead, Tivoli Common 
Data Model
Internet: tdang at us.ibm.com
phone: (919) 224-1242 T/L 687-1242
_______________________________________________
Oslc-Recon mailing list
Oslc-Recon at open-services.net
http://open-services.net/mailman/listinfo/oslc-recon_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-recon_open-services.net/attachments/20130220/5a2a23f0/attachment-0003.html>