Skip Navigation
NIH | National Cancer Institute | NCI Wiki   New Account Help Tips
Page tree
Skip to end of metadata
Go to start of metadata


August 5, 2010


Sherri DeCoronado, Larry Wright, Stuart Turner, Harold Solbrig, Jyoti Pathak, Natasha Noy, Trish Whetzel, Hua Min, Riki Ohira


  • Discussion on version and how to handle the metadata for versioning.
  • BioPortal has an extension of OMV that has a list of versions, a list of use, and a pointer to the current version, which is not in OMV, but in the BioPortal metadata.
  • For CTS2 specifications, we need to make sure it aligns with OMV as much as possible.
  • Natasha Noy gave presentations on these calls discussing what was extended
  • Q: Is the hierarchy of the OMV extensions in BioPortal? A: Yes.
  • Can't see all the properties in BioPortal, so sometimes you need to download the whole thing to see all the properties.
  • Trish Whetzel displayed the Class for metadata:VirtualOntology, and show OMV ontology class
    • VirtualOntology is a container for all version
    • Almost all properties are version dependent, except for the name
    • Challenge is that sometimes we want to publish metadata that doesn't get down to version level
      • What's available, what it is used for, and who to contact to learn more about it
      • Metadata about a terminology that is not associated with a specific instance is of value
      • Once we include version information, we are committing ourselves to "maintain" and "update" this information
      • Mayo has a terminology that is proprietary, but we have metadata about it that does not include the actual terminology or information specific to that instance.
      • Are the categories in OMV sufficient to supply general metadata about a terminology without having to get into version/instance specific information?
    • Use Case: Information about legacy data and needing to know differences between version 1 versus version 2
    • The challenge in an abstract sense, there is something called SNOMED-CT, and the characteristics it has outside of its version, so there are two levels of information about a terminology
    • What is the version-independent URI for SNOMED-CT? How does one find that if they are looking for information not related to a given version.
      • URI vs. URL: URI does not need to have a specific location (URI is identifier, and URL is location); ideally the URI is the URL
  • Stuart Turner and Sherri DeCoronado went through the table of OMV categories
    • Required information based on OMV: URI, name, description,
      • URI should be optional since it is a hard piece of information to find, not canonical, and sometimes there are many (hard to come to consensus from the community)
      • Q: Are we moving away from OMV and focusing on BioPortal? A: BioPortal is based on OMV. Q: BioPortal's intent to feed it back into OMV? A: Yes, but it's difficult because there is no one participating in OMV.
      • Group agreed to have BioPortal as the basis for this effort
      • We need to acknowledge that some terminologies have several URIs; different communities will claim different URIs as canonical source.
      • User Interface may not let you add more than one, since we had not addressed the issue of multiple URIs for a given terminology
      • There is a need to have a canonical URI, but it is context specific and difficult to get community consensus. There needs to be a consensus service that can maintain and monitor community needs for why any given URI is determined canonical.
    • Important to have user manual to help users know how to populate the information/metadata about the terminology
    • We ask the question, "What is the current versions of SNOMED-CT that are loaded?" and would expect two use cases: 1) Need URI that says SNOMED-CT not associated with a specific version, and 2) Need information about a specific version of SNOMED-CT (which would be a different URI)
    • name: REQUIRED
    • description: REQUIRED
      • Description could be from original source or developed by user, but we need guidance on this.
      • This gets back to provenance of the terminology
      • The description is version independent, and should reference the original source is the description
    • creationDate: OPTIONAL
      • Needs to be clarified. If it is the creation date, users may not know, but if it is the version date, that might be different
      • Or we can rename to something more specific, like Version Release Date
    • naturalLanguage: REQUIRED
      • Seen as important, but not sure how to handle those terminologies that do not have a single naturalLanguage
      • Example: Agrovoc is a multi-language
      • There could be the option of "multiple" for those without single naturalLanguage value
      • May want to qualify that it is primarily of a single language if there are some terminologies that have a small portion of other languages
  • The group will continue to review the required OMV properties to determine if they should be required and what are the challenges associated with that property (if the group needs to do something to clarify the use of the property)


  • Natasha Noy/Stuart Turner: Send presentation slides of the extensions of OMV on version to Harold Solbrig
  • The Group: Need to clarify definition of URI, creationDate.
  • The Group: Look through the "Required" properties and discuss off-line for next meeting in terms of what to include as required.
  • No labels