Sorry just catching up with this particular stream of thought. I know "enough to be dangerous" about Reconciliation. There's nothing specifically like a "computing environment" in Recon today (2.0 finalized recently), but users are at least talking about concepts that might be similar (clusters of various sorts) for follow-ons. Tuan Dang is the WG lead, +ccing him. I think there is a notional plan to immediately start working on a "2.0+1" version, so he'd be collecting scenarios "real soon now". As you folks have been discussing it so far however, there are a number of subtly different issues involved. 1: Reconciliation proper ... this would play if there are cases where two distinct actors have different identities (URLs) for some entity that is a non-information resource (often called "real world" resources) yet to us humans (and hence to code that wants to automate our actions) they are in some way "the same". In some places, people talk about tools individually managing different "aspects" of the thing. Reconciliation basically worries about how to decide whether or not two resources are (probably) "the same" in this sense. Apologies for the indirect language, but precise language here is like trying to grab a handful of fog. Not all even agree that the distinction is useful; others argue it's essential....*that* kind of fog. 2: "Compatibility" checking ... in this way of thinking, each consumer has a list of minimum requirements (perhaps per task), each provider lists the capabilities it exposes, and they're "compatible" (but NOT "the same") if the intersection of the two is at least what the consumer needs. Another way to think of these descriptions are as query predicates; the result of applying the consumer's query predicate over the set of providers is the set of providers actually useful to the consumer. I've seen that come up in other domains already. 3: What do "the same" and "compatible" really mean when the resources being used have triples whose objects are other resources? This is just another form of the well-known copy problem (shallow or deep?), which of course has no really appealing solutions. If one requirement you have as a consumer is a 2-tier deployment topology, this answer obviously matters quite a bit. 4: Re-use of Reconciliation (the domain spec or concept from #1) vs it's *Vocabulary* terms, which of course are freely open to re-use in other specs. If you were to model an execution env as a service, as an example, "there's a vocabulary term for that" aka crtv:ServiceInstance (personal guess). You could do that orthogonally to your answer to any other question/point here.
Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario "Oslc-Automation" <[email protected]> wrote on 05/03/2013 04:16:08 AM: > > I believe that the Reconciliation WG have been working on a way to > match two descriptions of IT resources. From my brief look at their > work I didn't see anything related to this sort of execution > environment (at least, not for the test subdomain scenarios, it > might work for the deployment one). Perhaps we could propose a new > vocabulary for them for common themes in our subdomains? Does anyone > know enough about their work to know if that would be a good fit? > > martin
