Views in triple stores

Leigh Dodds wants views in triple stores:

Views are an important feature of relational databases, providing a way to abstract over complex queries, subset data to just the minium required for a given task, as well as providing a point around which a schema can be refactored without having to (immediately) change the applications that use it.

Leigh proposes two approaches:

The first is to apply a “window” on the graph, and only extract the data that’s within a certain distance of my origin.

This is implemented easily, but doesn’t work well. If you need a query depth of 3 or 4 (which is likely), you will pull in lots of stuff that you don’t need.

The second subset may be created by filtering out the classes and properties extracted from the database based on their namespaces. For example I might have a triple store containing a mixture of public/private data, with the latter in a separate namespace and I want to pull out just the public aspects for returning from a web service.

I think this is not such a good idea. Namespaces are just that, namespaces. Don’t overload them with access control. This scheme also doesn’t work if you want to filter by data (e.g. by publication date) instead of by schema.

I think that SPARQL’s proposed CONSTRUCT feature could do a nice job here. Basically, it’s like an RDQL query. But instead of returning a “result table”, the results will be stuffed into an additional set of graph patterns to form a new RDF graph. This constructed graph can have a structure very different from the original data, and can use different vocabulary. Very simple example:

CONSTRUCT   ( ?x foaf:name ?name )
WHERE       ( ?x vcard:FN ?name )

For the refactoring scenario, you would change the query pattern, but leave the construct pattern unchanged.

CONSTRUCT, SOURCE and optional patterns are the SPARQL features I’m looking forward to the most.