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

Participants

Harold Solbrig, Sherri de Coronado, Hua Min, Grace Stafford, Rick Kiefer, Troy Bleeker, Larry Wright, Stuart Turner

Topic: CTS 2: History, Status and Areas of Interest (to the ORWG)

Presentation by Harold Solbrig

  1. Derives from Lexicon Query Services (LQS 1999) - the model has remained a good guide to terminologies today
  2. Contributions by HL7 (healthcare) with CTS ~2001-2004. CTS2 vetted 2010 and OMG (services, modeling, etc.)
    1. HL7 created services functional model (see http://wiki.hl7.org/index.php?title=Product_DSS_SFM and HL7 meeting minutes (Brazil, 2010) here: http://tinyurl.com/4rbmehh)
  3. CTS2 to fill-in gaps to CTS1 and in part LQS such as history, versioning, mapping, etc. Goal to have more open review (than typical to OMG) for comments by the community. 24 February deadline pushed ahead a bit to allow broader review.  Would like potential major users, e.g. IHTSDO, to provide feedback first.
  4. Participants (RFP response toward development of CTS 2)
    1. Mayo
    2. ii4sm (http://www.ii4sm.com/)
    3. Visum Point (http://www.visumpoint.com/)
  5. 21 May 2011 official submission date to OMG (tentative). Also drop a draft submission on the prior deadline in February
  6. Consumers (some) of CTS2 (in addition to caBIG/ NCI)
    1. CDC's PHIN VADS (http://phinvads.cdc.gov/vads/SearchVocab.action)
    2. Veterans Administration
    3. Office of the National Coordinator (for Health IT) - ONC/ONCHIT
    4. IHTSDO
    5. HSDB (Hazardous Substance Databank at the NLM?)
  7. Requirements or development influences
    1. Versioning updates
    2. "Authoring"
      1. More narrow approach
      2. Model of incremental change. To construct change sets, to open, review, package and make available
    3. Data binding
    4. Reasoning and inference [Is this really in CTS2 ?  SDC)
    5. Alignment with development (software) of LexEVS
    6. "not yet another health terminology service standard" - goal to broaden the scope of CTS2 to build a domain agnostic terminology (not just healthcare) standard including development and support through semantic web community. Being balloted at OMG through ontology platform special interest group as a general specification. (not healthcare group) with review by modeling and process and W3C expertise.
    7. Goal to host a CTS2 rest server, working with NCBO/Stanford and a path to extend the REST architecture to CTS2.  (NCBO keen on this, and NCI seeing more requests for REST).
    8. Using z for semantics as an alternative to OCL (object constraint language) as well as UML for structure (ii4sm had constrained to SROIQ http://www.w3.org/2007/OWL/wiki/SROIQ reasoner logic as well).
  8. Draft has yielded sections for a PIM and 3 PSM models  (?)
  9. An API specification for LexEVS is available, however producing this as a specification is much different than one for designed for someone to independently reproduce LexEVS-like functionality within a different environment. Have been able to implement CTS2 using LexEVS and has worked bidirectionally to support existing users as well as evolve the CTS2 specification.
  10. Documentation in LaTeX has been eased by rolling everything back into the UML model and generating the LaTeX syntax from there, rather than maintaining separate, modular documents for rendering or typesetting.
  11. REST has allowed quite a fine-grained conformance model. Supporting the "linear value proposition" as described for SAIF. Including publishing a directory of ontologies (and metadata about them). Part of this is resource definitions and axis, a functional axis, a representational axis (inputs/outputs), a bridge between RDF triples and the structured model.
    1. Resource axes
      1. Code system and code system version
      2. Allows for a provider to specify just a code system and/or code system version (describing content and content changes).
      3. Entities
      4. Relationships
      5. Value set
        1. Definition
        2. Resolution (binding)
      6. Concept domain (bridge data elements and value sets)
      7. Mapping (versions, etc.). Much informed by IHTSDO mapping model?
    2. Functional axes
      1. Code system read service (simplest method) (implemented using XML editor and Apache)
      2. Search and filter
      3. Import and export (profile that describes API for loading from external sources)
        1. No specification to go from RRF to CTS2, or OBO, etc. Needs an add-on at some point that defines formal mapping. Loaders do exist and implement same loaders that exist now.
        2. IHSTDO may require formal mapping specification before they'll fully support CTS2
      4. Incremental update
      5. Authoring (build change sets)
      6. History (ask questions about a particular resource)
      7. Temporal (state of a resource by date)
    3. Representational axes
      1. Conformance
      2. Compliance
      3. XML
      4. JSON
      5. RDF (source?), and "CRDF" or "canonical RDF". Natasha Noy requested to define a set of tags that could all derive from existing tag sets (e.g. SKOS note, OWL, RDF, Dublin Core, etc.). May become best practices for terminology content.
          1. See also "structWF" and the RDF Canonical Data Model? (http://techwiki.openstructs.org/index.php/Data_Federation_with_structWSF)
      6. REST, SOAP, Java objects
  12. CTS 2 UML model (in Enterprise Architect format) on Mayo site (http://informatics.mayo.edu/cts2/index.php/Main_Page)
    1. Sectioned into computational and informational
    2. Putting tags in model to allow generation of LaTeX and z representation. Using an XML transform to generate z and LaTeX.
  13. Roadmap
  14. Code System and Code System Version
  15. Core (building blocks)
  16. Resource description
    1. Distinguishing between external URI and a rendering URI that returns formatted information about the resource (in other words an abstraction representation and an actual instance).
    2. Resource type
    3. Resource ID
      1. Local name (context of the service, uniquely identifies the resource)
    4. Keywords (derived from OMV) - type is string - not intended to be a controlled vocabulary at this time (if it were would change type to valueset). Essentially an uncontrolled folksonomy
    5. Classifications from OMV (domain, task, language...etc.)
    6. URI's defined by six types; external, rendering (when dereferenced will provide CTS2 compliant returns), document (name external resource that may or may not exist - a file/system - where resource derived), directory (represents the result of a query), nameset
      1. IRI missing - "international" implies platform specific because of use of an international character set. In the PIM level to reference an IRI known to the W3C.
      2. Local Resource Identifiers (LRI). See OWL 2's Anonymous Individuals (see section 2.7.1 @ http://www.w3.org/TR/owl2-new-features/#Anonymous_Individuals)
        1. not global
  17. See Ontology Platform Special Interest Group (PSIG @ OMG): http://www.omg.org/ontology/
  18. Model allows representation as either asserted or inferred with reference to one or more reasoning algorithms (not functional reasoners per se, as well as the presumption that the ontology is monotonic (of entailment))
  19. Entities must be compatible with SKOS concept, OWL class, OWL individual, RDF property, otherwise one may wish to use a database or DBMS (Did he say anything about SKOS individuals of SKOS concept?  Just curious, because SI V2 group looking at using NCIt in SKOS (having converted classes to instances of SKOS concept) as intermediary between conceptual and logical models.  But I guess they just need to store it separately, not in LexEVS... in lexevs it would not be in SKOS anyway...SDC thinking out loud.)
  20. To use term "synopsis" because OMV's use of "description" is overloaded
  21. Code system versions a Directory URI will give list of all versions of code systems known to the service
  22. Tags known to the service (labels that may be associated with versions, with rules)
    1. Specification: Declare one canonical tag called "current". Rule is a service provider has option of assigning current to a particular version of any code system, if not it will default to the "most recent version". Some might differentiate as "production" version, "developmental" version.
  23. Are names of sources really ontologies? They need URI's in any case.
  24. Collapsed OMV source into source and role reference, rather than a specific enumerations in (2.4.1?) version. Such as "creator", "reviewer"
  25. Bibliographic sources - Harold described how the FMA faithfully represents the source (book, chapter, edition, page...). Uses "opaque" data type (see: http://en.wikipedia.org/wiki/Opaque_data_type)
  26. Rights
    1. Working to better define a well-defined rights model
  27. Note
    1. SKOS - 5 subtypes
      1. Resolve that definition is quite a bit different and in a code system, definition may not be a valid note tag
      2. Introduced a "comment" type and left it concrete
      3. Scope, history, editorial, change,
  28. Example introduced into CTS2 - a pattern that should be represented by a new tag
  29. Definitions: types, preferred, alternate and hidden?
    1. Review other candidate types to represent trust or authority (e.g. normative vs. informative as representations for preferred or alternate respectively).
  30. Property
  31. Source Statements
    1. None of the above (to do a call and retrieve everything, often requested by developers)
  32. Active resources
    1. Appear in everyday searches
    2. If inactive, you can get to it by "id", but won't show up in a normal query  (LexEVS default is active=yes.  Note that a terminology can have another property like "deprecated".  Active can = yes, while there is still a deprecated property = yes.  etc.  SDC)
  33. Status (external identifier assigned by whoever created/authored it) --( Is this the same as what I just added above? SDC)
    1. May have to map between internal and external status
  34. Owner
  35. Association
    1. Assertions in imported ontology are carried over to its target
    2. If one then wishes to change something about the imported ontology (as it exists in the import), then one can no longer say that it is imported
    3. This creates problems in editors. So imported ontologies (those not the primary ontology), are grayed out so changes cannnot be made and the imported assertion can remain true
    4. Led to two attributions for every resource (example: wine ontology imported to food ontology)
      1. Asserted by (food)
      2. Asserted in (wine)
    5. Question led to whether CTS2 should declare business rules, or gives business rule authors ability to enforce it as they desire. This may address IP and other issues.
  • No labels