Reconciliation wiki http://open-services.net/wiki/reconciliation Latest changes for the OSLC Reconciliation wiki en webmaster@open-services.net webmaster@open-services.net (Lee Reamsnyder) Copyright 2018 Mon, 16 Jul 2018 17:28:39 EDT <![CDATA[Common IT Resource Type Vocabulary Version 2.0]]> TuanDang http://open-services.net/wiki/reconciliation/Common-IT-Resource-Type-Vocabulary-Version-2.0/ http://open-services.net/wiki/reconciliation/Common-IT-Resource-Type-Vocabulary-Version-2.0/#When:1395861651

Note: This vocabulary was originally part of the Performance Monitoring workgroup. It was moved to the Reconciliation workgroup as it is more applicable to the work done here.

Source files used to generate this page: TURTLE [[File:crtv.ttl]], RDF [[File:crtv.rdf]], HTML [[File:crtv.html]]

Common IT Resource Type Vocabulary

The namespace URI for this vocabulary is:

http://open-services.net/ns/crtv#

This page lists the RDF classes, properties, and individuals that make up the Common IT Resource Type Vocabulary vocabulary. Following W3C best practices, this information is available as HTML (this page) and as RDF.

More details on how this page was generated and other related material can be found in the wiki article Publishing RDF Vocabularies on jazz.net.

Description:

The Common IT Resource Type vocabulary.

See Also:

Classes in this vocabulary:

ComputerSystem, Database, IPAddress, OperatingSystem, Path, Process, ServerAccessPoint, ServiceInstance, SoftwareModule, SoftwareServer, StorageVolume, Tablespace

Properties in this vocabulary:

address, assetTag, contextAddressSpace, dbInstance, dependsOn, deployedTo, elementFrom, elementTo, fileName, fqdn, hostid, instancePath, ipAddress, manufacturer, model, name, observationTime, occursBefore, parentServiceInstance, portNumber, processId, runsOn, serialNumber, serverAccessPoint, shortHostName, systemBoardUUID, version, vmid

address

http://open-services.net/ns/crtv#address
address is an RDF property.

The canonical string representation of the IP address.

See Also:

Application

http://open-services.net/ns/crtv#Application
Application is an RDF individual.

See Also:

assetTag

http://open-services.net/ns/crtv#assetTag
assetTag is an RDF property.

Specifies the asset tag for a physical piece of equipment. Asset tags are typically human readable labels that are durable and securely attached to equipment. Asset tags may also be readable by barcode and/or RFID.

See Also:

Compute

http://open-services.net/ns/crtv#Compute
Compute is an RDF individual.

See Also:

ComputerSystem

http://open-services.net/ns/crtv#ComputerSystem
ComputerSystem is an RDF class.

An intelligent device, such as a computer, that can perform computing, data collection, and/or communication operations. This category includes general purpose computers, such as laptops, servers, and virtual machines; computers with specific functions, such as Networking and Storage hardware, Voice over IP Telephony devices, HVAC systems; monitoring data collection devices in buildings, automobiles, or electronic grids.

See Also:

contextAddressSpace

http://open-services.net/ns/crtv#contextAddressSpace
contextAddressSpace is an RDF property.

See Also:

Database

http://open-services.net/ns/crtv#Database
Database is an RDF class.

An organized collection of digital data that is managed by a database management system (DBMS). (A Database Management System, in turn, is represented as a SoftwareServer).

See Also:

DatabaseConnectionPool

http://open-services.net/ns/crtv#DatabaseConnectionPool
DatabaseConnectionPool is an RDF individual.

A set of shared database connections.

See Also:

DatabaseInstance

http://open-services.net/ns/crtv#DatabaseInstance
DatabaseInstance is an RDF individual.

See Also:

DB2Instance

http://open-services.net/ns/crtv#DB2Instance
DB2Instance is an RDF individual.

See Also:

dbInstance

http://open-services.net/ns/crtv#dbInstance
dbInstance is an RDF property.

The Software Server representing the database instance that manages this database.

See Also:

dependsOn

http://open-services.net/ns/crtv#dependsOn
dependsOn is an RDF property.

A relationship denoting that the source of the relationship cannot function properly without an association with the target. The dependency is directional ( the source depends on the target but the reverse is not necessarily true ) and can represent any cause or type of dependency. For instance, this relationship can be used to denote that a device depends on its power supply(s) or that an IP path depends on a layer 2 connection.

See Also:

deployedTo

http://open-services.net/ns/crtv#deployedTo
deployedTo is an RDF property.

The SoftwareServer on which this SoftwareModule is deployed.

See Also:

elementFrom

http://open-services.net/ns/crtv#elementFrom
elementFrom is an RDF property.

The resource acting as the origination point in the ordered path.

See Also:

elementTo

http://open-services.net/ns/crtv#elementTo
elementTo is an RDF property.

The resource acting as the destination point in the ordered path.

See Also:

fileName

http://open-services.net/ns/crtv#fileName
fileName is an RDF property.

The file name of the package containing the SoftwareModule.

See Also:

fqdn

http://open-services.net/ns/crtv#fqdn
fqdn is an RDF property.

The fully qualified domain name (FQDN). In Internet communications, the name of a host system that includes all of the subnames of the domain name. An example of a fully qualified domain name is es123126.lab.ibm.com .

See Also:

hostid

http://open-services.net/ns/crtv#hostid
hostid is an RDF property.

A globally unique ID assigned to their machines by some manufacturers (.e.g Sun Solaris) .

See Also:

IBMHTTPServer

http://open-services.net/ns/crtv#IBMHTTPServer
IBMHTTPServer is an RDF individual.

See Also:

instancePath

http://open-services.net/ns/crtv#instancePath
instancePath is an RDF property.

The directory where the files for this SoftwareServer are stored.

See Also:

IPAddress

http://open-services.net/ns/crtv#IPAddress
IPAddress is an RDF class.

