Along a similar vein, did the
survey [[1]] cover any "query languages" that
were achieved through tunneling a restricted set of
Prolog?

The Internet Business Logic system answers all 14 questions in [1].

The set of logic programs that it handles is neither a superset nor a
subset of what Prolog can do. Roughly, it's datalog with stratified
negation, safe recursion, plus some arithmetic, string manipulation, and
aggregations. It compiles automatically into SQL when necessary.

You can run the 14 questions, and browse the rules that support them, by
pointing a browser to
www.reengineeringllc.com
. Click on Internet Business Logic, then on the GO button. Select RDFQueryLangComparison1 , then -- at the top of the page -- "Go to View or Change the Agent".

The Help buttons show how to run the questions, and how to get explanations of the answers. There are also tutorials for a gentle introduction.

Another query language possibly worth adding to the comparison is that
of the Wilbur Semantic Web Toolkit (dubbed "WQL"). I have written an
analysis of WQL's capabilities vis-a-vis the recently published
comparison and its 14 "tests". The draft is available here:

In summary, I consider two separate languages: "Plain" WQL, using only
the Wilbur query API, and WQL+CL, where "Plain" WQL query results are
manipulated using simple Common Lisp scripting. WQL was designed to be
integrated to Common Lisp as an access mechanism. This, and the fact
that Common Lisp, through the function EVAL, allows the dynamic runtime
execution of arbitrary expressions, justifies the consideration of
WQL+CL as a "query language".

"Plain" WQL is capable of satisfying a subset of the tests, but WQL+CL
can successfully evaluate *all* tests (albeit some queries are a bit
cumbersome :-). Details are included in the above paper.

Andreas,
interesting work; to this regard, you might also want not to skip W3C's
Metalog (cf. http://www.w3.org/RDF/Metalog ).

On the criteria in [2], obviously one might add many different
others as well. Given DAWG's scope, DB-like ops like joins etc might
profitably be included in the list. It would be also nice to express
those use cases in terms of abstract properties, rather than single
use cases: this will help better shaping the requirements document,
keeping a high level of abstraction and generality.