[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]RDF Query Language

From: Peter Minten
Subject: Re: [DotGNU]RDF Query Language
Date: Fri, 28 Mar 2003 08:47:39 +0100

Danny Ayers wrote:
> > SQL is easy to understand, GNU.RDF.QL attempts to be easy to
> > understand too.
> > Somebody who does not know GNU.RDF.QL but only RDF should be able
> > to get the
> > idea of a GNU.RDF.QL query straight away, don't think they will
> > be able to do
> > the same with RDQL.
> I can't see any difference in clarity myself, e.g.
> [RDQL] Query example 1: Retrieve the value of a known property of a known
> resource
> WHERE  (<http://somewhere/res1>, <http://somewhere/pred1>, ?x)
> etc.
> > Hmm, interop problems, not really. The GNU.RDF.QL is mainly used
> > to communicate
> > with GNU.RDF servers. It has the advantage of being quite close
> > to the actual
> > database layout. If I would ever need to communicate with other
> > kinds of servers
> > I would simply create a conversion agent.
> I don't know, of course it's entirely up to you. It just seems a little
> perverse to recreate something so close to existing work, but not directly
> interoperable with it. Wouldn't it be nice for GNU.RDF to be able to
> communicate with other servers in a transparent fashion - especially if it
> actually meant *less* work?

Well GNU.RDF is not about portability. It's about creating a coherent system for
the semantic web. The system will be compatible with W3C standards but not
always with exising implementations of the standards. The rationale is that
existing initiatives are quite scattered and most of them don't tackle the whole
picture, trying to be as compatible as possible will probably result in a design
nightmare. The system is open enough though for compatibility agents.

Besides I'm thinking of integrating link paths into the GNU.RDF.QL syntax, that
would certainly make a difference. Instead of writing 'SELECT foo FROM bar;' you
could write ';'. A good parser would make it possible to write '(SELECT
... /* a query that returns one resource */).propname;'. I would even consider
it possible to use the same syntax for queries that return more than one



reply via email to

[Prev in Thread] Current Thread [Next in Thread]