This mail seems relevant. RDF triples is what I'd support
as a potential requirement. I'm already expecting to
implement this, for Sesame / SeRQL style approaches.
QL syntaxes is another and entirely different matter.
Dave
---------- Forwarded message ----------
Date: Thu, 1 Apr 2004 16:54:21 +0100
From: Phil Dawes <pdawes@users.sourceforge.net>
To: www-rdf-interest@w3.org
Subject: getting rdf query results as an rdf graph
Resent-Date: Thu, 1 Apr 2004 13:49:07 -0500 (EST)
Resent-From: www-rdf-interest@w3.org
Hi All,
I've been involved in developing 5 RDF applications to date, and in
each I've found that the same architectural pattern emerges each time:
- Application has an in-memory rdf store(s), which it manages and
accesses via simple fine-grained API. (sortof the M in MVC)
- A number of larger RDF sources/stores exist, which contain
information useful to the application.
- Application performs remote queries on the larger RDF sources, and
inserts/merges the results into its local rdf store(s).
- Application uses simpler fine-grained api to walk the internal
store(s) whilst performing application logic (rendering UI etc..)
This is the case even for web-applications with a stateless middle
tier (i.e. an internal rdf model is built up on each request).
The reason that I'm writing is that in order to facilitate this style
of architecture, ideally the larger rdf stores need to support
returning query results as an rdf graph (sometimes a specially
constructed rdf graph).
As far as I can see, only Sesame directly supports this (via its seRQL
construct query), which confuses me.
Is this an uncommon approach?
Are there disadvantages to this approach compared to using a query
result format that binds variables to result values (e.g. rdql)?
Many thanks,
Phil