 |
Page History
...
| Discussion Points | Notes | ||
|---|---|---|---|
| Who are the stakeholders and end users of value sets | |||
| Define what work flow end user interface is (Shell script, Rest Service, Browser based GUI) | |||
Define performance or other considerations that require a move to triple store or OWL API (For Example: Do value sets need full OWL expressivity) In particular do we need reification for end users so that we can understand whether queries or API's need triple store or OWL API support. | 2017.04.24 VS Arch. Meeting - Gilberto and Larry would have to answer this question | ||
| Will non NCIt sourced value sets continue to use legacy value set definitions? (more a scope statement question) | |||
| What considerations/requirements drive the development of an architecture that encompasses hierarchical value sets and new resolution mechanisms? | |||
| Create OWL source for some/all values sets from LexEVS api or other source? (OWL export of value sets) | |||
| What user needs around the report writer generate requirements for LexEVS or the LexEVS team | |||
| Does Excel spread sheet generation fall into the scope of LexEVS value set resolution or otherwise generate requirements for the LexEVS team | |||
| Do the users/stakeholders in the value set API have any new requirements beyond those already stated | |||
| How to identify identical VS for different agencies. They need different URIs. | 2017.04.24 VS Arch. Meeting - There is information of the agency is in the annotation on that concept. This information can be used to create the unique URI that represents the agency. | ||
| What does it mean, in terms of requirements, to provide support for Neoplasm like value sets (Hierarchical) | Define use of Reification for end users so that we can understand whether queries or API's need triple store or OWL API support. (Gilberto and Larry would have to answer this question) |
