Set Up a Graph Service

We’ll set up an RDF graph service to abstract over any RDF graph database that we want to query. The graph service will provide us with a common API for graph management and for sending queries to the graph database.

Public databases

While we will make use of a local RDF graph database for testing, there are also many public RDF graph databases that are available for querying. We’ll try some of these out too. We can query these RDF graph databases through their public SPARQL endpoints.

HTTP protocol

The SPARQL standard also defines a graph store HTTP protocol for graph admin. Our local RDF graph database supports this. We could use this API directly, but for uniformity, we’d rather bring this under our common graph services API so that we can operate at a higher level of abstraction, which will make for less context switching when swapping between graph services.

Tracking the current graph store

There are many RDF graph stores we’d like to query, so we’d like a simple means of changing between them. We need to keep track of their query endpoints as well as any graph store API endpoints. We also need to track the graph store we’re currently working with.

We can use the application environment to store this information. Let’s define an admin property for the graph store API endpoint and a query property for the query endpoint. And let’s record this property pair for each store we are interested in. We can use a graph_store map for this and save each graph store with its own key and the endpoints as a value map: