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

Dear DCML Framework TC:

 

Below are the minutes from the Applications Services TC meeting from May 9 
that many of you were present for. In the interest of ensuring that the groups 
are aligned, they are reposted here for your convenience. 

 

Best, 

Sarah

________________________________________ 

 

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.