CTS2 BioPortal Model Mapping
Jump to navigation
Jump to search
The table below shows the correlation between the CTS 2 and Bioportal model elements or CodeSystem and CodeSystemVersion. A cardinality of 0..0 indicates that the model does not support the corresponding attribute directly.
| CTS 2 Class | CTS 2 element | card | Bioportal element | card | Notes |
|---|---|---|---|---|---|
| CTS 2 | CodeSystemCatalogEntry | 0..n | ontologyBean | 1..n | |
| CTS 2 | CodeSystemVersionCatalogEntry | 0..n | ontologyBean | 1..n | |
| 0..n | id | 1..1 | Not used directly in CTS2. The BioPortal abbreviation is used to identify the CodeSystemName. The Id is carried as a property in the CodeSystemVersionCatalog | ||
| 0..0 | ontologyId | 1..1 | The abbreviation, ontologyId and format are concatinated together to generate a unique CodeSystemVersion. The ontologyId is carried as a property in the CodeSystemVersionCatalog | ||
| 0..0 | filePath | 1..1 | This is where the file can be downloaded on BioPortal | ||
| 0..0 | isFlat | 1..1 | Used in BioPortal to indicate ontologies that do not have a well defined hierarchy (Example: Snomed CORE subset) | ||
| CodeSystemCatalogEntry | about | 1..1 | BioPortal PURL URI | 1..1 | BioPortal PURL URI |
| CodeSystemCatalogEntry | codeSystemName | 1..1 | abbreviation | 1..1 | |
| CodeSystemCatalogEntry | entryState | 1..1 | 0..0 | (Workflow related - should not have an Bioportal equivalent) | |
| CodeSystemCatalogEntry | formalName | 0..1 | displayLabel | 1..1 | |
| CodeSystemCatalogEntry | additionalDocumentation | 0..1 | 0..0 | ||
| CodeSystemCatalogEntry | alternateId | 0..n | 0..0 | CTS 2 allows an ontology to have multiple "cannonical" URIs. | |
| CodeSystemCatalogEntry | currentVersion | 0..1 | 0..0 | A link to the version of the ontology considered to be "current" by the supporting service | |
| CodeSystemCatalogEntry | keyword | 0..n | categoryId | 0..n | This is not exactly the same as keyword, but a close equivalent |
| CodeSystemCatalogEntry | note | 0..n | 0..0 | ||
| CodeSystemCatalogEntry | ontologyDomain | 0..n | 0..0 | ||
| CodeSystemCatalogEntry | ontologyType | 0..1 | 0..0 | ||
| CodeSystemCatalogEntry | property | 0..n | 0..0 | ||
| CodeSystemCatalogEntry | releaseDocumentation | 0..1 | 0..0 | ||
| CodeSystemCatalogEntry | resourceSynopsis | 0..1 | description | 1..1 | "Description" was considered to vague so CTS 2 used a more precise name |
| CodeSystemCatalogEntry | resourceType | 1..n | 0..0 | owl:Ontology, skos:ConceptScheme or other applicable type | |
| CodeSystemCatalogEntry | sourceAndNotation.sourceDocument | 0..1 | downloadLocation | 0..1 | The location of the source document |
| CodeSystemCatalogEntry | sourceAndRole | 0..n | contactName | 0..1 | |
| CodeSystemCatalogEntry | sourceAndRole | 0..n | contactEmail | 0..1 | |
| CodeSystemCatalogEntry | sourceAndRole | 0..n | homePage | 0..1 | |
| CodeSystemCatalogEntry | sourceStatements | 0..n | 0..0 | ||
| CodeSystemCatalogEntry | status | 0..1 | 0..0 | ||
| CodeSystemCatalogEntry | versions | 0..1 | 0..0 | A link to all known versions of an Ontology | |
| CodeSystemVersionCatalogEntry | changeDescription.changeDate | 0..1 | dateCreated | 0..1 | CTS 2 has a formal change model and this ends up as a component of this aspect. |
| CodeSystemVersionCatalogEntry | documentURI | 1..1 | resourceLocator | 1..n | In CTS 2 parlance, a code system cannot have a location, only a specific version. In addition, CTS 2 differentiates "versions" that have different representations. The OWL version of SNOMED-CT 2010AA is a different CTS 2 version than the RF2 version. As a result, each version has exactly one resourceLocator which serves as the identity of the specific resource. |
| CodeSystemVersionCatalogEntry | imports | 0..n | 0..0 | ||
| CodeSystemVersionCatalogEntry | officialReleaseDate | 0..1 | dateReleased | 0..1 | |
| CodeSystemVersionCatalogEntry | officialResourceVersionId | 0..1 | versionNumber | 0..1 | This information is not always known, which is why it is not required in CTS 2. CTS 2 does require, however, a codeSystemVersionName which uniquely identifies the version in the context of the service, but does not necessarily have any tie to the publisher's version identifier. |
| CodeSystemVersionCatalogEntry | sourceAndNotation.sourceDocumentSyntax | 0..1 | format | 0..1 | |
| CodeSystemVersionCatalogEntry | status | 0..1 | statusId | 1..1 |
| CTS 2 Class | CTS 2 element | card | Bioportal element | card | Notes |
|---|---|---|---|---|---|
| EntityDescriptionBase | about | 1..1 | fullId | 1..1 | |
| EntityDescriptionBase | entityId | 1..1 | id | 1..1 | |
| label | 1..1 | ||||
| isTopLevel | 1..1 | ||||
| authors | 0..n | There is no 'SourceAndRole' on an Entity, so this is not mapped. If this needed to be persisted, it could be a 'Note'. | |||
| NamedEntityDescription | entryState/status | 0..1 | isObsolete | 1..1 | if isObsolete is 'true', entryState = 'INACTIVE' and 'status' = 'Obsolete'. |
| EntityDescriptionBase | alternateEntityId | 0..n | 0..0 | ||
| EntityDescriptionBase | describingCodeSystemVersion | 0..1 | ontologyVersionId | 1..1 | |
| EntityDescriptionBase | designation | 0..n | synonyms | 0..n | |
| EntityDescriptionBase | definition | 0..n | definitions | 0..n | |
| EntityDescriptionBase | example | 0..n | 0..0 | ||
| EntityDescriptionBase | note | 0..n | 0..0 | ||
| EntityDescriptionBase | property | 0..n | ClassBean.relation | 0..n | When the target of the relation map is a string, it is assumed to be a property |
| EntityDescriptionBase | sourceStatements | 0..1 | 0..0 | ||
| EntityDescriptionBase | subjectof | 0..1 | classBean.Id | 0..1 | |
| EntityDescriptionBase | predicateof | 0..1 | classBean.relations.key | 0..n | When the target of the relations map in BioPortal is a list of classbean, the key is assumed to be a predicate |
| EntityDescriptionBase | targetof | 0..1 | classBean.relations.value | 0..n | The list classbean in the relations map values. |
| EntityDescriptionBase | parent | 0..1 | Relation.SuperClass | 0..n | |
| EntityDescriptionBase | ancestors | 0..1 | 0..0 | A BioPortal rest call overs this | |
| EntityDescriptionBase | children | 0..1 | Relation.SubClass | 0..n | |
| EntityDescriptionBase | descendents | 0..1 | 0..0 | A BioPortal rest call overs this | |
| EntityDescriptionBase | entityTypes | 0..n | type | 1..1 | |
| EntityDescriptionBase | instances | 0..1 | InstanceBean | 0..n | |
| EntityDescriptionBase | equivalentEntity | 0..n | ClassBean.relation.equivalentClass | 0..n |
| CTS 2 Class | CTS 2 element | card | Bioportal element | card | Notes |
|---|---|---|---|---|---|
| Association | associationID | 1..1 | URI | 1..1 | There is no identity given to the triple by Bioportal, so we will have to generate or concat something. |
| Association | subject | 1..1 | classbean.id | ||
| Association | predicate | 1..1 | classBean.relations.key | 0..n | |
| Association | target | 0..n | classBean.relations.value | 1..n | |
| Association | associationQualifier | 0..n | 0..0 | ||
| Association | assertedBy | 1..1 | 0..0 | There really is no way to get the ontology or ontologyVersion from the 'classBean', so we can't popluate this without parsing the URI | |
| Association | assertedIn | 0..1 | 0..0 | There really is no way to get the ontology or ontologyVersion from the 'classBean', so we can't popluate this without parsing the URI | |
| Association | derivation | 1..1 | 0..0 | ||
| Association | derivationReasoningAlgorithm | 0..n | 0..0 | ||
| Association | sourceStatements | 0..1 | 0..0 | ||
| Association::Changeable | entryId | 1..1 | 0..0 | Workflow | |
| Association::Changeable | entryState | 1..1 | 0..0 | Workflow | |
| Association::Changeable | status | 0..1 | 0..0 | Workflow | |
| AssociationDirectory | directoryFilter | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationDirectory | sortCriteria | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationDirectory | numEntries | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationDirectory | complete | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationDirectory | next | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationDirectory | prev | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationDirectoryEntry | associationID | 1..1 | 0..0 | There is no identity given to the triple by Bioportal, so we will have to generate or concat something. | |
| AssociationDirectoryEntry | subject | 1..1 | classbean.id | ||
| AssociationDirectoryEntry | predicate | 0..1 | classBean.relations.key | 0..n | |
| AssociationDirectoryEntry | target | 1..1 | classBean.relations.value | 1..n | |
| AssociationDirectoryEntry | assertedBy | 1..1 | 0..0 | ||
| AssociationDirectoryEntry | resourceName | 0..1 | 0..0 | Associations aren't referenced by 'name', but by URI. This will equal the 'associationID' | |
| AssociationDirectoryEntry | href | 0..1 | NA / CTS2 Specific | ||
| AssociationDirectoryEntry | matchStrength | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationGraph | expansionDepth | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationGraph | expansionDirection | 1..1 | 0..0 | NA / CTS2 Specific | |
| AssociationGraph | grapthFocus | 1..1 | 0..0 | NA / CTS2 Specific | |
| AssociationGraph | focusEntity | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationGraph | directoryFilter | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationGraph | sortCriteria | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationGraph | numEntries | 1..1 | 0..0 | NA / CTS2 Specific | |
| AssociationGraph | complete | 1..1 | 0..0 | NA / CTS2 Specific | |
| AssociationGraph | next | 0..1 | 0..0 | NA / CTS2 Specific | |
| AssociationGraph | prev | 0..1 | 0..0 | NA / CTS2 Specific | |
| GraphNode | nodeNumber | 1..1 | 0..0 | NA / CTS2 Specific Graph Node info | |
| GraphNode | direction | 1..1 | 0..0 | NA / CTS2 Specific | |
| GraphNode | nextNodeNumber | 1..1 | 0..0 | NA / CTS2 Specific | |
| GraphNode | nodeEntity | 1..1 | 0..0 | ||
| GraphNode | associationID | 1..1 | There is no identity given to the triple by Bioportal, so we will have to generate or concat something. | ||
| GraphNode | subject | 1..1 | classbean.id | 1..1 | |
| GraphNode | predicate | 1..1 | classBean.relations.key | 0..n | |
| GraphNode | target | 1..n | classBean.relations.value | 1..n | |
| GraphNode | assertedBy | 1..1 | 0..0 | ||
| GraphNode | resourceName | 1..1 | 0..0 | Associations aren't referenced by 'name', but by URI. This will equal the 'associationID' | |
| GraphNode | href | 1..1 | NA / CTS2 Specific | ||
| GraphNode | matchStrength | 1..1 | 0..0 | NA / CTS2 Specific |