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.
Rowland,
SPARQL has some really nice features in it which look very useful. Andy Seaborne’s ARQ is steadily improving to a point where I think you can apply an XSLT style sheet to SELECT statements. It would probably be possible to add this to CONSTRUCT and DESCRIBE. It’d be interesting to see how these could be used in conjunction with XForms, since that Chiba implementatino uses XSLT style sheets.
SOURCE looks useful if a source exists. Being able to use SOURCE with Named Graphs would be an interesting way to get hold of warrants without having to make multiple queries.
I agree with your thoughts on not using namespaces as access control mechanisms. I think lots of strang side effects could occur.
Cheers,
Rowland
Now this would be cool. Modifying RDF data through XForms … sweet.
Pingback: Lost Boy