Quick 2.0 links: | Meetings | Email archives | Recon Scenarios | Recon Specification | Examples
Contents
Goal
This workgroup seeks to define a common set of resource definitions, properties and constraints on the values of these properties such that disparate tools can utilize to identify and reconcile their data.
To join this working group
Please:
- Request a meeting invitation: contact [Tuan Dang](Tuan Dang), or send an email to the working group’s mailing list admins (note: remove NOSPAM from the destination domain name).
- Register for the Reconciliation Workgroup mailing list
Background
Whenever there is a situation where one product is communicating with another product about a resource, it is important to the user using both products to identify the resource and understand if it is the “same thing” across multiple systems. For example, do a monitoring record and an asset record taken together, describe one, multiple, or different resources ? The goal of this effort is to answer this category of questions, so that multiple tools can have a common understanding of their data when they integrate.
Identity allows users to know they have visibility, control, or apply automation on the correct “thing” when there are multiple products in use to perform those operations. Reconciliation is the task of bringing resource identity information together from each of the products, process this information, and then make a determination as to which resource data should combine together. The resulting combined representation is a reconciled representation of the resources across the various products. Identity and reconciliation allow users to have control over the correct resource when there are multiple products in use. This is a central issue when the resources described are not themselves electronic documents, be they representations of hardware, software or other managed business entities.
The approach will be to specify a number of tightly constrained scenarios, address them by drafting specifications, collect implementation experience using these drafts and then finalize the specifications. This will decrease the barrier to sharing data across multiple vendors and tools as part of the resource management life cycle. Future iterations of this process will be used to address additional scenarios.
Specifications
2.0 is the first version of the documents below. The OSLC Core working group recommends that domain working groups use the specification version to indicate that they are based on the OSLC Core 2.0 specification. This working group chose to use a consistent version number for all related documents.
2.0 (Draft)
OSLC-RECON 2.0 Specifications
| Document |
Link |
Status |
| Reconciliation Specification |
2.0 |
Initial Draft |
Supporting Documents
| Document |
Link |
Status |
| Reconciliation Workgroup Scenarios and Use Cases |
2.0 |
Note |
| Reconciliation Vocabulary |
2.0 |
Initial Draft |
| Common Resource Type Vocabulary |
2.0 |
Proposal |
| Architectural Direction |
2.0 |
Note |
| Examples |
2.0 |
Note |
Milestones
Note: iterative specification validation will be occurring as the drafts evolve before finalization. The goal is to have at least 2 implementations of the specification before it is considered finalized.
| Version |
Create Draft Specs |
Start Convergence |
Finalize Specs |
| 2.0 |
2012-Jul-13 |
2012-Aug-20 |
2013-Mar-29 |
Resources
How to join a working group
Meeting Agendas and Minutes
Mailing List
Register for the Reconciliation Workgroup mailing list
Reconciliation Workgroup mail archives
General OSLC Community
