REX evaluation

Just thought it was worth evaluating a form of the XQuery syntax we're
using at NI to query the knowledge encoded in OWL ontologies. I'll refer
to the RDF version of the syntax as "RDF Extensions to XQuery", or REX.

The language really does nothing but add a few new functions to XQuery:

individuals() returns a sequence of all the URIs used as either subjects
or objects in triples,
properties() returns a sequence of all the URIs used as predicates in
triples
dataValues() returns a sequence of all possible datavalues (for now,
assume they are just the values used as objects in triples)
related(x, y, R) is a boolean predicate representing the existence of
the triple 'x R y'

(This is actually a somewhat simplified version of the syntax, but it
will do for now.)

A query to find all working group members and their names would be:

for $i in individuals()
for $d in dataValues()
where related($i, #DAWG, #memberOf)
  and related($i, $d, #hasName)
return <Member><uri>{$i}</uri><name>{$d}</name></Member>


3.1: RDF Graph Pattern Matching
FULLY SUPPORTED
Each 'related' clause is nothing but a triple which might include
variables, and you can string them together with 'and', so I think a
'where' clause qualifies as a 'graph pattern'.

3.2: Variable Binding Results
FULLY SUPPORTED
The 'return' clause operates directly in terms of bindings.

3.3: Extensible Value Testing
FULLY SUPPORTED, with easy re-use of existing extensions
The standard XQuery mechanisms for additions of functions can be used to
define new predicates for data values. E.g.:
for $i in individuals()
for $d in dataValues()
where related($i, #DAWG, #memberOf)
  and related($i, $d, #hasName)
  and isCommonlyMisspelled($d)
return <Member><uri>{$i}</uri><name>{$d}</name></Member>

returns our good friend Kendall, based on a custom implementation
(whether user-defined or vendor-specific) of the isCommonlyMisspelled
function.

3.4: Subgraph Results
FULLY SUPPORTED
Results can easily be formattted as a subgraph of the original graph:
<rdf:RDF xmlns:rdf="..."> {
  for $i in individuals()
  for $d in dataValues()
  where related($i, #DAWG, #memberOf)
    and related($i, $d, #hasName)
    and isCommonlyMisspelled($d)
  return <rdf:Description rdf:id={$i}>
           <memberOf rdf:resource="#DAWG"/>
           <hasName>{$d}</hasName>
         </rdf:Description>
}</rdf:RDF>

3.5 Local Queries
FULLY SUPPORTED (not addressed)
The language does not address implementation or network access issues.

3.6 Optional Match
NOT CURRENTLY SUPPORTED
There are probably simple ways to extend the language to support this,
but we haven't looked into it yet.
How are the equivalent of outer joins performed in XQuery?

3.7 Limited Datatype Support
FULLY SUPPORTED
All the datatype predicates which are part of XQuery can be used if
desired. It just depends on what XQuery engine sits under the hood.

3.8 Bookmarkable Queries
FULLY SUPPORTED (not addressed)
Queries are expressed as text, so they can be encoded within a URI, thus
this language is compatible with whatever method an access protocol uses
for defining URLs.

3.9 Bandwidth-Efficient Protocol
WELL SUPPORTED
This feature remains quite difficult to test quantitatively, but the
sophisticated result-formatting system allows users to return only that
information which is actually relevent to their application. I.e. if the
user is interested only in the sequence of names and not the URIs of
group members:

for $i in individuals()
for $d in dataValues()
where related($i, #DAWG, #memberOf)
  and related($i, $d, #hasName)
  and isCommonlyMisspelled($d)
return $d

3.10 Result Limits
NOT CURRENTLY SUPPORTED
Again, this isn't something we've looked into. I'm not sure how this
issue is normally addressed within XQuery. It is worth noting, however,
that XQuery FLWOR statements do already provide robust support for
ordering, which can be an important building block in result-limit
functionality.

3.11 Iterative Queries
NOT CURRENTLY SUPPORTED
Not sure how this is normally handled in XQuery.

4.1 Human-Friendly Syntax
WELL SUPPORTED
The syntax is as readable and human-digestible as XQuery, which has
received generally positive user acceptance.

4.2 Provenance
UNKNOWN
I don't understand this objective well enough to evaluate it.

4.3 Non-Existent Triples
FULLY SUPPORTED
use of fn:not around predicates allows negation, which provides for
querying of non-existence of triples

4.4 User-Specifiable Serialization
FULLY SUPPORTED
One of the strengths of the language.

4.5 Aggregate Query
UNKNOWN
I don't understand this objective well enough to evaluate it.

4.6 Additional Semantic Information
WELL SUPPORTED
Extensions to such a language to support inferencing based on OWL,
rules, and other systems has been studies and implemented.

Received on Wednesday, 9 June 2004 15:00:58 UTC