Graph Use Cases
Storage Use Cases
When storing RDF information in a graph store, we would like to organize related information into separate graphs. Each graph must be identified with a URI to facilitate retrieval.
Another purpose in storing RDF content in different graphs is to enforce a permissions model so that sensitive information is not accessed by unauthorized users.
Query Use Cases
While query services are not explicitly addressed in the RDF spec, SPARQL does make use of graph IRIs and we should ensure that the semantics of graph identifiers are compatible with the way in which RDF datasets are defined by SPARQL.
Find Information In a Graph
When a query service processes a query containing a graph identifier, it must resolve the graph identifier to some collection of materialized RDF content that will be returned in the result set.
Often, graphs exposed by a query service are not present in any sort of physical storage, but rather their contents are computed at query time. Examples include:
- A federated query service may define a graph URI to be the union of graphs accessible through other query services.
- A service that does RDB to RDF mapping via R2RML may dynamically compute RDF results based on SQL results at query time.
Graph URIs as Locations
In the situation where a query service is presented with a graph identifier that is not present in local storage, the query service may wish to resolve the graph URI as a URL and make a request to that URL (possibly with conneg) for a document that serializes the content of that graph.