RE: RDF QLs within a larger language

-------- Original Message --------
> From: Eric Prud'hommeaux <>
> Date: 28 June 2004 08:10
> 
> Howard's XSRQL [1] and TimBL's N3QL [2] are good examples of RDF
> functions that fit into a larger QL. In the XSRQL case, it gives us
> an opportunity to lean on some already specified and implemented
> functionality in XQuery that is likely to get very wide
> deployment. I'm curious about how much re-use we get, Howard.
> 
> N3QL constrains itself to be a subset of the N3 syntax which can be
> used for query. This is especially usful if N3 is later adopted as a
> rules language because we would get to take advantage of the fact that
> query goals and rule goals are very similar, both in syntax and in
> semantics. Once we've defined a language that produces some sort of
> variable bindings, it's pretty easy to define how to use those
> bindings to construct new graphs.
> 
> Anybody interested in exploring this with me?

Yes - for two readings of "this"


Binding "this" to "N3QL" ...

The surface syntax of "DAWG-QL" for application writers and the network
syntax need not be the same, especially if there is a network syntax that
can reuse existing parsers.  I would prefer that the application writer can
write constraints as "?x < 27" rather than spell it out in RDF. 

I prefer the N3-full version, not the reification into RDF, but something is
needed to avoid the issues around interpretation of URIs for variables (e.g.
ask query a log file for requests/queries that use the variable "x").

Some points:

1/ The streamability requirement as the result is a graph.  While it is
possible to insist that the serialized graph come back in a useful order,
this does not feel like a useful way to go.  It is effectively a new
serialization that is compatible with the unrestricted one.

2/ Could add "describe", to get a more general fetch operation, not that the
returned graph is really limited to just what was asked for anyway.  But it
is more useful to explicit say "describe" rather than the rule like "cwm
--filter" style.

3/ The declarative nature of the RDF graph means (as is observed in the
document) that optionals is not well-defined.  I haven't found an
non-procedural (ordered) interpretation for multiple optionals that's better
than the rule that variables can only be bound in one clause or the
mandatory part.

4/ More an aside about the non-distinction of pattern and constraints.  In
Jena's conjunctive matching engine, for in-memory query, we don't separate
graph matching from constraints but instead we flow the constraints to the
earliest point in the matching where all the input variables are bound.
This is similar to having no distinction between the WHERE clause and the
AND clause. For a DB graph, we will let the DB optimizer decide.

--------

Binding "this" to a more general "embed DAWG-QL query inside A.N.Other QL",
especially Xquery/DAWG-QL.

One approach I have not seen is embedding an RDF query language as a whole
inside Xquery; rather that just Xquery FA's to access single triple
patterns, have Xquery to graph patterns (and constraints?) which is
effectively interfacing to the result set and sees doable if the result set
is in XML.

This would give the power to Xquery to produce XML, XHTML and other syntax
result forms yet does not make the DAWG issue an either/or.  It also allows
a separation with the Xquery-DAWG/QL interface being a remote access (c.f.
log:semantics).

	Andy

> 
> [1] http://www.fatdog.com/xsrql.html#Examples
> [2] http://www.w3.org/DesignIssues/N3QL
> --
> -eric
> 
> office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
>                         Shonan Fujisawa Campus, Keio University,
>                         5322 Endo, Fujisawa, Kanagawa 252-8520
>                         JAPAN
>         +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
> cell:   +1.857.222.5741 (does not work in Asia)
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.

Received on Monday, 28 June 2004 11:33:11 UTC