Replace vendor-specific triple store config by generic config for SPARQL-endpoint and RDF4J-server

[dennisvang]

Currently the FDP supports different types of external triple store, viz., Allegrograph, Blazegraph, and GraphDb. The FDP configuration for these triple stores looks like it is implementation-dependent:

FAIRDataPoint/src/main/resources/application.yml

Lines 57 to 74 in 0803e8a

	# valid repository type options {1 = inMemoryStore, 2 = NativeStore, 3 = AllegroGraph, 4 = graphDB, 5 = blazegraph}
	repository:
	main:
	type: ${FDP_TRIPLE_STORE_TYPE:1}
	native:
	dir: ${FDP_TRIPLE_STORE_DIR:/tmp/fdp-store/}
	agraph:
	url: ${FDP_TRIPLE_STORE_URL:http://localhost:10035/repositories/fdp}
	username: ${FDP_TRIPLE_STORE_USERNAME:user}
	password: ${FDP_TRIPLE_STORE_PASSWORD:password}
	graphDb:
	url: ${FDP_TRIPLE_STORE_URL:http://localhost:7200}
	repository: ${FDP_TRIPLE_STORE_REPOSITORY:test}
	username: ${FDP_TRIPLE_STORE_USERNAME:user}
	password: ${FDP_TRIPLE_STORE_PASSWORD:password}
	blazegraph:
	url: ${FDP_TRIPLE_STORE_URL:http://localhost:8888/blazegraph}
	repository: ${FDP_TRIPLE_STORE_REPOSITORY:test}

However, this is misleading and unnecessarily restrictive, because it appears to preclude the use of other triple stores such as Jena (TDB/Fuseki), see e.g. #808. In addition, it increases the maintenance burden.

In fact, the only requirement is that the configuration points to either a SPARQL-endpoint or an RDF4J-server (extended SPARQL-endpoint).

The underlying RDF4J Repository classes used by the FDP are just the default SPARQLRepository, for Allegrograph and Blazegraph, and HTTPRepository, for GraphDB:

FAIRDataPoint/src/main/java/org/fairdatapoint/config/RepositoryConfig.java

Line 108 in 0803e8a

new SPARQLRepository(properties.getAgraph().getUrl());

FAIRDataPoint/src/main/java/org/fairdatapoint/config/RepositoryConfig.java

Line 138 in 0803e8a

return new SPARQLRepository(urlBuilder.toString());

FAIRDataPoint/src/main/java/org/fairdatapoint/config/RepositoryConfig.java

Lines 164 to 166 in 0803e8a

	return repositoryManager.getRepository(
	properties.getGraphDb().getRepository()
	);

From the rdf4j sparql docs:

A SPARQL endpoint is any web service that implements the SPARQL 1.1 Protocol [...]

Since every RDF4J repository running on a RDf4J Server is also a SPARQL endpoint, it is possible to use the SPARQLRepository to access such a repository. However, it is recommended to instead use HTTPRepository, which has a number of RDF4J-specific optimizations that make client-server communication more scalable, and transaction-safe.

So, I propose to do the following:

• Remove the implementation-based configurations, i.e. Allegrograph, Blazegraph, and GraphDb
  (Note that Blazegraph should be removed anyway, see Discontinue Blazegraph support? FAIRDataPoint-Docs#95.)
• Add interface-based configurations, viz. for SPARQLRepository (sparql-endpoints, supporting the SPARQL 1.1 Protocol) and HTTPRepository (server-side-rdf4j-repositories supporting the RDF4J REST API on top of the SPARQL 1.1 Protocol, like GraphDB)
• In the documentation we could still use Allegrograph and GraphDB as examples for the configuration, and we could provide examples for more types of triple store.