Home

XsRQL (and other RQLs)

The RDF Data Access Working Group is busy doing a survey of query languages and access techniques that have been used with RDF. Many resemble SQL in syntax, despite operating on a graph. Amongst the WG's Design Evaluations Links there's a recent submission of a different style from Howard Katz : XQuery-style RDF Query Language (XsRQL), which actually looks very procedural (like XQuery).

By Danny Ayers at 2004-07-02 13:24 | XML | other blogs | 7569 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Interesting stuff

Thanks, I find this really interesting, but it will take me some time to get up to speed (I am one of those who don't always remember why and how RDF is not the same as XML...)

It would be interesting to explore how these languages can help implement the social network DSL I talked about a couple of years ago in the dicussion group. Basically, the idea is to design a DSL that should be accessible to sociologists and allow them to analyze and gather statistical data on social network. Social networks are graphs, so RQLs should be appropriate as for the backend of what I have in mind. Right?

By Ehud Lamm at Fri, 2004-07-02 15:25 | login or register to post comments

"Many resemble SQL in syntax,

"Many resemble SQL in syntax, despite operating on a graph." Exactly. I'm no expert on SQL and relational databases, but I really don't understand at all why people are using SQL-lite things for querying RDF. Seriously, it makes no sense whatsoever. Can somebody explain to me why this is, perhaps somebody who knows more than I? If all you want to do is select statements from a collection, then it's too complicated; but they are simultaneously too simple to deal properly with an RDF graph. Does anybody think this is anything other than trying to fit RDF querying into an existing SQL framework in their mind?

For example, to look at iTQL, not because I dislike it in particular, but just at random. It looks like: "select from where order by limit offset ;" Some problems: (a) columns don't even make sense in an RDF graph, so we have to make up variable names for them, which are then used in the constraints. (b) Constraints can only be specified as a list of statements, not as a graph. (c) Why would you want to order the results? (d) Why are not results returned as a graph?

I'll have a look at XsRQL to see what it is like. RDFQ seemed interested, queries were specified in RDF and, I beleive, results returned in RDF. However, I don't know if implementations exist, and development seems to have stopped.

Erik Hetzner

By egh at Fri, 2004-07-02 18:23 | login or register to post comments

SQL-like query languages

(Disclosure: I am a senior engineer at Tucana Technologies, and a core developer of kowari/tks --- and hence iTql)

Fundamentally, what is a query but a request for information from a source matching certain constraints? iTql is sql-like because we chose to represent these three components in a syntax that would be familiar to our users. A basic iTql query looks like:

select <variable-list> from <named-graph-expr>> where <constraint-expr> ;

At the moment if you want to return a sub-graph your query becomes:

select $s $p $o from <ng-expr> where $s $p $o and (<constraint-expr>) ;
[we are currently considering possible syntactic sugar to make it easier to express this, but we haven't decided on an approach yet].

However sub-graph's clumbersome for application developers; they require far too much post-processing to allow them to be displayed/used effectively for a large class of query. Worse, they make order-by, offset, and limit awkward --- and yes, they are essential when working with real datasets.

I remember listening to Joe Armstrong giving his LL2 talk mentioning that when doing OOP you don't want the system to limit the number of objects you create; when doing COP you don't want to limit the number of processes you create; and I would like to think that if you are using a triple-store you wouldn't want to have to consider the number of triples you load.

We have already demonstrated 250-million triples in tks, and we have plans to reach somewhere between 1-10 billion. We believe that returning variable binding lists (they just look like columns :), with streaming, ordering, and limit/offset support is the most practical approach to returning results from such triple-stores (although as we use named-graphs, technically we provide quad-stores).

For anyone who's interested, the from-clause is a set expression of models(named-graphs); the where-clause is a predicate composed of primative graph constraints.

One problem we do have, is that we aren't properly eliminating duplicates in the presence of dont-cares (which can occur under disjunction); if anyone knows of any literature discussing this problem I would appreciate any references. The current algorithm I'm implementing is non-polynomial in the number of variables that can contain dont-cares; it feels like there's a better approach, but I currently can't find it.

By Andrae Muys at Sat, 2004-07-03 01:13 | login or register to post comments

Declarative Syntax?

Just wondering why you'd want to attack the problem from either a SQL or a procedural perspective? Why not something along a more declarative programming approach like Prolog? Prolog is a natural at Trees (though I'm not sure it is good at more generalized graphs).

By Chris Rathman at Fri, 2004-07-02 19:25 | login or register to post comments

XsRQL (and other RQLs)

I'm pretty busy trying to get an actual implementation up and running w/in the next couple of days, but I'm up for trying to answer questions if anybody has any.
Howard

By howardk at Tue, 2004-07-06 17:52 | login or register to post comments

procedural?

I don't see why you think XML Query is procedural.
C or Java programmers might not understand the example you give, because they don't realize the if/then/else construct can actually have a value.

What's your "perspective"?

By Sjoerd Visscher at Tue, 2004-07-06 18:42 | login or register to post comments

procedural/declarative

I'm not sure if the last comment ("procedural") is responding to me or to Danny's original comment. I actually like what Danny says: the language "looks" procedural.

I've long ago given up trying to peg languages as purely this-that-or-anything. XsRQL also looks somewhat declarative. And just for good measure, you can throw in the "functional" word as well. It's an interesting mix of all three. I'll let the language lawyers battle it out on which adjective is most appropriate here; my head starts to hurt when I getinto that type of discussion.

Howard

By howardk at Tue, 2004-07-06 21:26 | login or register to post comments

anything procedural?

I was referring to the section "Procedural feel" on your page. It's not about which adjective is most appropriate, but if XQuery has a procedural aspect at all. The example you give is completely functional, pure even.

To me, XQuery is even less procedural/imperative than LISP or Scheme, because there are no side effects.

Surely you (or Danny) are not suggesting that anything that contains the words return, if, then and else looks or feels procedural?

By Sjoerd Visscher at Tue, 2004-07-06 22:30 | login or register to post comments

a matter of one's experience

No, I'm not suggesting that. I have no idea what Danny suggests. I use the word "procedural" to indicate a resemblance to the other non-query, procedural languages I've worked in, including C, C++, Java, and the like. It wasn't a major transition for me to move from those language to XQuery. Lisp, XSLT, and Schema on the other hand, feel quite different.

By howardk at Wed, 2004-07-07 04:12 | login or register to post comments