How to handle multiple graphs in Blazegraph?

Question

I'm using a public graph that I download and load on Blazegraph. I'm now familiar with SELECT and CONSTRUCT requests on this graph. I don't know if that matters, but the graph includes multiple prefixes:

@prefix schema: <http://schema.org/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix olo: <http://purl.org/ontology/olo/core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
....

I would now like to have another graph with internal data (e.g. user accounts) given that there will be links with the public graph (e.g. whether a user "liked" a node of the public graph);

I would like to keep these two graphs separate, for example to:

• replace the public graph with a new version when it's updated
• save a backup of my internal graph
• ...

How to do that ? Are there good practices ?

Answer 1

A couple solutions come to mind.

Solution 1: Named Graphs

It's possible to, in a single graph database, segment your data into subgraphs (formally known as named graphs). This allows you to logically separate your queries. For example,

INSERT DATA {
    GRAPH <http://example/my_public_graph> {
        subject pred obj .
    } 
}

The SPARQL spec has more information on querying from them.

Solution 2: Separate Blazegraph Instances With Federated Queries

Another solution is to have two Blazegraph instances running, each with different types of data. You can federate your queries from one to the other to perform a union of the data

Solution 3: Move off Blazegraph

Blazegraph is for all practical purposes, dead. More modern DBMS will allows you to run multiple graphs on the same instance. For example, GraphDB or Stardog.

Answer 2

Solution 4

Use blazegraph's multitenancy feature to host graphs in separate namespaces (but still in one server instance) and utilize federated queries to fetch data from those namespaces.

Basically, you need to create a bunch of namespaces, load data, and SPARQL-query out of it. The trick, however, lies in how you distribute your data across those namespaces to minimize data duplicity, namely metadata. One way to do it is to have a master namespace where you would store your metadata (e.g. ontology with all classes and relationships), and then a namespace for your users and other entity instances, but without the ontological part which is stored in the master namespace. You'll probably be able to configure each namespace separately.