This wiki has undergone a migration to Confluence found Here
Difference between revisions of "CTS2/doc/CTS2 SFM AssociationArea"
Jump to navigation
Jump to search
Line 4: | Line 4: | ||
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 | 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 | ||
− | [[ | + | [[Image:AssociationArea.png]] |
Latest revision as of 07:20, 22 December 2015
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
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 |
|
Home |
About CTS2 |
---|
Purpose |
CTS2 History |
Business Case |
How it works |
Federation |
Functionality |
Implementing CTS2 |
Architecture |
Development |
Resources |
Purpose |
FAQ |
Business Case |
Glossary of Terms |
Specification |
REST |
SOAP |
HL7 SFM |
Development |
CTS2 Development Framework |
Implementations |
Github Page |
Community |
Who is Using CTS2? |
Get Help |
Links |