Summary

(Conceptual thing) Extract Transform and Load Metamodel

The first approach is to use the RDFIzer which is currently provided by Dspace

The transformation process we propose, which has been tested several times consists of:
- first, translating the DSpace source data into an RDF graph representation. This task to be performed by the DSpace RDFizer
- Second, translate into VIVO perspective the DSpace source data within an RDF format using a SPARQL construct query
The SPARQL query uses the following files as input :
- DSpace source data in RDF format
- the files representing the DSpace data semantics which are in RDF
- the VIVO ontology used to contextualize the data sources in the VIVO perspective

This approach consists in producing a VIVO representation of DSpace data from a source data extraction mechanism directly from the Postgres database used by DSpace.
The block 1 presents the semantization process of the Dspace data structure. The process consists in extracting the database schema and storing it in an XML or CSV file. The translation of this XML file into RDF is produced by the XML2JSON and JSON2RDF utilities. The result of this process is an RDF ontology representing the structure of the source database tables. This process does not involve any particular risk since we have implemented this type of processing in many of our projects.
Block 2 which has been processed similarly to block one is mainly oriented to extract the data contained in the database. The result is therefore a graph of data in RDF format that are structured in the Dspace perspective.
Finally, block 3 consists in performing a mapping between the semantized data from the Dspace perspective to a semantized data from the VIVO perspective. As for the previous approach, this mapping is performed by a SPARQL construct query.
The process of the third approach is similar to the second approach except that the data source comes from the Dspace REST-API instead of from the Postgres database.

Facade is a structural design pattern that provides an interface for easy access to a library, framework or any complex set of classes.
RDFizer is an on-demand translator of DSpace data into a set of RDF triples that are stored in a triplestore accessible through a SPARQL endpoint.
The DSpace/VIVO facade is accessible to a web client and provides a single-entry point that unifies communications between the various components of the ecosystem
The SPARQL federated search allows to unify the result of a search even though it is distributed over the two data sources Fuseki and VIVO
The data synchronization periodicity is delegated to an external service of the facade which is in fact a kind of Web client

Extend the storage layer by adding an RDF triplet database (TDB) whose contents are synchronized in real time with the system's metadatabase
Add a SPARQL query editor and SPARQL endpoint Api to the application layer
Data synchronization between VIVO and DSpace is ensured by the facade through the SPARQL protocol
The DSpace semantic instance can thus become a LOD node

The main objective of the Message Design Pattern is to decouple the software from its external interfaces.
This pattern allows iterative interface development while maintaining backward compatibility.
The message is an exchange of information between a sender and one or many receivers. The message management is provided by the messaging system
In the message flow example, DSpace is the sender of the message and the receivers are VIVO and the other sources that are connected to the Messaging system.
Data from different sources are synchronized in real time
The DSpace/VIVO facade allows federated search execution using SPARQL query
Data can also be accessed by a client directly from the messaging system
The current VIVO-DataConnect project uses this pattern. It is specially designed to standardize the integration of external data sources such as Orchid