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: [email protected] phone: (919) 224-1242 T/L 687-1242 From: Tuan Dang/Raleigh/IBM@IBMUS To: [email protected], 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" <[email protected]> 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: [email protected] phone: (919) 224-1242 T/L 687-1242 _______________________________________________ Oslc-Recon mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-recon_open-services.net
