- Bio-ontologies are becoming increasingly important in semantic alignment for data integration, information exchange, and semantic interoperability. Due to the large number of emerging bio-ontologies, it is challenging for naïve ontology users to search, select, and adopt a “right” ontology for their applications. Therefore, it is important to have a consistent terminology metadata model and a resource for discovering appropriate ontologies or other resource for use in annotating data. This paper aims to seek a common, shareable, and comprehensive method to create, disseminate, and consume metadata about terminology resources.
Ontologies, thesaruri, termiologies, classifications and
coding systems can be referred to collectively as ‘terminology
resources.” Ontologies and other terminology resources are
becoming increasingly important in semantic alignment for
data integration, information exchange, and semantic
interoperability [
An ontology metadata model provides a method to richly characterize terminology resources. It therefore has the potential to mitigate the issue of discovery and improve ontology adoption. It also would facilitate comparison as well as coordination relating to standards and best practices. Structured metadata describes key aspects of a terminology resource such as scope, structure, provenance, availability, and usage statistics. It helps users to identify, evaluate, select, and deploy a resource more effectively and efficiently. The primary goal for this paper is to seek a common, shareable, and comprehensive method to create, disseminate, and consume metadata about terminology resources.
The NCI Center for Biomedical Informatics and Information Technology (CBIIT), NCBO, and National Cancer Research Institute (NCRI) in the U.K. support the fundamental concept that adoption of ontologies by the research and education communities is essential to data sharing, interoperability and reuse. NCI, NCBO and NCRI had a common interest in representing terminology resources using a standard ontology metadata model. Although there are several existing models and standards efforts for an ontology metadata profile, the NCI CBIIT, NCBO, and NCRI realized that no single metadata model could meet the requirements collected from those three institutions in 2012. Therefore we proposed to contribute to a possible standard ontology metadata model by harmonizing existing models.
Major activities of the NCI CBIIT include developing,
coordinating, and/or deploying biomedical-informatics and
scientific-management information technology systems,
infrastructure, open-source applications, semantics, and data
resources in support of the NCI’s research agenda [
The NCBO is one of the National Institutes of Health
Centers for Biomedical Computing (NCBCs). The goal of the
NCBO is to support biomedical researchers by providing
online tools, a web-based BioPortal, and programming
interfaces, enabling researchers to access, review, and integrate
disparate ontological resources in all aspects of biomedical
investigation and clinical practice [
The U.K.’s NCRI focused on the technical and cultural
aspects of data sharing [
The NCRI worked to achieve consensus with and across NCI and NCBO in defining the way forward in promoting standards in order to facilitate international interoperability. A joint group, the Ontology Representation Working Group (ORWG), was founded to serve this purpose. The major goal for the ORWG was to seek a common, shareable and comprehensive method to create, disseminate, and consume metadata about ontologies.
Beside the three institutions that were involved in this
activity, the OBO Foundry [
The development of an ontology metadata model contains four major steps: (A) Review the existing metadata models, (B) Identify important metadata based on a user survey of the three organizations that collaborated on the ORWG, (C) Propose and ballot new extensions and/or modifications toward a new normative edition of an ontology metadata model, and (D) Adoption of the new version by the community.
We reviewed existing ontology metadata models including
ISO/ IEC 19763-3 [
A survey to the NCI, NCBO, and NCRI was created and conducted by the ORWG. The content of the survey was designed based on OMV core. Authors from the three institutions filled out the survey based on their own needs and requirements. Each piece of metadata from the OMV was prioritized as “Low, Medium, or High” and classified as “Required or Optional”. A list of important metadata was finalized based on group consensus. The detailed survey can be found in the Results section. Usability testing was done by applying OMV to four relevant biomedical vocabularies: LOINC, SNOMED CT, RxNorm, and NCI Thesaurus. A summary of the outcome of usability testing results is also described in the Results section.
Based on the results from our survey, review, and OMV usability tests, the ORWG group suggested that further extensions and/or modifications to OMV are an ideal approach to enable OMV to serve as a single model designed to support the requirements of the entities involved in this paper and potentially the rest of the biomedical community.
The OMV extensions influenced the final selection of
metadata in the CTS2 standard. A set of standardized
terminology metadata allows applications using terminology
services to build on a common infrastructure, and improve
interoperability across applications. For example, NCI’s
LexEVS CTS2 server implements a portion of the model, as
does a recent pilot project for implementing a federated
network of terminology service nodes [
The results of this study include (1) a list of important metadata data elements, (2) usability testing results, and (3) a set of recommendations consisting of changes to existing properties and proposed extensions in support of a newly revised version of OMV.
A list of important terminology metadata elements was extracted from the survey results. The content of this survey was derived from the OMV Ontology class. The structure of the OMV contains classes, elements, and relationships. The OMV has 15 classes such as Ontology, Ontology Type, Ontology Language, Ontology Engineering Methodology, Party, etc. Elements are properties or characteristics that are used to describe the class. For example, the Ontology class has 34 elements including URI, name, acronym, version, etc. The relationships link the OMV classes together.
Metadata elements were tagged with an “Occurrence Constraint” (whether an element should be Required or Optional) and “Ranking” (Importance of the element to utility High, Medium, or Low) by the three institutions to judge the importance of the metadata based on their own requirements and needs. Eight out of the 34 OMV metadata elements were identified as “Required” to describe a source (e.g., name, description, and creationDate). Ten out of the 34 metadata elements were identified as “High” priority (e.g., URI, name, and description). Some metadata were classified as both “Required” and “High” (e.g., ontology name and description). Some were ranked as a “High” priority but were also recommended as “Optional”. For example, not all ontologies in the NCBO BioPortal have a URI and some ontologies have more than one URI. Table 1 shows the group’s determination of metadata elements identified as ‘core’.
The OMV was tested with four widely used vocabularies:
LOINC [
A revision to the OMV was recommended by both
refinement of existing OMV ontology class elements [
element name was changed to the widely accepted term. For example, the “name” and “acronym” were changed to the fullName and shortName respectively.
Some textual definitions for elements were modified. For example, the definition of the “fullName” was defined as “the name by which an ontology is known”. Sample values for the element were also included in the definition. For example, the full name of an ontology can be "Logical Observation Identifiers Names and Codes".
information: Elements were relocated to other classes if they did not belong to the OMV Core class. For example, “creationDate” and “modificationDate” were removed from the Core Ontology class and relocated into a newly created Version class.
were identified as not necessary according to group consensus. These unimportant elements were removed from the new model (e.g., “hasPriorVersion”).
e) Harmonization – To refine/extend the model: OMV's single “endorsedBy” element represents an important concept that should be expanded into more atomic elements for greater expression. The “endorsedBy” is a relation between “Ontology” to a "Party" as used in the OMV to represent either a person or organization. Therefore it is difficult to disambiguate the types of entities supporting the ontology. New properties such as “certifiedBy” and “mandatedBy” were added to the OMV extensions in order to capture these details with finer granularity. For example, “certifiedBy” is done under formal reviews by CBIIT or “mandatedBy” for requirements for use by regulatory or governmental agencies such as under the Meaningful Use criteria for deployment of electronic health records in the United States.
The OMV extensions were developed by harmonizing
existing well-known metadata standards such as Dublin Core
[
The ORWG developed a set of recommendations relating to issues for ontology distribution, implementation, and maintenance as well as licensing, provenance, and community participation. A summary of those recommendations are as follows.
a) Core Ontology Metadata: An iterative approach should be adopted to implement consistent ontology metadata beginning with core metadata and moving outward to more comprehensive metadata as it proves beneficial. The scope of the metadata should include core areas such as content, structure, provenance, documentation, and certification. A revised version of OMV core metadata should be evaluated or audited against several ontologies relevant to the biomedical community. Future updates or revisions to the core ontology profile should be created based on the feedback from the evaluation.
of widely adopted models would improve the opportunities for broader adoption, ease of use of existing tools, and therefore the potential for federation and semantic interoperability. To the authors’ knowledge, OMV deployment so far has been within stand-alone environments, although API's (e.g., the REST API in BioPortal) have been used to facilitate query and retrieval. The impact for the replacement of OMV elements would affect NCBO's modeling in BioPortal. Continued observation of emerging models important to the community such as updates to the CTS2 was recommended.
c) Ontology Usage: “knownUsage” is one of the most important and yet difficult metadata elements to capture, measure, or share. “Usage” can be described by a simple declarative example, by actual use case, case study, or by reference to a project, activity, or data. Since it is difficult to define a formal and detailed schema for this element, the ORWG suggested that it should be carefully described with best practices or guidelines to capture information from the community. Language should be succinct, but should emphasize relatively verbose sharing of details of how an ontology is used including successes, failures, challenges, innovations, activities such as mapping or merging, level of effort and so on. The goal is to capture a wide range of instances of how, where and why an ontology is being used, including those outside the primary scope or intent published by the developer. All usage examples could be helpful, even if they are novel or represent outlying use cases.
d) Intellectual Property: Licensing or Rights Expression Description of licensing rights in the current metadata models (i.e., "hasLicense") is fairly general. Additional information about attribution, reuse, distribution, and guidance for variances in licenses should be provided by ontology owners/submitters. These variances include licensing of artifacts as creative works (e.g., Creative Commons), open source licensing of source code, hybrid or dual licensing (e.g., commercial open source), and complexities in licensing by geographic region (e.g., affiliate licensing under IHTSDO for SNOMED-CT).
Terminology Metadata Profiles: Terminology owners are the ideal source to initially populate profiles as well as to curate subsequent revisions. Although users are valuable in providing more atomic updates, annotations, reviews, and unique perspectives, the level of detail in a profile and the difficulty in assuring accuracy requires dependence on a more authoritative and familiar source. Biosharing, for instance recognizes this as well, and attempts to get resource owners to ‘claim’ and update the metadata record. Source information must also be accurate and timely and even with initial population by the ontology owners, continued curation by the manager of the repository or registry remains a significant burden and at risk for obsolescence. The ORWG recommended a common approach where owners or community members may maintain a verified or validated profile locally by populating a “standard” metadata profile based on the revision of the OMV for publication using a unique identifier and namespace. A profile service would be able to periodically query and archive updated ontology profiles or the service could ping the service with the URL to the resource at the moment it is modified or updated.
The lack of a standard terminology metadata schema to
comprehensively describe biomedical ontologies is a challenge
and a barrier to users looking to identify terminology resources
appropriate for their use. Even though a tool such as the
Ontology Recommender [
Of all the available metadata models, the OMV Version 2.4.1 was selected as the best foundation for developing a shared, harmonized, and standard metadata model. However the OMV Consortium has no active governance structure to accept community contributions and there has been no published update since 2009. It is currently insufficient to meet the representational needs of a richer community-based framework. This study identified gaps as well as recommendations to extend and refine features of the OMV.
It is difficult to populate values for non-ontologies since they do not have a more formal/explicit ontological representation. Some “Required” elements in the OMV have to be left blank. For example, LOINC has a NULL value for the required element “hasOntologyLanguage”. Therefore, the occurrence constraints should be loosened to allow the model to fit knowledge representation resources that fall along the various points along the semantic spectrum; from thesauri to controlled vocabularies to taxonomies and to ontologies.
Another prevailing observation was that it was sometimes difficult to find the right values to populate the metadata model for a terminology resource. For example it took one of the authors a full work day to populate values from LOINC for the whole OMV model. In some cases, the information was not readily available (e.g., not published or difficult to find). In other cases, although the information seemed to be reasonably aligned with the metadata description, it was divergent enough to lead to uncertainty about how appropriate a value was for a given metadata element. Perhaps better data was available elsewhere, or a specific value was different enough to suggest the creation of a new metadata element to satisfy a perceived gap in the model. As mentioned earlier, the ontology owner or developer is best suited to seed and maintain the metadata information. This mitigates much of the concern about gaps in knowledge by a curator or the appropriateness of populated values.
Ontology evolution has been defined as the "timely
adaptation of an ontology and consistent propagation of
changes to the dependent artifacts" [
NCBO and NCI’s LexEVS CTS2 server implement a portion of the developed model. Future work should include (1) working with the wider community to validate the model for other terminologies and amend/extend as needed; and (2) developing a set of competency questions, e.g. for creating terminology search queries based on the OMV extension. A search engine based on this could allow users to search appropriate terminologies using a combination of the metadata elements, and perhaps even in combination with Ontology Recommender or a similar tool that suggests ontologies based on sample text input. This should be done in collaboration with the rest of the community, since resources like Biosharing are already working on a ‘wizard’ to help users find data standards that meet their needs.
The ORWG conducted research to identify relevant terminology metadata models that could form the foundation for a standard ontology profile for use by NCI, NCBO, and NCRI. The OMV version 2.4.1 was selected as the base model. It was tested on LOINC, SNOMED-CT, RxNorm, and NCI Thesaurus, resulting in a revision of the OMV. The OMV extension, already partially implemented by NCBO and LexEVS/CTS2, could serve as the starting point for a terminology resource metadata standard in the biomedical research community, providing a framework for further work with other organizations active in this space such as OBO Foundry, RDA, or Biosharing. Even providing a standard set of basic metadata about terminologies would be of great value to help make terminology descriptions consistent across resources.
REFERENCES Action N/A Rename and Refine definition Rename and Refine definition Refine definition Refine definition N/A N/A N/A Rename Remove and Addition (creationDate moves to Version.creationDate and versionDate is added here) Remove (modificationDate moves to Version.modificationDate) Refine definition N/A N/A Refine definition
N/A URI name acronym description documentation reference notes keywords status creationDate modificationDate naturalLanguage numberOfAxioms hasContributor hasCreator usedOntologyEngineeringT ool usedOntologyEngineeringM ethology conformsToKnowledgeRepr esentationParadigm endorsedBy hasDomain isOfType designedForOntologyTask hasFormalityLevel knownUsage hasOntologyLanguage hasOntologySyntax resourceLocator version hasLicense useImports hasPriorVersion isBackwardCompatibleWith isCompatibleWith numberOfClasses numberOfProperties numberOfIndividuals
N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Remove N/A N/A N/A N/A N/A Addition Addition OMV Extensions URI fullName shortName description documentation reference notes keywords developmentStatus versionDate naturalLanguage numberOfAxioms hasContributor hasCreator usedOntologyEngineeringTool Comparable terms from Dublin Core Metadata dc: description