Represents an IP address, either IPv4-based or IPv6-based.

See Also:

ipAddress

http://open-services.net/ns/crtv#ipAddress
ipAddress is an RDF property.

The IP address assigned to this system.

See Also:

J2CConnectorPool

http://open-services.net/ns/crtv#J2CConnectorPool
J2CConnectorPool is an RDF individual.

A set of shared J2C connections.

See Also:

J2EEApplication

http://open-services.net/ns/crtv#J2EEApplication
J2EEApplication is an RDF individual.

See Also:

J2EEServer

http://open-services.net/ns/crtv#J2EEServer
J2EEServer is an RDF individual.

See Also:

manufacturer

http://open-services.net/ns/crtv#manufacturer
manufacturer is an RDF property.

Name of the device manufacturer. This attribute SHOULD be a publicly available manufacturer name vocabulary.

See Also:

MessagingServer

http://open-services.net/ns/crtv#MessagingServer
MessagingServer is an RDF individual.

See Also:

model

http://open-services.net/ns/crtv#model
model is an RDF property.

Value of the device model. The model number as provided by the device manufacturer.

See Also:

MQQueue

http://open-services.net/ns/crtv#MQQueue
MQQueue is an RDF individual.

See Also:

MQQueueManager

http://open-services.net/ns/crtv#MQQueueManager
MQQueueManager is an RDF individual.

See Also:

name

http://open-services.net/ns/crtv#name
name is an RDF property.

Typically used as an identity field, this property is used to represent a known name of a resource instance.

See Also:

Network

http://open-services.net/ns/crtv#Network
Network is an RDF individual.

See Also:

NULL

http://open-services.net/ns/crtv#NULL
NULL is an RDF individual.

See Also:

observationTime

http://open-services.net/ns/crtv#observationTime
observationTime is an RDF property.

The time that the resource was last observed by the provider.

See Also:

occursBefore

http://open-services.net/ns/crtv#occursBefore
occursBefore is an RDF property.

If there is a temporal order between other Path or ServiceInstance Resource Definitions, the Resource Definition action that occur after this Resource Instance are listed here.

See Also:

OperatingSystem

http://open-services.net/ns/crtv#OperatingSystem
OperatingSystem is an RDF class.

Represents the operating system or control software installed and running on a ComputerSystem

See Also:

OracleInstance

http://open-services.net/ns/crtv#OracleInstance
OracleInstance is an RDF individual.

See Also:

parentServiceInstance

http://open-services.net/ns/crtv#parentServiceInstance
parentServiceInstance is an RDF property.

When context is required, this is the containing Application for the set of Transactions.

See Also:

Path

http://open-services.net/ns/crtv#Path
Path is an RDF class.

Path represents individual components of a directed graph of resources, where specific ordering is necessary to preserve a graph. Examples of such directed graphs are the representation of workflows or processes.

See Also:

portNumber

http://open-services.net/ns/crtv#portNumber
portNumber is an RDF property.

The port number as defined by IETF and IANA.

See Also:

Process

http://open-services.net/ns/crtv#Process
Process is an RDF class.

This resource represents a process running under an operating system.

See Also:

processId

http://open-services.net/ns/crtv#processId
processId is an RDF property.

The process id number assigned to the Process by the operating system.

See Also:

runsOn

http://open-services.net/ns/crtv#runsOn
runsOn is an RDF property.

The ComputerSystem this SoftwareServer instance is running on.

See Also:

serialNumber

http://open-services.net/ns/crtv#serialNumber
serialNumber is an RDF property.

Serial number assigned by the manufacturer. The value should be provided by the manufacturer of the resource.

See Also:

ServerAccessPoint

http://open-services.net/ns/crtv#ServerAccessPoint
ServerAccessPoint is an RDF class.

A network endpoint, i.e. the combination of IP address and port number that clients connect to when accessing a SoftwareServer.

See Also:

serverAccessPoint

http://open-services.net/ns/crtv#serverAccessPoint
serverAccessPoint is an RDF property.

The Server Access Point clients use for communications with this resource.

See Also:

ServiceInstance

http://open-services.net/ns/crtv#ServiceInstance
ServiceInstance is an RDF class.

A Service Instance is the representation of a service offering that was selected by the customer and then instantiated for that specific customer. Service Instances are supported by definite and measurable warranties or guarantees that the expected level of service/value will be met. Instances of the resource carry exposure from the group that is responsible for supporting the offering externally to the group that is utilizing the offering. It is common to group or nest instances together to form a service instance hierarchy. This resource definition does not represent the individual processes and/or activities that comprise an overall service except in the case where such processes are viewed as an independent service. In this condition, an instance of ServiceInstance would be created to represent the ServiceInstance of the process, then creating a hierarchy of ServiceInstances (to the containing ServiceInstance).

See Also:

shortHostName

http://open-services.net/ns/crtv#shortHostName
shortHostName is an RDF property.

A label assigned to a machine and used for communications on the local network. For example, a Windows hostname is IBM-2JMUUEH6TEQ .

See Also:

SoftwareModule

http://open-services.net/ns/crtv#SoftwareModule
SoftwareModule is an RDF class.

Represents packaged components that are deployed to a SoftwareServer.

See Also:

SoftwareServer

http://open-services.net/ns/crtv#SoftwareServer
SoftwareServer is an RDF class.

Represents an instance of software that participates in hosting a particular application.

See Also:

Storage

http://open-services.net/ns/crtv#Storage
Storage is an RDF individual.

See Also:

StorageVolume

http://open-services.net/ns/crtv#StorageVolume
StorageVolume is an RDF class.

Represents an identifiable unit of data storage. A StorageVolume can be a physical device ( e.g. a removable hard drive ) or a logical unit created by combining one or more other storage volumes.

See Also:

systemBoardUUID

http://open-services.net/ns/crtv#systemBoardUUID
systemBoardUUID is an RDF property.

The unique identifier of the system board.

