NIH | National Cancer Institute | NCI Wiki  

Versions Compared

Old Version 1

changes.mady.by.user Unknown User (endlecm)

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (endlecm)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

NameRolePresent
Wright, Larry NIH/NCI  x
Fragoso, Gilberto NIH/NCI    x

De Coronado, Sherri    

NIH/NCI   x

Safran, Tracy

NIH/NCI [C]x
Ong, Kim L
ISx
Lucas, Jason R
ISx
Bauer, Scott  Mayox
Stancl, Craig
Mayox
Endle,  CoryMayox
Solbrig, HaroldMayox
Jiang, GuoqianMayox
Wynne, Robert    NIH/NCI [C] 
Tran, Tin    NIH/NCI [C]  
Carlsen, Brian NIH/NCI [C] 
Wong, Joanne NIH/NCI [C] 

Kuntipuram, Kumar

NIH/NCI [C]

 

Haber, MargaretNIH/NCI  x
Campbell, JohnNIH/NCI  x

Agenda

 


Goals

We need to broaden the scope of and participation in this series, and at the same time sharpen the focus. 

  1. LexEVS and CTS2 are planned to continue as key components of NCI terminology services, but NCI also plans to extend beyond them, notably with RDF triple store SPARQL and REST components.  This raises important design and coordination issues.
  2. REST services need substantial extensions, within and beyond CTS2.  NCI plans to offer REST APIs that can support the requirements of its own and others’ applications, and expects a significant component to be REST services from the RDF triple store.  An obvious test case is ability to support EVS browser functionality (even while these browsers will likely use the Java API for some time to come).
  3. We face some immediate needs from other users, notably CTRP and GDC, so need to clarify design approaches and produce new services based on them in the relatively near term.


Agenda

Review and discuss (Kim's/Jason's) concerns

  • Each of these are to support the browser (via java API)
  1. Handling of metadata
    1. Metadata to be stored as RDF
  2. Supported search algorithms (currently, only exactMatch, startsWith, and contains are available)

    1. CTS2 service - would like to have CTS2 support the full LexEVS Search Extension

    2. Need to confirm that the Lucene algorithm is available.

  3. CTS2 Handling of namespace in read service. Could namespace be included as a parameter in a REST call?

    1. entity read service is able to include namespace.

    2. Need to confirm the responses to determine both namespaces are supported for single concept code
    3. Need to provide ability to return concept with different namespaces.
  4. Search against multiple coding schemes (count, ranking, iterator, pagination)
    1. Required for browser
    2. Currently allows search against all, but not a designated set of coding schemes.
  5. Search against multiple mappings and value sets (count, ranking, iterator, pagination)

    1. Required for browser

    2. Currently allows search against all, but not a designated set of coding schemes, mapping and value set API may require additional public methods

  6. Mapping search (count, ranking, iterator, pagination) - currently iterator and pagination are broken in remote LexEVSAPI)

    1. CTS2 will no longer be running against remote (only local)

    2. Broken iterator no longer issue if running local.

  7. Support for property and relationship search?
    1. Need further notes on this.  Graph implementation should cover relationship search.  Properties are currently restricted to presentations, it may mean an extension to supply better coverage to generic property types.
  8. Constrained/restricted search (e.g., restrictToCode on CNS; search only on a particular branch of tree, for instance, Gene, Gene Product -- CTRP like use cases).

    1. Not readily available in CTS2 (as in LexEVS)

    2. Some searching on properties (designations)

  9. Tree construction (expandable status, distance-2 child node count)

    1. Need to have ability to know if a node is expandable or not.

    2. Can be provided by leaf from graph api

  10. Resolving of a graph (transitive closure).
    1. Graph API can provide this - but not implemented today.
  11. Current use of CRC (cyclic redundancy code) in the response, would like to understand better the use?

    1. This is provided in CTS2 response.

    2. This an identifier applied to a definition (IE)

      1. A name for the definition.

      2. In this case, it can be anything to identify the version.

      3. The request is to resolve this identifier on the server rather than passing it back and forth between client and server. This would require an API change.

  12. Issues we face for Triplestore extension: Various OWL formats (e.g., in NCIt the unique idenfier is code, but in GO, it's oboInOWL:id)

    1. CTS2 allows for many identifiers

    2. Gilberto to document and share the concerns for consideration

    3. Similar parallels to URI resolver?

  13. Handling of NCIm and other non-OWL or RDF coding schemes.
CTRP and GDC Issues (Larry, others)
  • Nothing immediate to address
  • Ability to collect a "structured neighborhood of concepts related to a user query"
    • For example, Investigator of a clinical trials protocol will search for a gene, protein, etc. but not specific - and then present a neighborhood in a structured way for the investigator to review.
    • Provide ability to efficiently traverse a set of relationships 
  • Both groups will looking at using REST APIs to get terminology content
  • Nothing additional today, but possible future requirements.
Additional Considerations
  • Modeling of cancer concepts
    • Need to identify the notes/requirements. Possibly notes from previous F2F.
  • Partonomy 
Next Steps
  • Review notes from previous F2F.
  • Determine priority for browser support
  • determine requirements that fit into CTS2
  • Determine an architecture to support requirements that do not fit into CTS2
  • Determine integration of LexEVS, CTS2, Triple Store
    • separate rest services? 
    • discussion necessary

Review current LexEVS CTS2 Services (Cory)

  • Review of existing services was discussed.
  • There are additional structural profiles that we may want to consider for implementation.

Continue discussion around what is missing from current REST CTS2 service. (All)

 

  • OWL2 considerations
    • Statement 
    • BNode (not supported purely in CTS2)
    • No canonical RDF Spec for CTS2
  • Modeling considerations (for example Neoplasm)
    • Flattening of content necessary to represent in LexEVS
    • There are things that were not able to be represented in LexEVS nor CTS2.
      • Issues
        • Restrictions bundled together in role groups
        • Ability to represent conjunctions and disjunctions.
        • within a given cancer, there are multiple prognosis - but will be flattened and nonsensical.
  • Relationship between LexEVS and graph or RDF/SPARQL
    • Support for partonomy
  • GDC groups
  • Value Set complexity
  • Mapping considerations
    • current LexEVS CTS2 support - search and complex construction
  • Available CTS2 services
    • LexEVS widely known service today.
    • Research is looking for a mature standard.  However there are gaps in functionality currently implemented.
    • Suggested that someone represent LexEVS at the FHIR table at HL7.

 

Next Steps
  • Schedule our next meeting to prioritize the above list
    • Schedule focused discussions on each topic (follow on meetings).