...

1. Current Freemarker UI will stay in-place for the scope of this plan (although deprecated)
2. UI must provide read access to VIVO data
3. UI must minimally be informed by the Production Evolution effort
4. UI must be based on data coming from a JSON endpoint
5. UI should render data served by a GraphQL server
6. GraphQL server should be configured with the same models used by ingest tooling (note: DocumentModifier.java may be updated to populate search index with these models)
7. UI must support accessibility
8. UI must support internationalization (i18n)
9. UI should avoid querying the triplestore when rendering

Decoupling VIVO

Requirements

...

By decoupling VIVO, we envision a collection of independent services that interact with one another over HTTP. Each of these components provide services based on well-documented contracts/APIs to further enable the replacement of one implementation of a component with another technology. Where possible, the component contracts/APIs should be aligned with native cloud services (i.e. AWS, Azure). Finally, to ensure consistent deployment environments and to facilitate transitioning from local to cloud deployment, each of the components below should be bundled as Docker images.

Triplestore

1. Initial service abstraction is represented in the RDFService.java interface
2. Implementations to support: Fuseki, BlazeGraph, Neptune
3. Respond to SPARQL-Query
4. Ingest set of triples
5. Generate resource URIs
6. Produce list of named graphs
7. Produce serialization of single graph
8. Produce serialization of entire graph store
9. Determine if internal graph is different from a serialized graph

Search Index

1. Initial service abstractions are represented in the following interfaces: SearchIndexer.java and SearchEngine.java
2. Implementations to support: Solr, Elasticsearch
3. Note: The search index machinery could potentially be used to transform data for import to and use in other derivative stores

Reasoners (TBox / ABox)

1. Enable configuration to set reasoning to on-demand or to on-change (Brian L has example code)

Triple Pattern Fragments

1. Either move current implementation into its own component, or use one of the other community implementations

Architectural concerns and questions

1. From an architectural perspective, having a triplestore at the core of the application brings significant limitations
2. As we decouple components, we must ensure that we also decouple logic expectations between the components
3. Is the VIVO ontology undergoing a significant revision? If so, what is the nature of the impact we should expect on the VIVO application?

...and more