Integration scenarios as input to OSLC specifications

Body

A common requirement from the integration scenarios that I've been introducing to you is the need for combining data from multiple sources. For example, while scenario “Service and Application Problem Diagnosis” calls for being able to determine the impact  on services and applications of supporting resources and  scenario “Deployment of VM, System and Application patterns in Cloud” calls for being able to provision servers in the Cloud, the implementors  of both  scenarios share the need to process  data from diverse inputs such as  provisioning service providers, monitoring applications, asset management tools and so on.

How are we to combine and make sense of this heterogeneous data ? Two things we need to think about:

• What is this thing we're all talking about? Some of us say “cell phone” and others say “mobile”. We need a common "language" to express common concepts.
• I'm reporting on the CPU usage of a computer system. You are reporting on the ownership of a computer system. We need to determine if we are both referring to the same machine.

Also, as we are incorporating this work in our software products and as we want others to be able to join a scenario at a later date, whatever we define has to be precise and public. This is the goal of the OSLC reconciliation workgroup. The workgroup members publish a vocabulary (the "Common IT Resources vocabulary" ) and the OSLC reconciliation specification.
The vocabulary is the set of properties and types (unlike most languages, in RDF properties are globally re-usable rather than being bound to a single type.)  It defines types, for example "ComputerSystem". It also defines properties used with those types, for example "modelNumber".
 The specification defines resource shapes, and reconciliation rules. Resource shapes show the set of properties for each type useful for reconciliation.  Reconciliation rules are heuristics used to decide if two or more resources of the same type, for example "monitoring data about computerSystem A" and "asset data about computerSystem B", describe the same computer system.

There are other OSLC workgroups working on topics of common interest such as the Performance Monitoring workgroup which is defining usage metrics, or the Automation workgroup which is defining a protocol for automating software interactions.

What problems do you struggle with ? Do you require multi-vendor collaboration, have current protocols that are too brittle or have a use case that you’d like to propose ? I encourage you to join the workgroups and collaborate with the OSLC community in defining the solutions.