See Also:

Tablespace

http://open-services.net/ns/crtv#Tablespace
Tablespace is an RDF class.

the storage area used by an Database to store its data. Database administrators define how Tablespaces maps to actual system storage. A Tablespace can be a physical device ( e.g. a removable hard drive ) or a logical unit (e.g. a file or a virtual disk).

See Also:

ThreadPool

http://open-services.net/ns/crtv#ThreadPool
ThreadPool is an RDF individual.

A set of shared threads.

See Also:

Transaction

http://open-services.net/ns/crtv#Transaction
Transaction is an RDF individual.

See Also:

version

http://open-services.net/ns/crtv#version
version is an RDF property.

The version string assigned to this entity.

See Also:

vmid

http://open-services.net/ns/crtv#vmid
vmid is an RDF property.

The VMID is a unique identifier for the virtual machine.

See Also:

WebServer

http://open-services.net/ns/crtv#WebServer
WebServer is an RDF individual.

See Also:

WebSphereServer

http://open-services.net/ns/crtv#WebSphereServer
WebSphereServer is an RDF individual.

See Also: ]]> Wed, 26 Mar 2014 15:20 EDT <![CDATA[Common IT Resource Type Vocabulary Version 2.0]]> TuanDang http://open-services.net/wiki/reconciliation/Common-IT-Resource-Type-Vocabulary-Version-2.0/ http://open-services.net/wiki/reconciliation/Common-IT-Resource-Type-Vocabulary-Version-2.0/#When:1395860410

Note: This vocabulary was originally part of the Performance Monitoring workgroup. It was moved to the Reconciliation workgroup as it is more applicable to the work done here.

Source files used to generate this page: TURTLE [[File:reconciliation.ttl]], RDF [[File:reconciliation.xml]], HTML [[File:reconciliation-vocabulary.html]]

Could not find a file uploaded to this wiki with that name ]]> Wed, 26 Mar 2014 15:00 EDT <![CDATA[Common IT Resource Type Vocabulary Version 2.0]]> TuanDang http://open-services.net/wiki/reconciliation/Common-IT-Resource-Type-Vocabulary-Version-2.0/ http://open-services.net/wiki/reconciliation/Common-IT-Resource-Type-Vocabulary-Version-2.0/#When:1395860330

Note: This vocabulary was originally part of the Performance Monitoring workgroup. It was moved to the Reconciliation workgroup as it is more applicable to the work done here.

Source files used to generate this page: TURTLE [[File:reconciliation.ttl]], RDF [[File:reconciliation.xml]], HTML [[File:reconciliation-vocabulary.html]]

Could not find a file uploaded to this wiki with that name ]]> Wed, 26 Mar 2014 14:58 EDT <![CDATA[Common IT Resource Type Vocabulary Version 2.0]]> TuanDang http://open-services.net/wiki/reconciliation/Common-IT-Resource-Type-Vocabulary-Version-2.0/ http://open-services.net/wiki/reconciliation/Common-IT-Resource-Type-Vocabulary-Version-2.0/#When:1395860251

Note: This vocabulary was originally part of the Performance Monitoring workgroup. It was moved to the Reconciliation workgroup as it is more applicable to the work done here.

Source files used to generate this page: TURTLE [[File:reconciliation.ttl]], RDF [[File:reconciliation.xml]], HTML [[File:reconciliation-vocabulary.html]]

Could not find a file uploaded to this wiki with that name ]]> Wed, 26 Mar 2014 14:57 EDT <![CDATA[index]]> John Arwe http://open-services.net/wiki/reconciliation/ http://open-services.net/wiki/reconciliation/#When:1379507711 Quick 2.0 links: | [[Reconciliation Meetings | Meetings]] | Email archives | [[Reconciliation Scenarios | Recon Scenarios]] | [[OSLC Reconciliation Specification Version 2.0 | Recon Specification]] | [[OSLC Reconciliation 2.0 Samples | Examples]]

[TOC]

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:

  1. 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).
  2. Register for the Reconciliation Workgroup mailing list
  3. Sign up for the workgroup ( by clicking the “Join” button on this page and signing the participant’s agreeement )

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 (finalize)

OSLC-RECON 2.0 Specifications

Document Link Status
[[OSLC Reconciliation Specification Version 2.0]] 2.0 final
[[OSLC Reconciliation Version 2.0 Issues]] 2.0 Ongoing
[[OSLC Reconciliation Implementation Reports 2.0]] 2.0 Ongoing

Supporting Documents

Document Link Status
Reconciliation Workgroup Scenarios and Use Cases [[Reconciliation Scenarios 2.0]] | Note
Common IT Resource Type Vocabulary [[Common IT Resource Type Vocabulary Version 2.0 2.0]] | Draft
Implementation Guidance [[OSLC Reconciliation Guidance for Implementers 2.0]] | Ongoing
Architectural Direction [[Architectural Direction 2.0]] | Note
Examples [[OSLC Reconciliation 2.0 Samples 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-Sept-26 2012-Oct-01 2013-Oct-26

Resources

How to join a working group

[[Reconciliation Meetings | Meeting Agendas and Minutes]]

Mailing List

Register for the Reconciliation Workgroup mailing list

Reconciliation Workgroup mail archives

General OSLC Community

]]> Wed, 18 Sep 2013 08:35 EDT <![CDATA[Reconciliation Meetings]]> TuanDang http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/ http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/#When:1379101236 Meetings are held weekly on Wednesday at 02:00PM Eastern TZ

(contact TuanDang if you’d like to participate)

Agendas and Minutes

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2012 13,21 11,16,23,30 06,13,27 04,11
2013 23, 30 6, 13, 20, 27 13, 20, 27 03, 10, 17 22, 29 18

Previous out-of-cycle meetings

None

]]> Fri, 13 Sep 2013 15:40 EDT <![CDATA[Reconciliation Meetings]]> TuanDang http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/ http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/#When:1379101187 Meetings are held weekly on Wednesday at 9AM Eastern TZ

