RE: getting rdf query results as an rdf graph

A - Returning Graphs

I do it in jena all the time:

	public String execQuery(String query)
		throws GnowsisException {
		QueryResults qres =
RequestHandler.getHandler().execQuery(query);
		Model target = ModelFactory.createDefaultModel();

		// do extraction of bindings
		while (qres.hasNext()) {
			ResultBinding b = (ResultBinding) qres.next();
			b.mergeTriples(target);
		}

		// print target to string
		StringWriter s = new StringWriter();
		target.write(s, "RDF/XML-ABBREV");
		return s.toString();
	}

B - Tier Architecture
I may add my two bits here as I have written a server that integrates
Outlook data as RDF and filesystem metadata as RDF.
You are right in all your points.

The thing we all need are PROTOCOLS.
and URI BASED ROUTING (or similiar)

you said "a number of large RDF sources" exist. Yup, now write a
router/hub that integrates them and you have much headache.
and yes, I forgot: It should do OWL-DL also, haha.

ok, what I did was to use RDF/XML-ABBREV graphs as variables to
communicate. that is fine but crap for high performance. We need
something as fast as SQL.

 
> 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)?

to my knowledge, RDQL is stone age. When I tried out sesame a year ago,
you could do a "SELECT * WHERE (x .. y... z)...." query and the return
variables where not named and not ordered, so you could not know in
which column which result was. the standard defined a query with a
useless result.

second thing is "left outer join", so optional joins. It is a basic of
RDQL that a big query fails when one triple misses, this is also bad.
Something better will come, or perhaps I am not on the latest and
optional joins are already implemented in sesame.

Nethertheless, a good publication architecture is needed. In january I
published gnowsis at http://www.gnowsis.com/wiki/GnowSis/LeoSThesis
which contains some stuff about "middleware for the semantic web
desktop".

I appreciate any well-engineered approach in this direction, it is
needed to explore these things. 

thanks for this post, a good thread.

Leo

Received on Thursday, 1 April 2004 18:20:24 UTC