Sprint Status | Current Sprint - Sprint 54 (April 13, 2017 – April 26, 2017) 16X237 Agile Development - Sprint Status#16X237AgileDevelopment-SprintStatus-Sprint54 - Tracy mentioned that there was a CTRP meeting on Monday.
- A request from that team is to get back limited data from the lexevs- service (instead of the entire entity). Just FULLSYN data as an example.
|
DEV Blade - Update to 6.5.0 RC 1
- Testing update
- Moving up the tiers
- URI Resolver (Java 1.8)
| Discussion Points: - Jacob to install URI Resolver and CTS2 in separate containers.
- Kim's browser testing looks good.
- Tracy/Rob to load the latest source and then test today.
- Kim/Jason will test with the latest source when Tracy has completed the load.
Decision Points: - If everything goes well, we should be able to create a FINAL version next week.
|
Value Set Architecture Discussion - Use case for OWL expressivity
| Discussion Points: - LexEVS 6.5.1 Value Set Architecture
- We had a meeting last week and another one is scheduled for this afternoon.
- Scott asked - What is the use case that would require us to use the triple store or OWL2 API? Do we need an OWL representation?
- Larry suggested it could be used for concept models, role groups, and traversal. For value sets - it was for more rich information (hierarchical)
- Are there aspects of the OWL class that can't be stored in OWL?
- Restrictions, Anonymous nodes are not well defined in LexEVS API.
- LexEVS API performance may be an issue and a reason to move to OWL.
- Larry offered a use case: Structured organization of the role relationships in the browser. They could only separate out roles that were directly attached.
- This is associated to reasoning and OWL.
- This is a general coding scheme issue (not necessarily associated to value sets).
- Gilberto - We only need OWL it if we show the OWL semantics.
- Relationships without the anonymous nodes is faster.
- In the value sets, we don't need the expressivity.
- There may be a performance penalty to navigate from a concept in a value set to another entity.
Decision Points:
|
Docker - Next Steps Discussion - Update from recent meeting
| Discussion Points: - The server is configured with Jenkins and Docker.
- There are a few adjustments that are still needed.
- Next Steps - Meet with the the systems group and work on reusable containers that have approved NCI tech stack software.
Decision Points: |
| Triple Store Hierarchy Discussion | Discussion Points: - This has already been discussed above to some extent.
- We will need to work through more of this during our VS architecture discussion.
Decision Points: |
| lexgrid.org Migration | Discussion Points: Decision Points: - Scott will coordinate with the NCI team when we plan to change the DNS settings for lexgrid.org.
|
Access to NCI Wiki Pages - External user access
- Development Documents access
| Discussion Points: - Craig was wondering if LexES Project Documents folder and sub folders should be visible to all.
- Larry suggested these folders should be public unless there is private information.
Decision Points: - Larry requested that we check the contract to verify what is mentioned. Does it specify that certain pages should be public?
- Kumar will investigate what the contract contains.
- It was decided to leave it open to the public for now.
|
Deployable LexEVS Containers - NCI Containers for deployment
| Discussion Points: - This was discussed above.
Decision Points: |
LexEVS External Users - Interest in LexEVS Docker containers for deploymentF
- caDSR content admin
- Run queries against LexEVS and using Python (not using LexEVS Admin)
| Discussion Points: - Scott has sent the user in caDSR some sample code and tips on how to directly access the LexEVS DB.
- The user is working on the UMLS. The user wants the mappings.
- The user wants to retrieve the semantic types for certain terms and also get the mappings.
Decision Points: - Scott to send the code examples to Tracy and she will add the code to the LexEVS coding examples on the wiki.
|
| Team Absences | Mayo Team NCI |
