CTS2/doc/CTS2 SFM AssociationArea

From HL7Wiki
Jump to navigation Jump to search
Prev Contents Next

Alignment between the CTS2 SFM Association Class and the CTS2 PIM Association Class

This section describes the alignment of the SFM Association Class and the corresponding Class in the CTS2 PIM. Note that this does not address the notion of "mapping", which is described in a separate aspect of the CTS2 PIM model

CTS2/doc/Image:AssociationArea.png


SFM PIM Reason
AssociationType ObjectPropertyDescription (subclass of EntityDescriptionBase See: Entity Area for a discussion of the why this is considered a first class entity in the CTS2 PIM.
CodeSystemEntityAssociation Association The CodeSystemEntity part of the name was dropped because "CodeSystem" was redundant and, as the CTS2 PIM was expanded to support literal, bnode and list targets, the resulting association was no longer just between two entities.
CodeSystemEntityAssociation.associationKind (none) "[associationKind] describes the nature of the association (e.g. ConceptMap vs. Hierarchic relationship within a code system).". The CTS2 PIM separates the notions of ConceptMap and Hierarchic relationships. This was done because all but the simplest concept mappings required the addition of rules and other artifacts that made no sense in a simple association triple.
CodeSystemEntityAssociation.status Association.entryState The SFM defines status as "A status (status) to identify the state (mainly for curation)". entryState provides the state of the association with respect to the service (ACTIVE or INACTIVE)
Association.status[0..1] The status of the association within an external workflow, which covers the "curation" portion of the definition
CodeSystemEntityAssociation.statusDate[0..1] ChangeDescription.changeDate
(Not shown in this diagram)
The date that the last change occurred. Note that this applies to all changes - a client will have to locate a METADATA change type where the status changed or, if not present, the CREATE change type where the first entry was created.
CodeSystemEntityAssociation.id[0..1] Association.associationId (which is a redefinition of Association.entryID Association identity represents an interesting challenge in the ROA environment - some notion of identity is required if one is to inactivate, change the status of or otherwise modify a specific association, and identity is not as simple as the subject-predicate-target triple - targets can be lists or bNodes. The CTS2 PIM chose to remain neutral on how an associationID is generated. The choice is (fairly) obvious when the association comes from SNOMED-CT, as every Relationship entry has a unique SCTID. It isn't, however, when one is loading, say, the Wine Ontology. In the latter case, the PIM suggests (but does not require) that an association be assigned a GUID when loaded. This is a less than perfect solution, however, as the same association in two different service instances will not have the same ide.
CodeSystemEntityAssociation / AssociationType Association.predicateOf See: Entity Area for a discussion of why this is represented as a predicate vs. a type.
CodeSystemEntityVersion.isSourceOf Association.subjectOf

The strong containment relationship doesn't actually work as represented, as it is only possible for an instance a class to be contained in at most one container at a time. The most likely reason that this has been represented this way is to show that, if an instance of CodeSystemEntityVersion is deleted, the corresponding association must go away as well. This is not an issue in a ROA model, as the "existence" of an EntityDescription is independent of the URI.

CodeSystemEntityVersion.isTargetOf Association.targetOf
  1. The isSourceOf containment issues apply here as well
  2. The CTS2 PIM allows a number of different types of targets beyond EntityDescription. Targets may be lists, literals or blank nodes (BNodes). The [0..*] cardinality reflects these choices with respect to EntityDescription.
Prev Contents Next