Page History

De Coronado, Sherri    

Safran, Tracy

Kuntipuram, Kumar

Sprint Status

Current Sprint -  Sprint 51 (March 2, 2017 – March 15, 2017)

16X237 Agile Development - Sprint Status#16X237AgileDevelopment-SprintStatus-Sprint51

Triple store discussion

Discussion Points:

• LexEVS 6.5.0 Release
• OWL2 Transition
• Value Set Architecture
• REST Architecture
  
• DevOps:

• Docker setup at NCI
  

Scott mentioned the OBO loader issue should be considered as well.

Larry suggested that the priority list as follows:

• OWL 2 transition is a priority 
• Value Set loads (issues described by Rob)
  • There are still some loading issues
    
    • Searching against a coding scheme that doesn't exist
    • Rob to provide an example of what if failing.
• LexEVS 6.5.0 Release 
• Value Set Architecture
• REST Architecture
• DevOps: Docker setup at NCI

Decision Points:

• Rob to provide example of issues with the value sets that are loaded incorrectly.
  

Discussion Points:

• Scott asked when the (scrubbed) OWL 2 Thesaurus source will be available.
  • Rob mentioned that they are currently working on it and will have a version available soon.
    

Decision Points:

• Rob, Tracy, Scott, and Kim to work together on the new OWL 2 loads and determine why Kim's code is failing.
  • Kim will provide the stack trace of the issue.

• Kim to create a JIRA issue for the source qualifier issue that he is seeing in the Terms browser

• Gilberto gave an overview of the current status of the triple stores.
• Gilberto is waiting for quotes to come back.
• Stardog has another version coming out that may improve performance.
  

Decision Points:

• The team decided to go with Stardog if we can get several developer licenses for a discount.  (They charge $8600/developer license).  Otherwise we will go with Virtuoso.

DEV Server Configurations

• DEV Blade
  • 6.4.1.3.FINAL
  • Separate DB
  • 5.0 Snapshot

Discussion Points:

• Jacob anticipates the DEV blade VM will be installed with the 6.4.1.3 FINAL by early next week.
   Cory created a ticket for Jacob to create separate MySQL 5.6 DBs for the DEV blade and VM instancesis waiting on the creation of the MySQL 5.6 DB for the blade server.
• The API set up but pointing to existing 5.6 db for the VM.

• Access to the server and the URLs should be completed before Friday.

• Once the Dev blade system is installed and configured, Kim will test his browser on it.
• Yeon is working on the DB configuration and it will be ready by EOD today.
• Jacob mentioned (in an email) that the blade server should be ready before Friday this week.

Decision Points:

Value Set Loading Enhancements

• Load Planning Update

Discussion Points:

• LexEVS Meeting Minutes - Value Set Architecture Planning Session - 2017.03.02
• We discussed how we could automate testing of loaded value set definitions and resolved value sets (in the meeting link above).
• Tracy suggested starting from scratch to fix this error-prone approach.
• Rob asked if we could we use the content of Thesaurus for populating the value set?
• We could look into using an OWL based approach
  
  • Concept in subset.
• Tracy suggested that this could be a prototype for outside groups to use too.
• We will continue this discussion at our value set meeting next Tuesday, 3/14.
  

Decision Points:

• Scott to test the value set load on the NCI DEV system.
• Mayo dev team will look into a new architecture/design for generating the value sets.
  

• Once Tracy and Rob are both back, we will set up a meeting with both of them.
• Rob suggested that he could offer suggestions on where the current workflow is broken.
  

Decision Points:

Discussion Points: 

• REST Service Architecture
• The Mayo dev team looked at the 6 CTS2 issues and determined what was possible for each.
  
• LEXEVSCTS2-138: This fits within the realm of the CTS2 spec and could be implemented as a part of that specification
• LEXEVSCTS2-139, 140: These are LexEVS coding scheme metadata and don’t really have a good counterpart or fit in CTS2.  We’d likely want to provide a separate resource or service for these. 
• LEXEVSCTS2-142: Return only the specified information on an entity
  
  • This would be a new call that returned a new partial resource
• LEXEVSCTS2-143: Return a property type for an entity 
  • This would be a new call that returned a new partial resource
  • Example Call
    
    • https://lexevscts2.nci.nih.gov/lexevscts2/codesystem/NCI_Thesaurus/version/16.12d/entity/C422?format=json
  • Would need to filter the properties to return this specific property type 
• LEXEVSCTS2-144:  Retrieve a concept based on the presence of a restriction
  • Workflow - series of calls to get from CTS2
  • A new wrapper/extension REST call would need to be created to do this in one call.

• Priorities (suggested by Tracy)
• • Ability to retrieve the FULL_SYN information (Larry)
  • Search on property for a given criteria
    • Give me all the concepts that have a specific property
  • Limit the result set coming back.
   

Decision Points:

• Set up meeting to look at examples and discuss.
• Start to add to sprints - convenience methods for
  
  • LEXEVSCTS2-142, LEXEVSCTS2-143
    

Discussion Points:

• Gilberto - from the snippet that Scott provided: an annotation property that doesn't have a range.
• There have been JIRA issues that were created for the points that Gilberto discussed.
   

Decision Points:

• Gilberto to send an OBO example code snippet for the issues he discussed

• needs to capture the end user requirements and and then come up with some suggested approaches.
• Larry suggested that the CTS2 calls work but may not be efficient for what the user is requesting.
  

Decision Points:

Discussion Points:

Decision Points:

• We decided we should initiate contact with the NCI dev ops team to determine a road map/plan to set up our system tests there.
  

Resolving all relationships for a given association

Discussion Points:

• Scott noted that only the default namespace is loaded in our LexEVS loader. 
  
• Gilberto suggested that OBO format is deprecated and we shouldn't spend time on this
• What is the use case for resolving all relationships for a given association. 
  
• Is there a requirement for Enumerations
  
• There is a workaround that can retrieve these relationships, but we should discuss implementing a more efficient API call.
  

Decision Points:

• Scott will create a JIRA item to track this issue.

Discussion Points:

Decision Points:

Mayo Team

• Cory -
• Scott - March 14
• Craig -

NCI

• Tracy
  • March 9-17
• Rob
  

  • March 20-24