- From: Rob Shearer <Rob.Shearer@networkinference.com>
- Date: Wed, 9 Jun 2004 11:59:10 -0700
- To: "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
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