chenejac
commented
6 years ago Jim Blake said:
Some of this work is well under way. Some has not been attempted.
When VIVO starts up, it reads the applicationSetup.n3 file from the home directory, and instantiates modules based on the contents of that file. In general, VIVO has only one implementation of each type of module. The exception is the main triple store, which can be configured to use SDB, TDB, Virtuoso, or a generic SPARQL endpoint. These modules have all been implemented, and can be selected by following the instructions in the configuration file.
(How well these modules have been tested is a separate question.)
(There is talk of a second implementation for the SearchEngine module, which would support Elasticsearch.) h3. Regarding the components listed as candidates for decoupling:
The indexer is already defined by two interfaces, SearchEngine, which controls how to read and write to the search engine, and SearchIndexer, which determines the contents of the index.
There are two reasoners in VIVO, one for the ABox and one for the TBox. The TBox reasoner is already defined by TBoxReasonerModule. The ABox reasoner is not defined by an interface.
There are two triple stores in VIVO, one for content and one for configuration. These are already defined by the ContentTripleSource and ConfigurationTripleSource interfaces.
To my knowledge, no one has tried to define the presentation layer by an interface. h3. Other components
Other components that are already defined:
FileStorage – determines how uploaded files are stored, such as faculty photograph images.
ImageProcessor – determines how images are manipulated to produce thumbnails.
h3. Documentation
I don't know of any wiki pages that document this.
The configuration file example.applicationSetup.n3 contains some comments.
The components are loaded by a class called ConfigurationBeanLoader, with a README.md file here. The README file also contains a brief mention of the Application setup process.
Mike Conlon (Migrated from VIVO-1542) said:
Providing clean, well-defined interfaces between components of a system is a best practice simplifying the adoption of new versions of components and of entirely new components, and/or the replacement of components by sites as/if needed. Components for decoupling include: the presentation layer, the triple store, the indexer, and the reasoner.