CTS2/doc/Primer
Contents
Intro to the Specification
CTS2 is designed to address a broad range of requirements within the ontology and terminology community. The use cases range for a need to be able to publish simple catalogs that identify what resources are available to the ability to serve the content of multiple formal ontologies, performing online reasoning and classification. The CTS2 specification also recognizes that terminological services will not necessarily be centralized – one organization may publish catalogs, a second content and yet another may serve value sets, maps and other resources based on these tools.
The goal of this specification includes the ability to provide distributed, federated terminology services, enabling replicated service instances that periodically synchronize their content as well as service instances that reference the content in other instances. Our goal in no small part is to provide the core infrastructure that allows terminology services to be coupled and interlinked in much the same way that pages are interlinked today in the World Wide Web. Many of the design decisions that went into this specification reflect this need.
Intro to the Resources
Code System Catalog – metadata about code systems (ontologies, code sets, thesauri, classification systems, etc.). A service would implement this section to publish information about what sort of terminological resources are available, who maintains them, what they are intended to be used for, how often they are released, what copyrights pertain to them, etc.
Code System Version Catalog – metadata about specific versions of code systems. A service would implement this section to provide information about specific versions of code systems – when they were released, what format they are in, when they were intended to become active, which version they replace, etc.
Entity Description – a set of entity (aka. “class”, “category”, “concept”, “predicate”, “property”, “term”, “individual”) identifiers known to the service along with information about which code system versions make assertions about these identifiers and what they say. The entity description service focuses on the lexical aspect of entity identifiers – providing access to the designations, definitions, descriptions, examples, usage notes and other artifacts used to represent the meaning of the entity to human consumers. Services would implement this section to publish information about the codes described in various versions of code systems along with their intended meanings.
Association – sets of “semantic” assertions about entity identifiers, in which the entity identifier may play the role of subject, predicate (verb) or object in the assertions. This area represents the formal machine interpretable aspects of code systems, and a service would implement this section to support classification, reasoning or other computational logic systems built on terminological content.
Value Set Catalog – metadata about sets of entity identifiers (value sets) that have been grouped for some purpose. A service would implement this section if it wanted to publish information about these collections such as who created them, who maintains them, what is their purpose, what code systems do they depend on, how they are updated, etc.
Value Set Definition - information about how value sets are constructed. A value set definition can be a simple enumeration of its elements or can contain instructions about how the elements are assembled from aspects of entity descriptions and associations. Value set definitions may be coupled to specific versions of code system, or may be defined in a way that they could be applied to different versions, potentially with different results. Services would implement this section to publish the rules on the construction of value sets. The value set definition section includes an optional sub- section (Resolved Value Set) that enables the publication, loading and use of the results of applying value set definitions. Services would implement this section when they needed to consume and use value sets without having access to the underlying code systems.
Concept Domain Catalog – a catalog of abstract “concept domains” that represent a collection of possible meanings. Concept domains are intended to represent the intended meaning of a field on a form, a column in a database, a field in a message, etc. The CTS2 specification focuses on enumerated concept domains – fields that represent discrete collections of “meanings”, each of which is represented by a permissible value. A service would implement this section to provide a list of generic fields that would be used in data interchange.
Concept Domain Binding – the coupling of a concept domain with a value set, where the value set provides a list of possible meanings that can be used in a concept domain in a particular use case or context.
Map Catalog – a catalog of “maps” - collection of rules that allow human or machine assisted transformation between the codes in one value set or code system and those in a second. A service would implement this section to publish information about which rule sets are available, which code systems or value sets they map between, their intended purpose, how often they are published, what formats they are in, etc.
Map Version – an instance of a map, including the specific value set definitions that and code systems that they are based on and the actual rules. A service would implement this section if it wished to publish the content of maps. This section includes an optional sub-section (Map Resolution) that provides access to the machine aided interpretation of map versions – a service that does the actual map transformation.
Statement - a bridge between the information contained in the various sections described above and the actual assertions made by the information providers. A service would implement this section when it needed to provide additional provenance about assertions made in catalogs or resource versions including what was actually said, how it mapped to the CTS2 service representation, the provenance of the assertion, etc. Statement is also intended to act as a bridge between the structured CTS2 model and simple subject/predicate/target systems as represented by OWL and RDF.
Intro to the Functionality
This specification is also intended to support a number of functional areas including:
Read – direct access to the contents of a resource via URI, local identifier or, where applicable, a combination of an abstract resource identifier and version tag (e.g. SNOMED-CT / Current version)
Query – the ability to access, combine and filter lists of resources based on the resource content and user context Import and Export – the ability to import external content into the service and/or export the contents of the service in different formats
Update – the ability to validate load sets of changes into the service that updates its content
History – the ability to determine what changes have occurred over stated periods of time
Maintenance – the ability to create and commit sets of changes
Temporal – the ability to ask questions about the state of the service at a given point in the past (or future).
Specialized – service specific functions such as the association reasoning services, the map entry services and the resolved value set services.
The Import, Export and Temporal functions are generic – there are no resource specific aspects to these services and, as such, they are defined once in the Core Service Elements module. The remaining components have different signatures depending on the structural domain to which they are applied.
The CTS2 specification is subdivided into the following sections:
Core Model Elements – this section defines the data types, building blocks, and basic interfaces that are shared across more than one structural or functional area. All of the remaining sections have dependencies on the Core no dependencies between any of the remaining sections that follow. Each of the remaining sections, when combined with the core, can stand by itself.
Code System and Code System Version Catalog Services – this section describes two independent modules: Code System Catalog Services and Code System Version Catalog Services.
Entity Description Services – this section describes two independent but closely related modules: Entity Description Services and Association Services.
Value Set Services – this section describes the Value Set Catalog and the Value Set Definition services.
Concept Domain and Concept Domain Binding Services - this section describes the Concept Domain and Concept Domain Binding services
Map Services – this section describes the Map Catalog and Map Version services, which includes the Map Resolution service.
Statement Services – this section describes the statement services
With the exception of the Core Model Elements, each of the modules described above is specified using the following pattern:
Resource Information Model – the first section of the module describes the structure and content of the resource(s) used in this module. This description includes what constitutes the identity of the particular resource, which elements must be present, which are optional and which are computed by the service itself. Identifying and computed components are marked as read only to make it clear what aspects of the resource can be modified.
Resource Directory and List Model – the query function returns lists of resources. There are two purposes for these lists – the first is to summarize the set of resources that have passed the filter criteria and to provide links that can be used to access the details of the resource directly. This type if list is referred to as a Directory. The second purpose of these lists is to gather complete images of the actual resource for some secondary purpose. These sets of complete resource images are referred to as Lists. Note that the modules will define both types of list (Directory and List) even when the summary consists of the entire resource image.
Read Services – the methods that are available for direct access to the resources. These methods come in pairs – one for testing existence of a resource and a second for actually retrieving it. All resources provide URI access. Note that the URI is passed as a parameter to the function. The CTS2 specification makes a clear distinction between the HTTP URI that would be used to access the query service and the URI of the resource itself. In no case is the CTS2 service URI to be used as the identity of the resource itself.
Query Services – query services all start with a general pattern. The service provides a URI of type DirectoryURI that represents all of the instances of the particular resource that is known to the service. This URI represents both active and inactive resources and, if the Temporal compliance profile is supported, represents the all possible service states. The query service then provides a number of generic and structural specific methods, each of which takes a DirectoryURI as input and returns another DirectoryURI that, when resolved, returns the result of applying the filter to the input URI. Operations are also available for the union, intersection and difference of resource instances. The query services then provide two additional methods, resolve and resolveAsList which respectively return Directories and Lists (as described above).
History Services – history services consist of several common methods to access and query change sets along with three additional methods – one to return the earliest known state of a resource, a second to return the current state along and the third to return an ordered list of states. Resource states include historical information about what changed, who did it, when, etc.
Maintenance services – each module will have a method that allows the creation of the minimal valid resource (identity and required fields) and a second that allows modification of a resource, which allows the addition and update of non-identifying, non-computed content. The services also include generic methods for creating, querying, committing and rolling back change sets. The CTS2 specification requires the following sequence in order to make a change to the service state through a maintenance service:
- Create a new change set
- Make one or more changes to one or more resources, providing the URI of the created change set c. Update any additional provenance information on the change set
- Commit the change set
| 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 |