(contact TuanDang if you’d like to participate)

Agendas and Minutes

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2012 13,21 11,16,23,30 06,13,27 04,11
2013 23, 30 6, 13, 20, 27 13, 20, 27 03, 10, 17 22, 29 18

Previous out-of-cycle meetings

None

]]> Fri, 13 Sep 2013 15:39 EDT <![CDATA[zMeeting 2013 18 September]]> TuanDang http://open-services.net/wiki/reconciliation/zMeeting-2013-18-September/ http://open-services.net/wiki/reconciliation/zMeeting-2013-18-September/#When:1379101096 Agenda
  1. addition of resource type for cluster
  2. addition of naming rule for cluster
  3. scheduling for subsequent meetings
]]> Fri, 13 Sep 2013 15:38 EDT <![CDATA[zMeeting 2013 29 May]]> TuanDang http://open-services.net/wiki/reconciliation/zMeeting-2013-29-May/ http://open-services.net/wiki/reconciliation/zMeeting-2013-29-May/#When:1369762933 Agenda
  1. Additional values for categorizing crtv:SoftwareServer instances
  2. For WebSphere servers, determine value to put in SoftwareServer.instancePath so that we can reconcile.
]]> Tue, 28 May 2013 13:42 EDT <![CDATA[Reconciliation Meetings]]> TuanDang http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/ http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/#When:1369420556 Meetings are held weekly on Wednesday at 9AM Eastern TZ

(contact TuanDang if you’d like to participate)

Agendas and Minutes

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2012 13,21 11,16,23,30 06,13,27 04,11
2013 23, 30 6, 13, 20, 27 13, 20, 27 03, 10, 17 22, 29

Previous out-of-cycle meetings

None

]]> Fri, 24 May 2013 14:35 EDT <![CDATA[zMeeting 2013 29 May]]> TuanDang http://open-services.net/wiki/reconciliation/zMeeting-2013-29-May/ http://open-services.net/wiki/reconciliation/zMeeting-2013-29-May/#When:1369420500 Agenda
  1. Additional values for categorizing crtv:SoftwareServer instances
]]> Fri, 24 May 2013 14:35 EDT <![CDATA[Reconciliation Meetings]]> TuanDang http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/ http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/#When:1369163222 Meetings are held weekly on Wednesday at 9AM Eastern TZ

(contact TuanDang if you’d like to participate)

Agendas and Minutes

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2012 13,21 11,16,23,30 06,13,27 04,11
2013 23, 30 6, 13, 20, 27 13, 20, 27 03, 10, 17 22

Previous out-of-cycle meetings

None

]]> Tue, 21 May 2013 15:07 EDT <![CDATA[Reconciliation Meetings]]> TuanDang http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/ http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/#When:1369163173 Meetings are held weekly on Wednesday at 9AM Eastern TZ

(contact TuanDang if you’d like to participate)

Agendas and Minutes

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2012 13,21 11,16,23,30 06,13,27 04,11
2013 23, 30 6, 13, 20, 27 13, 20, 27 03, 10, 17 23

Previous out-of-cycle meetings

None

]]> Tue, 21 May 2013 15:06 EDT <![CDATA[zMeeting 2013 22 May]]> TuanDang http://open-services.net/wiki/reconciliation/zMeeting-2013-22-May/ http://open-services.net/wiki/reconciliation/zMeeting-2013-22-May/#When:1369163052 Agenda
  • Discuss setting default behavior for reconciling when using string names. Make comparison case insensitive ?
]]> Tue, 21 May 2013 15:04 EDT <![CDATA[zMeeting 2013 17 Apr]]> TuanDang http://open-services.net/wiki/reconciliation/zMeeting-2013-17-Apr/ http://open-services.net/wiki/reconciliation/zMeeting-2013-17-Apr/#When:1366317953 Agenda
  1. v2.0 spec is final
  2. call for scenarios and items for follow-up version of the spec
  3. Consider new meeting time and frequency
  4. additions to vocabulary per Marek Smet
  5. If time permits, issues from LRDB re: TADDM vocabulary

Minutes:

attendees: John Arwe, Tuan Dang

  • Now that v2.0 is final and we have not yet gotten going on v3.0, consider changing time and frequency of meeting Tuan will poll WG members.
  • Other agendas items from today’s call will be discussed via the mailing list
]]> Thu, 18 Apr 2013 16:45 EDT <![CDATA[OSLC Reconciliation Specification Version 2.0]]> TuanDang http://open-services.net/wiki/reconciliation/OSLC-Reconciliation-Specification-Version-2.0/ http://open-services.net/wiki/reconciliation/OSLC-Reconciliation-Specification-Version-2.0/#When:1366317734 OSLC_logo.png

Open Services for Lifecycle Collaboration
Reconciliation Specification Version 2.0

Status: 2.0 Draft Specification - In finalization phase

This Version

Latest Version

PreviousVersion

  • This specification is the initial version of an OSLC Reconciliation specification

Authors

Contributors

Table of Contents

[TOC]

License

Creative Commons Attribution license
This work is licensed under a Creative Commons Attribution License.

Notation and Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC2119.

Domain name examples use RFC2606.

Introduction

(this section is informative)

Reconciliation, as referenced in this specification, refers to the case where there exists a need to understand if multiple providers are referring to the same resource, particularly when there is not already a common identifier that all providers populate. For example, an IT environment discovery tool reports that it finds a computer using an IP address of 192.168.0.1 ; and a monitoring tools reports that CPU usage on the machine with hostname example1.domain.com. A system administrator would previously have to rely on experience or have to lookup manually that both tools are referring to the same physical resource. In HTTP terms, we want to determine that a set of URIs refer to the same “non-information resource” entity. See the [[Reconciliation Scenarios]] page for several specific examples.

