2015 December Face-to-Face Meeting Notes 

• centOS 7
  • centOS 7 hasn't been used by the Mayo team (as of yet.)
  • There is much interest in the automated environment setup provided by Docker.
  • Sarah indicated that it would NOT be an upgrade on the existing web servers.  They would recommend this for new servers.  
  • As of Sept 30, centOS 7 is to the current supported catalog at NCI.  They still provide previous centOS 6 for several years.  Redhat dates 2020 for centOS 6 and 2024 for centOS7.
  • Scott also suggested the use of a Sonatype Nexus server to distribute Docker artifacts.   NCI currently provides a Nexus server.  However Docker artifacts are fairly large and infrastructure would need to be considered.  
  • Additional Docker discussion later in the week.    There are 2 use cases - deploying at NCI and supporting other users (setup). 
  • MariaDB is a MySQL fork.  Advantages aren't known at this time.   The NCI database team would need provide support if MariaDB were to be used.  This may be in the future Tech Catalog. 
  • Sarah recommended that we hold off on deciding on CentOS 7 until the use of Docker is further defined.
  • Larry pointed out that centOS 7 has additional security enhancements. Jacob indicated there is no current mandates to move to centOS 7.
  • Gilberto shared that the Protege Project is planning on using Docker.
• Java 8
  • Scott shared that he was able to compile LexEVS with Java 8, but no testing had been completed.
  • Scott looked at the potential Tomcat issue and determined that this is not a concern if using Tomcat 7.0.5.8 or higher.
  • Gilberto shared that for the Protege Project uses Java 8 - the only issues were around concurrency.  
  • Sarah indicated that there are other projects that are built with Java 8 and Java 8 and Tomcat 7.  There is full support for Java 8 and Tomcat 7 at NCI.  Sarah would need to know the exact version numbers.   
  • TODO:  Scott to send Sara the version numbers for Tomcat.
  • Kim can demonstrate an error with Java 8 and Spring 2.?  Kim and Scott to discuss.
  • Gilberto indicted that will need to move to Java 8.  Oracle dates are what drive moving from version to version.  
  • There is no plan to deprecate Java 7 at NCI (typically a 2 year lead time).
  • Tomcat 7 Java 1.7 will be deprecated in 2017.
  • This will be considered for 6.5.
• Spring Migration
  • Scott indicated that after testing the Spring 4 - there are much DAO changes.  
  • This should be considered with Java 8 upgrade.
• Roadmap/Next Steps
  • centOS 7 - no immediate plans - defined after further discussions around use of Docker.
    • Will need to consider hardware configurations to support centOS 7 deployments (March 2016 timeframe)
  • Updates considered for 6.5 timeframe:
    • Java 8
    • Spring 4

Discussion: LEXEVS API/Browser Performance and Usability Improvements

• Value Set
  • Rob noted that using the compiled value set definitions requires an extra step.  Tracy indicated that they aren't sure how those are being used.   
  • Need to look at compiled value set definitions.  
• Tree Performance
  • Kim noted that it would be good to provide capability to identify if a node is a leaf node. Can currently do this with multiple calls.
  • Scott noted there are a couple of pending JIRA items; notably, the iterator issue - knowing the graph size (provide number of nodes)
  • Kim noted that Triple Store usage -  GLEEN - provides extension for graph query in triple store. 
    • GLEEN  http://sig.biostr.washington.edu/projects/ontviews/gleen/
• Usability
  • Kim suggested way to provide inbound and outbound
  • Scott noted that we shouldn't change existing API, but add extensions. 
  • Kim indicated that current model is complex for the API - requires multiple calls to query.  
  • Scott requested that a list of API enhancement requests be provided by Kim and then we can prioritized.
  • Larry indicated that there has been a much larger usage of the CTS2 REST API, so it may make sense to focus on CTS2 and not Java API.  
  • Kim - CTS2 API needs to be expanded to fully support browser development.   Scott identified that CTS2 implementation would need to be further implemented to support all CTS2 functionality.  
  • Kim - LexEVS currently doesn't provide way to prevent pulling entire code system.  Scott suggested that the API could govern this functionality.
  • Kim - No way to retrieve concept with role group (class expression in OWL with specific format).  Scott noted that this may be impossible.  
    • Gilberto - Use case is for the browser - wanting to show role groups.  Currently everything is jumbled together.   
    • Scott indicated that to support this, a model change would be needed in order to reconstruct this content.  
    • Gilberto noted that LexEVS model was to flatten the models and LexEVS wasn't intended to represent this complex modeling.  Noted that we need to consider performance.  We could also use something to supplement LexEVS terminology services (triple store and LexEVS hybrid)
