-by Van Wiles, Lead Integration Engineer


A possible answer to the question of how to model CIM associations in CMDBf.


Last time I posted a question - to see if we can move toward a resolution on the question about modeling a CIM association using CMDBf relationships. William Vambenepe replied to me on his blog here:


Basically his answer can be summarized as: (a) Some authoritative group like the CMDBf workgroup defines a convention for mapping CIM association roles to CMDBf source and target, and/or (b) CMDBf workgroup provides an ontology language that allows records to be related to each other (e.g. RDF/OWL semantics.)


While I like his proposal about a naming convention for relationship records (such as CIM_Dependency_from_Antecedent_to_Dependent), it would allow any implementation to model the source/target direction either way. At least it would be definitive about the role of source and target for that relationship. I also like the idea of having an ontology language to describe the record types more thoroughly, but I would not want to force MDRs and consumers to read and understand the ontology in order to use the interface.


I guess in a perfect world everyone would model it the same way, so if we said "source is always the first role and target is always the second role" we would at least have a simple match most of the time, and the naming convention would confirm the roles of source and target.


Note that an ontology language or some embeded mapping of data models allows an MDR to return records it considers to match your query, even if the record type has a different name. Here's an example.


Assume I could have this i1 -r1-> i2 <-r2- i3 graph in a CIMOM where:

  • i1 has a CIM_ComputerSystem record

  • r1 has a CIM_ParticipatingCS_from_Antecedent_to_Dependent" record

  • i2 has a CIM_Cluster record

  • r2 has a CIM_ConcreteDependency_from_Dependent_to_Antecedent" record

  • i3 has a CIM_Organization record

So in English I have an organization which depends on a cluster of computer systems.


Now I want to see what computer systems support this organization. I can invert r2 as CIM_ConcreteDependency_from_Antecedent_to_Dependent (vr2) and have this:
i1 -r1-> i2 -vr2-> i3. Now I can query i1 to i3 via CIM_Dependency_from_Antecedent_to_Dependent with depthLimit 2 or more and find this graph. Great! But I made a couple of assumptions that the casual observer might not have noticed:

  • CIM_Dependency is a superclass of CIM_ConcreteDependency and CIM_ParticipatingCS. We have decided it is OK to match a record type which is considered to be of the same type as the request, even if there is no strict XSD extension model to validate this.

  • We are also considering defining a way (via RDF/OWL) to expose these class relationships.
    An MDR could respond with an inverse relationship that satisfies your query, even though this relationship record does not actually exist in that form (really a special case of the previous item).

Reversing direction in the underlying data store query could be challenging, but that's why we hire geniuses (well maybe we need a few more).


The postings in this blog are my own and don't necessarily represent BMC's opinion or position.