A discussion of the design and implementation of an RDF API.
Specifying queries: confirm*() API, path expressions, resource sets, templates versus predicate logic.
What do we want back? Tables, models, sets of models? They're all the same, from a point of view.
Just return, or rewrite?
Pulling other concepts from SQL: aggregation
The nature of constraints: value and structural
A proposal for a light-weight record retrieval mechanism is slowly taking shape.
In a nutshell: a query system may have a nuts-and-bolts implementation that relies only on the 'pure' API. Some RDFModels that use complex systems for their storage (OQL-based systems?) may enable a more efficient mechanism for solving queries. So it appears that a layered system should pass a query down the layers until something can answer the query efficiently.
The problem occurs when an additional semantic layer exists upon the top of a complex-query-capable layer. For instance, a layer implementing virtual triples that supplies the transitivity of "subclass" and/or implicit superpropery arcs may sit on top of an OQL store.
In this scenario, the top layer may not be able to do smart query processing; the OQL layer can perform such processing, but it doesn't know about the virtual triples that the top layer supplies.
The only method to support queries in this scenario appears to fall back to using the 'pure' API implementation; this seems extremely wasteful.
An alternative method might be for each semantics-adding layer to transform a query as it passes it to underlying layers, and to potentially transform the results as they are passed back up.
The problem with this proposed solution (apart, of course, from the devil that lurks in the details) is that it scales very badly when it comes to increasing the number of query mechanisms that are required to be supported (we need to potentially modify every semantics-adding layer) and when it comes to the generation of a new semantics-adding layer (we need to create the transformations for each query mechanism).
This problem may recede as a small number of query mechanisms come to the fore as the 'right' way to query RDF (the one true RDFQL, anyone?) but until that happy day, only implementation experience can indicate whether this is going to prove a killer.