NIH | National Cancer Institute | NCI Wiki  

Versions Compared

Old Version 5

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

Saved on

compared with

New Version Current

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

Saved on

Key

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

...

TimeLocationAttendeesResources
11:00 AM - 1:00 PMRoom 5W034Rob, Tracy, Kim, Jason, Scott, Cory, Craig, Ruth, John Campbell, Stephanie LipowEVS_Inventory_1st_Draft_JL.xlsx

...

Goals

  • Document all services that exist for EVS

  • Document Gaps and Overlap of existing services.

  • Describe importance of architecture planned services

  • Describe need for Architect role.

  • Propose possible scenarios for architecture based on services and usage

Topics

TopicDiscussion
topic 1Discussion

Discussion Points: Decision Points:

  • Remote users currently need to use the client jars. This is a concern for the end users. This could be done by updating CTS2 services and provide REST services to these users.
    • caDSR transition would take awhile
    • In the near term, leave the remote services as-is for them.

  • CTS2 supports all the vocabularies (including meta). EVS REST API is limited to Triple Store content using elastic search.
  • Governance of the services is critical in order to provide one central query mechanism.
  • LexEVS will no longer have the stand alone code systems. The Meta will continue to live in LexEVS. There is the possibility for Meta in EVS REST API.
  • The NLM does host UTS API. This could be something to look at.
  • Sorting and Ranking is important for results, but this isn't available in the EVS REST API yet.
  • End users do not have resources to upgrade or the funding. This might be done be the EVS team (rewriting code for interaction layer, etc).
  • CTS2 REST results - different than the EVS REST API.
  • caDSR and Browser are the primary consumers of APIs.
  • Ability for usage analytics - what types of queries being run and what content.
  • Infrastructure
    • Cloud
      • FedRAMP - provides information about cloud services.
      • EVS API noted issues with remote API dropping connections when communicating from the cloud.

Decision Points:

  • Determine a level of governance and architecture for EVS related services.
  • Work with the caDSR team to transition from remote API to REST Services. (TBD?)
  • Propose ability to capture usage statistics for analytics of what types of queries are being run, content searched, etc.
  • Determine a REST service for Metathesaurus and determine best how to support the end users.
  • Continued transition of stand alone coding systems to EVS REST API.
  • Transition of LexEVS search knowledge to the EVS API development team
    • utilize the services spreadsheet
  • Provide LexEVS resources to help with EVS API.
  • Investigate infrastructure considerations (cloud environments?).
  • Single Service coverage (provide single search mechanism)
    • REST Service for Meta
    • EVS REST API
    • LexEVS API


Attachments



https://wiki.nci.nih.gov/display/LexEVS/2018.10+Proposed+F2F+Agenda+Topics

...