Minutes from the DCML Applications/Services TC meeting 5/9/05

Minutes:
The meeting achieved quorum and by consensus the discussion covered topics such as updates from the New Orleans face-to-face meeting, liaison efforts, and a discussion on DCML ontology and modeling options. Notes from the discussion included:

New Orleans
Overall good participation and interest during the face-to-face session. The presentation panel on ontologies was interesting with several areas for alignment between DCML activities and activities for those on panel.
A review of the current TC structure was completed at the New Orleans session and in the effort to simplify and eliminate confusion about elemental management vs. interrelationship and configuration management to process management; there was a proposal that the TCs be restructured. This would take the elemental approach of the TCs such as Framework, Application/Services, Server and Network and would replace them with a TC entitled configuration management that would have sub-groups focused on mapping, process modeling, and CMDB. A Visio file illustrating this change was distributed to the TC for review and comment.
In addition to TC structure, a decision about where DCML would establish efforts within the stack was made in an effort to avoid duplicating efforts with other open and proprietary standards related to configuration management. A Visio file illustrating this decision was distributed to the TC for review and comment.
Liaison Efforts
Liaison efforts can be identified as internal OASIS and external standards bodies.
Initial groups identified for liaison included:
         OASIS - WSDM
         DMTF - CIM
         OGC/itSMF/ISACA
ACTION - ALL: All to review Darrel standards map slide 5 and document other standards/relationships
ACTION- ALL: A call for volunteers that may be involved in these groups and have an interest in acting as DCML Liaison was generated.

DCML ontology and modeling
A significant portion of the meeting was spent discussion DCML ontology selection and modeling options. What follows are highlights from this discussion:
As part of the discussion at the New Orleans face-to-face session, it was identified that consistent training on RDF/OWL for the technical TCs should be arranged to ensure an understanding of the semantics.
Tim has recommended that in order to solve the OWL/RDF versus other ontologies, that individuals provide a definitive use case that would explain what options would be used in place of OWL/RDF for review by the DCML TCs.
RDF/OWL are good for semantics, abstractions and vocabularies as well provides the non-hierarchical flexibility that XML Schema does not provide for IT Services environments that are inherently loosely coupled in their construct. Since DCML's primary purpose is to communicate data that will be based on relational intelligence and inherently doesn't primarily focuse on object oriented concepts, but more semantic, ontological, and "like" mapping that using OWL affords, there was concern by the members that the pure usage of OWL/RDF unnecessarily complicates the speciation and may be inhibiting for implementation
RDF level of abstraction with IT infrastructure hasn't been widely implemented. There was agreement that RDF would make sense at the management level but there was concern about RDF working at an applications level internally, but would require some due diligence to ensure that its usage would be prevalent for DCML's strategic adoption. The team is at consensus on the instance passing of DCML's XML structure, but not on the processing/preprocessing of RDF by management tools, and needs clarification on the use case for RDF's usage in management systems implementations. Possibly, a short workflow on the processing, exchange, and consumption of an RDF/XML-based DCML document vs. an alternative is in order to clarify the team.
DCML recognition that is model based - management systems would talk to IT resources pre-and post within the environment as DCMLs primary focus. Secondary focus is model based. There was some concern that because models are both object oriented model and inherited that there would be a lot of layers of abstraction within model.
As a group, there was a lot of agreement that UML would be a good modeling tool for DCML as it enables the use of class diagrams. It is still to be determined if everything is an inheritance based model as there may be areas that this approach would not fit - which has been the primary disadvantage in using UML or OO based modeling for DCML's multi-dimensional problem space in ITSMM. Additionally, there is a need to carefully consider how UML would exchange models - or, IF models need to be exchanged in management systems; the idea is to use UML to model, and another acceptable strategic construct to exchange, such as XMLS-or-OTHER/XML vs RDFS/XML. Recommendation was to complete modeling exercise first then to pick the schema starting with UML for class diagram.
Assumption is that UML diagramming would enable ease of ITIL configuration based off of Framework Spec 1.3, Appendix B - put into run book structure.
PROPOSAL: Fred recommended that the group complete a modeling exercise in UML to compare to the model done within RDF/OWL for comparison and contrast.
ACTION- ALL: Propose a definitive pro- and con- use case that would change the current model. Use the framework Use case in the Appendix B of the Framework Spec 1.3 that would be taken from a UML/XML perspective for contrast
ACTION - David Basham: Look at strategy regarding presenting DCML as a use case for ITIL with that as the first step with OGC/itSMF.
Next Steps:
Solidify TC structure with feedback
Proper ITIL and ITIL relationship mapping
Feedback to Tim and Framework TC with a use case that proposes different approach that maps out how it may be implemented.
Ajay to refining Use cases for higher level use cases at the process level versus element level.
Establish relationships OGC/itSMF/ISACA/AND OTHER NECESSARY feedback - Help would be appreciated

11:35am adjourn.

dcml-frame message