## "Your" RDF Query Language

Kendall Clark of the Data Access Working Group (part of the W3C's Semantic Web initiative) has posted regarding their work on a query language and access protocol for RDF. The DAWG has recently released the 2nd draft of its Use Cases and Requirements and is looking for community input. Their initial query language design, BRQL, looks SQL-like but is designed to operate on graphs/sets of triples.

## Comment viewing options

### I like it

Let's connect this to the Python Paradox thread discussing language design. Here we have design by committee, of course, but the nice thing is that the committee creates use cases that can later be connected to specific language features.

This can make the design process more productive, since competing features can be judged by how each of them helps solve the different programming problems provided by the use cases.

### Some committee

There are only 2 editors of the draft. And one of them works for HP, and might therefore be biassed. BRQL indeed looks a lot like RDQL.

### I don't like it, at all

When people design query languages, they often seem to forget they are still designing a programming language.

They should look more at XQuery, which I like a lot more.

My biggest problem is the use of triples. I find that a very inconvenient way of describing graphs.

Things like
?x :f ?y . ?y :g ?z
is like you have to write
let y=f(x) in g(y)
g(f(x))

And SELECT returns tuples?? Sure, return your data in the one data format that RDF does not support... Compositionality thrown in the bin right there.

### They Say They Looked at RQL...

... but in my opinion they didn't look hard enough. RQL has a formal graph model, can query on both data and metadata in an RDF schema, and can even "interpret superimposed resource descriptions," that is, cope with resources that belong to more than one schema. There's also a somewhat extended RQL implementation in OpenRDF.

In looking at the various RDF query languages that are available, it really shocks me how many of them are so hidebound by trying to be like SQL, both syntactically and semantically. They just don't seem to understand the RDF syntax and semantics, and try to turn a graph model into a set-theoretic model. Bad idea.

### Compositionality in the bin

I guess they're looking to emulate SQL as closely as possible, then.

I'm wondering how much extra scaffolding would be needed to make it comfortable to use Plain Old Prolog for RDF queries. Are initiatives like this really inventing a Better Wheel?

### Prolog for RDF queries

I'm wondering how much extra scaffolding would be needed to make it comfortable to use Plain Old Prolog for RDF queries.

Interesting suggestion, nothing like that seems to have been considered.

### I thought you were joking

Amazing that neither "prolog" nor "logic programming" gets a mention anywhere in the document.

A quick google for RDF and Prolog turns up this, which looks quite promising:

http://www.xml.com/pub/a/2001/07/25/prologrdf.html

Oz and RDF sounds like a good match to me, considering the semantic web "vision" of multiple, distributed, asynchronously updating feeds.

### I was talking about the process not the language

From the little I understand of the issues involved, I agree with your opinion as regards the language. I agree 100% that they shouldn't forget that they are still designing a programming language.

### Designing to examples

Usually it's dangerous to design a language by making a few examples look good. In this case I agree it should have worked rather well. RDF has been used for a while so they know what the requirements are. And they made a good list. But it hard to choose when there are no convincing candidates.

### re Designing to examples

I agree. My first response was "this is not how it should be done..."

But when you think about it, there are worse ways. If you are going to do the design work by committee, it makes sense to at least agree on some specific goals.

Obvioulsy, "making a few examples look good" is not enough. Which is one reason why you should have more than a few examples, if you decide to follow this approach.

### Make the easy things look easy

It's important that the more rudimentary "use cases" can be dealt with in a simple and appealing manner - I think that's a consideration that ought never to slip from the designers' minds. So maybe it's not a bad thing to have a few straightforward examples up front. But I agree that it's hazardous to use them as the basis for thinking about the harder cases.

### Bijan Parsia

... considered it and did it.

### Yeah

I was trying to explain RDF and SW to a friend a while back, and ended up suggesting (with tongue slightly in cheek) that it was basically just "good old-fashioned AI".

I like Parsia's explanation of why nobody wants to own up to this (the "AI" label as kiss-of-death), but one could also entertain a gripe of Fabian Pascal's: the market isn't interested in decades-old ideas, and in fact relies on a sort of ever-self-renewing amnesia to keep the trade in novelty going.

Are there any RDF-querying applications for which logic programming a là prolog is really unsuitable?

### Response

See here for some reactions to the discussion above.