• Modeling 
  • Scott - how can we derive a solution?  Is this sufficient within our group or do we reach out to the larger community.   Larry indicated that it may be more of a decision for NCI and Mayo group.    Scott suggested that if we start down the path of updating the model, we would then like to have additional resources participate. 
    • Larry - identify the use cases around OWL and then identify resources to review.   
    • It was suggested that we involve Harold to start this discussion.
  • Gilberto suggested that if we are going to support Round-tripping of OWL and other OWL is to maintain validity of format - this would allow NO loss in and out of LexEVS. 
    • • • Scott indicated this would be a huge effort.  
        • Rob noted that LexGrid XML format was also available.
• Multi-Namespaces
  • Gilberto described "Hierarchy traversal based off of namespace" and the other to be able to "Traverse horizontally"
    • Described the use case - Load NCIT and have GO - and crossing namespaces to support crossing coding schemes to GO.
    • Maps would be needed to support crossing coding schemes.
    • Scott noted that for example, with RRF, we already of the CUIs for traversal.
    • Tracy suggested query a coding scheme for it's namespaces and query the other coding schemes for their namespaces.
    • Gilberto noted that OBI may refer to 20 other namespaces - and then have LexEVS determine if those other namespaces exist.
    • Sherri suggested that the specific use case be documented by Gilberto.
    • Tracy suggested the use of the URI resolver.  Scott indicated that would be overkill for this purpose, but could be used - but noted that it might be heavy weight to have another service.  
    • Sherri asked if the identifiers were standard.  Gilberto described how identifiers are created - ie. hash.
• Relationship query
  • Gilberto described the use case - For any vocabulary we have - "give me all the concepts that have this association y"
  • Scott noted that this would not be easy in LexEVS.   Perhaps SPARQL would be the better choice.
  • Gilberto suggested to flatten out class expression 
  • Tracy - anonymous classes are structured - is it possible to create an extension to parse?  Scott indicated this is possible - however, performance may be a consideration.   It was noticed this would typically be done one at a time.  
  • Scott - if flattened, the parenthetical is lost.  Gilberto noted we still need to be able to do this.  
  • Larry suggested the use of a flag to indicated flattened.
  • Gilberto noted the browser would like to be able to display anonymous classes 
  • Scott suggested we need to determine a specific set of requirements an use cases.
• Inferred Data
  • Gilberto described the use case - in some areas of vocabulary there aren't specified relationships, but instead they are inferred.
    • For example, Tell me all the organs in the chest cavity - includes heart, even though it's not specified.
    • Tracy described the need to be able to search on them, but my not need/want to see them.
    • Gilberto noted that currently in LexEVS, cannot flag those that are inferred.  
    • This will require additional discussion. 
• Removal of caCORE 
  • Scott noted that we've brought this up previously.  
  • Web services as part of LexEVS in caCORE framework.  These have been around for quite some time.  
  • Gilberto indicated that caCORE is no longer being used, so indeed this can be removed.
  • It was noted that users were considered, but it was acknowledged that perhaps we didn't document.
  • It was decided that caCORE API can be removed.
• Refactoring Remote API
  • Scott indicated this would all us to update to a more modern Remote API and removal of artifacts from caCORE
  • This should be considered as part of the Spring migration.
• Next Steps
  • Use cases can span many of these areas and will to be considered during ongoing discussions.

Discussion: Enhancing the LEXEVS CTS2 REST Interface

• CTRP Requirements