This specification builds on the OSLC Core Specification to define the resources and operations supported by Open Services for Lifecycle Collaboration (OSLC) providers who have a need to reconcile resource instance information with other providers.

The goal of this effort is to define resources, methods and constraints such that disparate tools can recognize that their data describes the same entity or concept (non-information resource). Reconcilable resources describe individual entities, including their relationships to other resources inside and/or outside of the Reconciliation domain.

Terminology

Reconciliation Service Provider - an OSLC Service Provider that exposes reconcilable and/or reconciled resources.

Reconcilable resource - a resource that conforms to this specification, especially the “additional requirements” section for each resource definition. It can be matched to another resource based on the values of a set of properties as defined in this specification

Reconciled resource - A collection of reconcilable resources that the Reconciliation Service Provider has determined to be representations of the same entity.

NOT - When used in the Resource Definitions section of this specification, indicates that the absence of a property is required.

Base Requirements

Compliance

This specification is based on OSLC Core Specification. OSLC Reconciliation domain consumers and service providers MUST be compliant with both the Core specification and this specification, and SHOULD follow all the guidelines and recommendations in both these specifications.

The following table summarizes the requirements from OSLC Core Specification as well as additional requirements specific to the Reconciliation domain.

Note that this specification further restricts some of the requirements from the OSLC Core Specification as noted in the Origin column of the compliance table. See further sections in this specification or the OSLC Core Specification to get further details on each of these requirements.

Any consumer or service provider behaviors are allowed unless explicitly prohibited by this or dependent specifications; conditional permissive requirements, especially those qualified with MAY, are implicitly covered by the preceding clause. While technically redundant in light of that broad permission, OSLC specifications do still make explicit MAY-qualified statements in cases where the editors believe doing so is likely to add clarity.

Requirements on OSLC Consumers

Requirement Level Origin(s) Meaning
Unknown properties and content MUST Core OSLC clients MUST preserve unknown content

Requirements on OSLC Service Providers

Requirement Level Origin(s) Meaning
Unknown properties and content MAY Core OSLC service providers MAY ignore unknown content
Unknown properties and content MUST Core OSLC service providers MUST return an error code if recognized content is invalid.
Unknown properties and content SHOULD Core OSLC service providers SHOULD NOT return an error code for unrecognized content.
Resource Operations MUST Core OSLC service providers MUST support resource operations via standard HTTP operations
Resource Paging MAY Core OSLC services MAY provide paging for resources
Partial Resource Representations MAY Core OSLC service providers MAY support HTTP GET requests for retrieval of a subset of a resource’s properties via the oslc.properties URL parameter
Partial Resource Representations MAY Core OSLC service providers MAY support HTTP PUT requests for updating a subset of a resource’s properties via the oslc.properties URL parameter
Service Provider Resources MAY Core OSLC service providers MAY provide a Service Provider Catalog resource
Service Provider Resources MUST Core OSLC service providers MUST provide a Service Provider resource
Creation Factories MAY Core OSLC service providers MAY provide creation factories to enable resource creation via HTTP POST
Query Capabilities SHOULD1 Reconciliation, Core OSLC service providers SHOULD provide query capabilities to enable clients to query for resources
Query Syntax MUST2 Reconciliation, Core If a service provider supports OSLC query capabilities, the query capabilities MUST support the OSLC Core Query Syntax
Query Syntax MAY Core OSLC query capabilities MAY support other query syntaxes
Delegated UI Dialogs SHOULD Core OSLC service providers SHOULD allow clients to discover, via their service provider resources, any Delegated UI Dialogs they offer.
Delegated UI Dialogs SHOULD Core OSLC service providers SHOULD offer delegated UI dialogs for resource creation
Delegated UI Dialogs SHOULD Core OSLC service providers SHOULD offer delegated UI dialogs for resource selection
UI Preview SHOULD Core OSLC Services SHOULD offer UI previews for resources that may be referenced by other resources
HTTP Basic Authentication MAY Core OSLC Services MAY support Basic Auth
HTTP Basic Authentication SHOULD Core OSLC Services SHOULD support Basic Auth only over HTTPS
OAuth Authentication MAY Core OSLC service providers MAY support OAuth
OAuth Authentication SHOULD Core OSLC service providers that support OAuth SHOULD allow clients to discover the required OAuth URLs via their service provider resource
Error Responses MAY Core OSLC service providers MAY provide error responses using Core-defined error formats
RDF/XML Representations MUST3 Reconciliation, Core OSLC service providers MUST offer an RDF/XML representation for HTTP GET responses
RDF/XML Representations MUST3 Reconciliation, Core OSLC service providers MUST accept RDF/XML representations on PUT requests.
RDF/XML Representations MUST3 Reconciliation, Core RDF/XML representations on POST requests whose semantic intent is to create a new resource instance.
XML Representations MAY3 Reconciliation, Core OSLC service providers MAY provide a XML representation for HTTP GET, POST and PUT requests that conform to the Core Guidelines for XML.
JSON Representations MAY3 Reconciliation, Core OSLC service providers MAY provide JSON representations for HTTP GET, POST and PUT requests that conform to the Core Guidelines for JSON
HTML Representations SHOULD3 Reconciliation, Core OSLC service providers SHOULD provide HTML representations for HTTP GET requests
  • 1The OSLC Core Specification indicates service providers MAY provide Query Capabilities. This specification strengthens the requirement.
  • 2The OSLC Core Specification indicates service providers MAY support the OSLC Query Syntax. This specification makes OSLC Query Syntax support a MUST requirement for service providers providing query capabilities.
  • 3Support for all common HTTP methods is not required for all resources defined by this specification. See the HTTP Method support table for details.

Specification Versioning

See OSLC Core Specification Versioning section.

Namespaces

In addition to the namespace URIs and namespace prefixes defined in the OSLC Core specification, OSLC Reconciliation Workgroup defines a namespace

  • http://open-services.net/ns/crtv# with a default namespace prefix of crtv. This namespace URI and prefix are used to designate the resources defined by the Common IT Resource Type vocabulary. The namespace prefix is used in this specification for consistency but client and provider implementations might use others.

