Difference between revisions of "CTS2/doc/CTS2 SFM CodeSystemAttributes"
Jump to navigation Jump to search
m (1 revision: Re-import CTS2 documentation pages with appropriate links)
Revision as of 22:30, 27 November 2015
The diagram below contains the attributes described in the CTS2 SFM and the those in the CTS2 PIM. The sections that follow explain the differences between the two models and the rationale for the differences.
|id - type ISO OID||about - type ExternalURI||
|description||resourceSynopsis||The CTS2 ROA approach emphasized that the various CTS2 model elements contained descriptions of the various resources, not the resources themselves. A CodeSystemCatalogEntry may describe SNOMED-CT, but it clearly isn't SNOMED-CT itself. This distinction turned out to be quite important in some situations. The problem, however, is that the term description was already used to characterize all of the CodeSystemCatalogEntry metadata, so we needed a different term for the block of text that summarizes and/or describes the resource in a given language. The term resourceSynopsis was chosen as a substitute.|
|administrativeInfo||codeSystemName, codeSystemCategory, ontologyDomain, ...||The CTS2 PIM felt that the "placeholder" in the SFM needed to be made explicit where industry accepted naming and type standards were in place. The various elements, which you will note are almost all optional, are drawn from a variety of sources including LexGrid, LexEVS, RDF and OWL, the Dublin Core, the Ontology Metamodel Vocabulary (OMV), BioPortal, etc. |
property provides a slot for including additional information not named in the other components described above.
|CodeSystemSupplement||CodeSystemSupplement explicitly calls for a name (an attribute that is, curiously, not spelled out in CodeSystem. provenanceDetails appear to be synonymous (?) with administrativeInfo and effectiveDate is a characteristic of a version, not a code system itself. We have concluded that CodeSystemSupplement requires all the characteristics present in Codesystem (especially as CodeSystemCatalogEntry makes many of the provenanceDetails explicit), needs to be versionable, and needs to reference specific CodeSystemVersions in addition to target CodeSystems|