view
Date
Attendees
Goals
- Start on path to JSON interpreter
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| Mapping demo tomorrow |
| ||
| Review previous meeting | Scott reviewed Stardog vs other graph engines. Stardog not quite as fast as others. They do have a graph engine of their own. Scott says ArangoDB, Neo4J and OrientDB have all proven to be very fast. Some issues with loading relationships here is preserving the attached metadata. Issue is knowing what the predicate means, not just what the predicate is. Triplestores do maintain this information but are a little slower. If we get the graphing database working fast enough over it, then it solves a lot of problems. So - how do we measure the performance? What is the most difficult graphing task we have? Check concept "Human" | ||
JSON Interpreter | What is scope of this? Just QBE conversion? Working with caDSR? caDSR is in flux so their specific needs may change a lot, but the general need for JSON interpreter will not. So Mayo is OK developing a JSON interpreter to create LexEVS type objects against the EVSRestAPI. | ||
| EVSRestAPI | Status - CTRP version vs general. When on PROD? What should I tell people coming in now who want to use a REST api? Could they co-reside? The old api are all evsrestapi/ctrp/<query> where the new is all evsrestapi/<query> Can they be served by the same endpoint without conflict? |
Action items
- Safran, Tracy (NIH/NCI) [C] - Ping Terry and Al about mapping feedback
- Bauer, Scott (NIH/NCI) [C] - pseudocode some possible stress test queries