Resource Formats

In addition to the requirements for OSLC Defined Resource Representations, this section outlines further refinements and restrictions.

See HTTP Method support table for further clarification on support for HTTP methods and media types for each OSLC resource.

For HTTP GET requests on all OSLC Reconciliation and OSLC Core defined resource types,

  • Reconciliation Providers MUST provide RDF/XML representations. The RDF/XML representation SHOULD follow the guidelines outlined in the OSLC Core Representations Guidance for RDF/XML.
  • Reconciliation Providers MAY provide other representations. Other representations SHOULD follow the guidelines outlined in the OSLC Core Representations Guidance.
  • Reconciliation Consumers requesting RDF/XML SHOULD be prepared for any valid RDF/XML document. Reconciliation Consumers requesting XML SHOULD be prepared for representations that follow the guidelines outlined in the OSLC Core Representations Guidance.
  • Reconciliation Providers SHOULD support an [X]HTML representation and a user interface (UI) preview as defined by UI Preview Guidance

For HTTP PUT/POST request formats for Reconciliation resources,

  • Reconciliation Providers MUST accept RDF/XML representations and MAY accept XML representations. Reconciliation Providers accepting RDF/XML SHOULD be prepared for any valid RDF/XML document. If XML is accepted, Reconciliation Providers SHOULD be prepared for representations that follow the guidelines outlined in the OSLC Core Representations Guidance.
  • Reconciliation Providers MAY accept XML and JSON representations. Reconciliation Providers accepting XML or JSON SHOULD be prepared for representations that follow the guidelines outlined in the OSLC Core Representations Guidance.

For HTTP GET response formats for Query requests,

  • Reconciliation Providers MUST provide RDF/XML and MAY provide other representations such as JSON and XML.

When Reconciliation Consumers request:

  • application/rdf+xml Reconciliation Providers MUST respond with RDF/XML representation without restrictions.
  • application/xml Reconciliation Providers SHOULD respond with OSLC-defined abbreviated XML representation as defined in the OSLC Core Representations Guidance

Authentication

See OSLC Core Authentication section. This specification puts no additional constraints on authentication.

Error Responses

See OSLC Core Error Responses section. This specification puts no additional constraints on error responses.

Pagination

Reconciliation Providers SHOULD support pagination of query results and MAY support pagination of a single resource’s properties as defined by the OSLC Core Specification.

Labels for Relationships

Relationships to other resources are represented as properties whose values are the URI of the object or target resource. When a relationship property is to be presented in a user interface, it may be helpful to provide an informative and useful textual label for that relationship instance. (This in addition to the relationship property URI and the object resource URI, which are also candidates for presentation to a user.) OSLC Core Links Guidance allows OSLC providers to support a dcterms:title link property in resource representations, using the anchor approach (reification), but this specification discourages its use (providers SHOULD NOT use it, and consumers SHOULD NOT depend on it). At the time this specification was written, the W3C RDF working group was on a path to remove reification from the next version of RDF, and it was noted that reification never was normatively defined even in the RDF/XML syntax W3C Recommendation, where it occurs informatively.

Resource Definitions

Resources defined by this specification can have properties other than those described here, in any namespace. It is RECOMMENDED that any additional properties exist in their own unique namespace and not use the namespaces defined in this specification.

A list of properties is defined for each type of resource. Most of these properties are identified in OSLC Core Appendix A: Common Properties and in the Common IT Resource Type vocabulary. Any exceptions are noted. Relationship properties refer to other resources. These resources may be in any OSLC domain (including the Reconciliation domain).

For all resource types defined in this specification, all required properties (those defined with an occurrence of exactly-one or one-or-many) MUST exist for each resource and must be provided when requested. All other properties are optional, and might not exist on some or any resources; those that do not exist will not be present in the returned representation even if requested, while those that do exist MUST be provided if requested. Providers MAY define additional provider-specific properties; providers SHOULD use their own namespaces for such properties, or use standard Dublin Core or RDF namespaces and properties where appropriate.

If no specific set of properties is requested, all properties MUST be returned - both those defined in this specification as well as any provider-specific ones. See Selective Property Values in the OSLC Core Specification.

Consumers should note that some resources may have a very large number of related resources, and that some resources may be very large and/or expensive to compute. For this reason, consumers are strongly RECOMMENDED to use the oslc.properties parameter to limit the properties returned from a request to the subset required. See Selective Property Values in the OSLC Core Specification.

Resource: ComputerSystem

  • Name: ComputerSystem
  • Description: An intelligent device, such as a computer, that can perform computing, data collection, and/or communication operations. This includes ( but is not limited to ) general purpose computers, such as laptops, servers, and virtual machines; computers with specific functions, such as Networking and Storage hardware, Voice over IP Telephony devices, HVAC systems; monitoring data collection devices in buildings, automobiles, or electronic grids.
  • Type URI http://open-services.net/ns/crtv#ComputerSystem

ComputerSystem Properties

Prefixed Name Occurs Read-only Value-type Representation Range Description
OSLC Reconciliation: Start of additional properties
crtv:manufacturer zero-or-one False String n/a n/a Name of the device manufacturer.
crtv:model zero-or-one False String n/a n/a Value of the device model. The model number as provided by the device manufacturer.
crtv:serialNumber zero-or-one False String n/a n/a Serial number assigned by the manufacturer. The value should be provided by the manufacturer of the resource.
crtv:systemBoardUUID zero-or-one False String n/a n/a The unique identifier of the system board.
crtv:vmid zero-or-one False String n/a n/a The VMID is a unique identifier for a virtual machine.
crtv:hostid zero-or-one False String n/a n/a A globally unique ID assigned to their machines by some manufacturers (.e.g Sun Solaris).
crtv:shortHostname zero-or-many unspecified String n/a n/a A label assigned to a machine and used for communications on the local network.
crtv:fqdn zero-or-many unspecified String n/a n/a The fully qualified domain name (FQDN). In Internet communications, the name of a host system that includes all of the subnames of the domain name.
crtv:ipAddress zero-or-many unspecified Resource Reference any an IP address assigned to this system. Typically refers to a resource of type crtv:IPAddress but it MAY refer to other resource types.

