W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2004

Re: named graphs

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Tue, 4 May 2004 09:54:39 +0300
Message-Id: <E9F79E50-9D97-11D8-BA6F-000A95EAFCEA@nokia.com>
Cc: <www-rdf-interest@w3.org>, "ext Chris Bizer" <chris@bizer.de>
To: "ext Phil Dawes" <pdawes@users.sourceforge.net>

On May 03, 2004, at 16:58, ext Phil Dawes wrote:

> Hi Patrick,
> Patrick Stickler writes:
>> RDFQ has been a useful "thought experiment" that I would like to have
>> seen reach a higher stage of maturity in the implementation, but 
>> further
>> development is at the moment, and probably for the summer, "on ice".
> That's a shame - for me it represents the most promising query
> language for cross-store querying. I suspect querying across multiple
> sources will start to become an important requirement for applications
> in the near future, especially if tools like Chris's D2R mapping
> software open up existing relational databases to RDF query languages.

Well, the spec for RDFQ is public, so anyone is free to implement it.
I've been implementing it by simply writing a front end to RDFQL, the
native query language in RDF Gateway.

I'll probably get back to this work, but it's been pushed pretty far
down my list of priorities at the moment.

> RDFQ is compelling for this sort of thing because of the following
> features:
> 1) supports adding RDF knowledge to be considered in addition to the
> contents of the knowledge base being queried.
>   - important when carrying out a query across multiple sources since
>   passing existing results between stores facilitates additional
>   results to be found.
> 2) supports multiple queries in one dispatch
>   - useful when trying to augument existing knowledge with extra
>   descriptive triples - e.g. labels, comments, types. Also I often
>   find myself needing to do a number of un-related queries to obtain
>   enough information to carry out an action.
> 3) supports named graphs
>   - important when results are syndicated from multiple sources.
> The only thing that puzzled me about the RDFQ spec[1] is the result
> format. It's currently constrained to being either a set of
> consise-bounded-descriptions or in the rdf format from the
> recording-query-results[2] document.
> For me, the most useful result format for server-side querying is a
> single rdf graph containing all the matched triples.
> This is because usually (in software I've written) query results are
> required to be used in tandem with other knowledge to carry out the
> required functionality. Getting the results as a graph enables the
> client to merge the information with its existing internal store.

I can see the utility in that.

I was deliberately taking a minimalist approach with RDFQ, trying
to force each feature to fight tooth-and-nail to be included.

I didn't need results of that form, so I didn't go out of my way to
try to speculate about all result formats that might be useful to

There's no rule saying one can't provide alternative result formats
in addition to what is specified. Go for it ;-)


> Cheers,
> Phil
> http://phildawes.net/
> [1] http://sw.nokia.com/rdfq/RDFQ.html
> [2] http://www.w3.org/2003/03/rdfqr-tests/recording-query-results.html


Patrick Stickler
Nokia, Finland
Received on Tuesday, 4 May 2004 02:54:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:51 UTC