Versions Compared

Old Version 5

changes.mady.by.user Andrew Woods

Saved on

compared with

New Version Current

changes.mady.by.user Jim Blake

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Scalable ingest
  2. No focus on refactoring VIVO
  3. How are loaders triggered?
  4. How are updates managed, from the UI?
  5. jb - Why keep "VIVO Triple Application" with its triple-store and inferencing? To provide a SPARQL endpoint? To provide an editing environment? 

VIVO Product Evolution Straw

  1. Similar to above
  2. No focus on refactoring VIVO
  3. jb – At first glance, it appears to be straightforward to implement GraphQL as a layer over SPARQL. This might indeed insulate developers from SPARQL complexity, but it is unlikely to improve performance.

Screen Shot 2018-12-20

  1. Focus on VIVO refactoring
  2. How is performance and scale addressed?
  3. Is the frontend decoupled from the APIs?
    • Server-side or client-side frontends?
  4. jb – Would the internal front-ends access the JSON APIs, or the existing controllers?
  5. jb – For the internal front-ends, Would there be any attempt to separate display from editing? Currently they are very much intertwined.

Future VIVO Example

  1. Focus on VIVO refactoring
  2. Maybe config does not need to be in a triplestore
  3. jb – Is the "New REST API" read/write or read-only?
  4. jb – Are the Legacy Freemarker pages just for admin functions, or are they also for searching, profile display, and profile editing?
  5. jb – Why the second search index? Is it more efficient, more flexible to populate two indexes?

VIVO 2.0 Arch

  1. Focus on VIVO refactoring
  2. Similar to above
  3. jb – This appears to be a draft of "Future VIVO Example"

arhitectura-vivo

  1. Addresses updates from UI and other sources
  2. Can service layer become the core VIVO app w/ content sources externalized?
  3. jb – What about policy filtering? (i.e., data is restricted from display and/or editing based on user accounts.) Currently, language filtering is applied at the SPARQL query level, but policy filtering is implemented higher in the stack. Where would policy filtering be implemented in this architecture? Or would it be dispensed with?

VIVO arch brainstorming

  1. jb – What is the benefit of JSON-LD? Isn't it just another RDF notation?
  2. jb – This might avoid one of the pitfalls of a graph model: the graph is one continuous structure, with no boundaries (ref: the deletion problem).

VIVO arch brainstorming-2

  1. No focus on refactoring VIVO
  2. Similar to Duke?
  3. Loader model
  4. What is the interation between webapps and content stores? API?
  5. What does deployment look like?
  6. Where does the VIVO ontology come into the picture?
  7. jb – What is the virtue of having both a triple-store and an RDBMS? What are the costs?

VIVO_Architecture_ideas.png

  1. jb – In the short run, the Data Distribution API is a good way to rapidly develop a back-end for an Angular/React/etc front-end.

ACTIONS


Collection of existing architecture diagrams / resources

...