Additional requirements

Reconcilable resources of this type MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid. Multiple bullet points (rows) MAY be satisfied.

  • crtv:hostid, crtv:vmid
  • crtv:hostid, NOT crtv:vmid
  • crtv:manufacturer, crtv:model,crtv:serialNumber, crtv:vmid
  • crtv:manufacturer, crtv:model,crtv:serialNumber, NOT crtv:vmid
  • crtv:systemBoardUUID
  • (set of) crtv:fqdn
  • (set of) crtv:ipAddress

You MUST NOT use an informational value such as “Unknown” or “Not Available” for any of these bulleted properties. Populate a property only from administrative or configuration information returned from the system itself. If you are unable to obtain such information, omit the property entirely.

Resource: Database

Database Properties

Prefixed Name Occurs Read-only Value-type Representation Range Description
OSLC Reconciliation: Start of additional properties
crtv:name zero-or-one False String n/a n/a The name assigned to the database by the database administrator.
crtv:dbInstance zero-or-many False Resource Reference any The database instance that manages this database. Typically refers to a resource of type crtv:SoftwareServer but it MAY refer to other resource types.

Additional requirements

Reconcilable resources of this type MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid.

  • name, (set of) dbInstance

Resource: IPAddress

IPAddress Properties

Prefixed Name Occurs Read-only Value-type Representation Range Description
OSLC Reconciliation: Start of additional properties
crtv:address exactly-one False String n/a n/a The canonical string representation of the IP address.
crtv:contextAddressSpace zero-or-one False Resource Reference any the anchor IP address for an IPAddress in a Network Address Translation (NAT) scenario, that is IPv4 addresses within the set of IANA privately defined address ranges of 10.0.0.0 - 10.255.255.255, 172.16.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.255.255 . Typically refers to a resource of type crtv:IPAddress but it MAY refer to other resource types.

Additional Requirements

Reconcilable resources of this type MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid.

  • crtv:address, crtv:contextAddressSpace

Resource: ServiceInstance

  • Name: ServiceInstance

  • Description: A Service Instance is the representation of a service offering that was selected by the customer and then instantiated for that specific customer. Service Instances are supported by definite and measurable warranties or guarantees that the expected level of service/value will be met. It is common to group or nest ServiceInstances together to form a service hierarchy.

  • Type URI http://open-services.net/ns/crtv#ServiceInstance

ServiceInstance Properties

Prefixed Name Occurs Read-only Value-type Representation Range Description
OSLC Reconciliation: Start of additional properties
crtv:name exactly-one False String n/a n/a The name assigned by the organization that owns and supports this ServiceInstance.
crtv:parentServiceInstance zero-or-one unspecified Resource Reference any In cases where services are organized in a hierarchy, this refers to the service that is immediately higher in the hierarchy. Typically refers to a resource of type crtv:ServiceInstance but it MAY refer to other resource types.

Additional Requirements

Reconcilable resources of this type MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid.

  • crtv:parentServiceInstance, crtv:name

Resource: ServerAccessPoint

ServerAccessPoint Properties

Prefixed Name Occurs Read-only Value-type Representation Range Description
OSLC Reconciliation: Start of additional properties
crtv:ipAddress exactly-one False Resource Reference any The specific IP address which the ServerAccessPoint uses. Typically refers to a resource of type crtv:IPAddress but it MAY refer to other resource types.
crtv:portNumber exactly-one False String n/a n/a The port number as defined by the IANA

Additional Requirements

Reconcilable resources of this type MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid.

  • crtv:portNumber, crtv:ipAddress

Resource: SoftwareServer

SoftwareServer Properties

Prefixed Name Occurs Read-only Value-type Representation Range Description
OSLC Reconciliation: Start of additional properties
crtv:name zero-or-one False String n/a n/a The name assigned by an administrator .
crtv:serverAccessPoint zero-or-many False Resource Reference any The Server Access Point clients use for communications with this resource. Typically refers to a resource of type crtv:ServerAccessPoint but it MAY refer to other resource types.
crtv:instancePath zero-or-one False String n/a n/a The directory where the files for this SoftwareServer are stored.
crtv:runsOn zero-or-one False Resource Reference any The system this SoftwareServer instance is running on. Typically refers to a resource of type crtv:ComputerSystem but it MAY refer to other resource types.

Additional Requirements

Reconcilable instances of this type MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid. Multiple bullets may be satisfied.

  • crtv:name, crtv:instancePath, crtv:runsOn
  • crtv:name, (set of) crtv:serverAccessPoint
  • crtv:name, crtv:runsOn

Resource: SoftwareModule

SoftwareModule Properties

Prefixed Name Occurs Read-only Value-type Representation Range Description
OSLC Reconciliation: Start of additional properties
crtv:deployedTo zero-or-one False Resource Reference any The application server on which this SoftwareModule is deployed. Typically refers to a resource of type crtv:SoftwareServer but it MAY refer to other resource types.
crtv:fileName zero-or-one False String n/a n/a The file name of the package containing the SoftwareModule.
crtv:name zero-or-one False String n/a n/a The name of the SoftwareModule.

Additional Requirements

Reconcilable resources of this type MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid.

  • crtv:deployedTo, crtv:name, crtv:fileName

Reconciliation Service Provider Capabilities

Service Discovery and Description

Resource Shapes

Reconciliation service providers MAY support Resource Shapes as defined in OSLC Core Specification Appendix A

Service Provider Resource

Reconciliation service providers MUST provide a Service Provider Resource that can be retrieved at an implementation dependent URI.

