Spring based Configuration

rdf2pg tools are based on Spring beans components, which makes it possible to configure the tools for your use cases by means of Spring bean configuration files.

Typical aspects that you can define in a configuration include: .sparql files defining the RDF-to-PG mappings for your data and target database access details (URL, credentials).

Details are given in the documentation pages about the respective rdf2pg tools. Here, we'll make some general considerations about these files.

Note to developers: because we're using Spring, if you're going to use our [core library][15] programmatically, you can additionally/optionally use other Spring configuration means, such as Java annotations.

This is an example for the rdf2neo tool, which refers to the SPARQL queries located in the core package, in which you can see the elements:

• instances of the ConfigItem class. rdf2pg can split the conversion process into multiple independent configurations, each dealing with particular RDF subsets, with its own mapping SPARQL queries. Typically, this is used to arrange things on a per-type mapping. In the mentioned example, those are Place and People. A variant of this might be a config item managing an entire subtree of classes (eg, People, Employee, Manager, etc).
• each config item lists the SPARQL definition files for querying the types described in the mapping section, that is: nodeIrisSparql, labelsSparql, etc. rdf2pg relies on these names to know which SPARQL file is for what.
• tools-specific beans, such neoDriver, which is used to tell where is the Neo4j database where to store the RDF-mapped data and how to access it. Again, neoDriver is a mandatory name, rdf2neo expects to find it as the place where Neo4j coordinates are given.

Spring modularity

Since the rdf2pg configuration files are spring bean files, you can benefit from their expressivity.

For instance, you can use the Spring import mechanism to split configurations into common SPARQL mapping imported by additional files that define specific details, such as Neo4j credentials.

Another approach to achieve similar modularity is to inject Java property files into Spring XML files.