Reconciliation service providers MAY provide a Service Provider Catalog Resource that can be retrieved at an implementation dependent URI.

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

Creation Factories

If an OSLC Reconciliation service provider supports the creation of resources, there MUST be at least one Creation Factory entry in its Services definition.

See the HTTP Method support table for further clarification on support for HTTP methods and media types for each OSLC resource.

Query Capabilities

There SHOULD be at least one Query Capability entry in the Services definition.

If provided, the Query Capability MUST support the oslc:where parameter and SHOULD support the oslc:select parameter:

If shape information is NOT present with the Query Capability, service providers SHOULD use the default properties defined in OSLC Core RDF/XML Examples to contain the result.

Delegated UIs

Reconciliation service providers MAY support the selection of reconcilable and reconciled resources as defined by Delegated UIs in OSLC Core.

Service Provider HTTP Method Support

Support for all HTTP methods in the compliance table is not required for all resources. The following table summarizes the requirements for each HTTP method, and media type combination. A value of N/A means this specification does not impose any constraints on it.

Resource RDF/XML XML JSON HTML Compact XML Other
GET MUST MAY SHOULD SHOULD N/A N/A
PUT MAY MAY MAY N/A N/A N/A
POST MAY MAY MAY N/A N/A N/A
DELETE N/A N/A N/A N/A N/A N/A

Reconciliation service providers SHOULD support deletion of any resources for which they allow creation.

Appendix C: Notices and References

Contributors

Reporting Issues on the Specification

The working group participants who author and maintain this working draft specification, monitor a distribution list where issues or questions can be raised, see Reconciliation Workgroup Mailing List

Also the issues found with this specification and their resolution can be found at [[OSLC Reconciliation Version 2.0 Issues]].

License and Intellectual Property

We make this specification available under the terms and conditions set forth in the site Terms of Use, IP Policy and the Workgroup Participation Agreement for this workgroup.

References

]]> Thu, 18 Apr 2013 16:42 EDT <![CDATA[index]]> TuanDang http://open-services.net/wiki/reconciliation/ http://open-services.net/wiki/reconciliation/#When:1366138231 Quick 2.0 links: | [[Reconciliation Meetings | Meetings]] | Email archives | [[Reconciliation Scenarios | Recon Scenarios]] | [[OSLC Reconciliation Specification Version 2.0 | Recon Specification]] | [[OSLC Reconciliation 2.0 Samples | Examples]]

[TOC]

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:

  1. 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).
  2. Register for the Reconciliation Workgroup mailing list
  3. Sign up for the workgroup ( by clicking the “Join” button on this page and signing the participant’s agreeement )

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 (finalize)

OSLC-RECON 2.0 Specifications

Document Link Status
[[OSLC Reconciliation Specification Version 2.0]] 2.0 final
[[OSLC Reconciliation Version 2.0 Issues]] 2.0 Ongoing
[[OSLC Reconciliation Implementation Reports 2.0]] 2.0 Ongoing

Supporting Documents

Document Link Status
Reconciliation Workgroup Scenarios and Use Cases [[Reconciliation Scenarios 2.0]] | Note
Common IT Resource Type Vocabulary [[Common IT Resource Type Vocabulary Version 2.0 2.0]] | Draft
Implementation Guidance [[OSLC Reconciliation Guidance for Implementers 2.0]] | Ongoing
Architectural Direction [[Architectural Direction 2.0]] | Note
Examples [[OSLC Reconciliation 2.0 Samples 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-Sept-26 2012-Oct-01 2013-Oct-26

Resources

How to join a working group

[[Reconciliation Meetings | Meeting Agendas and Minutes]]

Mailing List

Register for the Reconciliation Workgroup mailing list

Reconciliation Workgroup mail archives

General OSLC Community

]]> Tue, 16 Apr 2013 14:50 EDT <![CDATA[Reconciliation Meetings]]> TuanDang http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/ http://open-services.net/wiki/reconciliation/Reconciliation-Meetings/#When:1366137529 Meetings are held weekly on Wednesday at 9AM Eastern TZ

(contact TuanDang if you’d like to participate)

Agendas and Minutes

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2012 13,21 11,16,23,30 06,13,27 04,11
2013 23, 30 6, 13, 20, 27 13, 20, 27 03, 10, 17

Previous out-of-cycle meetings

None

]]> Tue, 16 Apr 2013 14:38 EDT <![CDATA[zMeeting 2013 17 Apr]]> TuanDang http://open-services.net/wiki/reconciliation/zMeeting-2013-17-Apr/ http://open-services.net/wiki/reconciliation/zMeeting-2013-17-Apr/#When:1366137443 Agenda
  1. v2.0 spec is final
  2. call for scenarios and items for follow-up version of the spec
  3. Consider new meeting time and frequency
  4. additions to vocabulary per Marek Smet
  5. If time permits, issues from LRDB re: TADDM vocabulary
]]> Tue, 16 Apr 2013 14:37 EDT <![CDATA[zMeeting 2013 03 Apr]]> TuanDang http://open-services.net/wiki/reconciliation/zMeeting-2013-03-Apr/ http://open-services.net/wiki/reconciliation/zMeeting-2013-03-Apr/#When:1364995532 Agenda
  • Request for a new resource type to represent clusters
    • from Tivoli APM team
    • possible use of rdfs:Container with rdf:type
    • no requirement for naming rules yet

Minutes

Attendees: John Arwe, Tuan Dang

  • sparse attendance
    • team is waiting on steering committee vote before starting next version of spec
    • Tuan to send out mailing list note on cluster item
  • Tentative date for completing next version of spec is 3Q2013
    • Tuan to issue call for scenarios. Scenario work should be complete by end of May 2013
    • Tuan to see if there is enough change in scope that IBM should go back to its STSC board to see if other groups want to participate
]]> Wed, 03 Apr 2013 09:25 EDT