- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Mon, 5 Apr 2004 15:54:06 +0300
- To: "ext Eric Prud'hommeaux" <eric@w3.org>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Apr 02, 2004, at 16:16, ext Eric Prud'hommeaux wrote: > > > On Thu, Apr 01, 2004 at 07:04:54PM +0300, Patrick Stickler wrote: >> >> Eric, >> >> Could you please include RDFQ [1] in your survey of query >> implementations. ... > done [2] -- please proofread. Thanks. I didn't see any mistakes, but there were some omissions and I've made the representation more specific to "any RDF graph serialization" pretty much. To summarize, RDFQ provides: expressivity: arbitrary graph variable predicates literal evaluation node selection by pattern disjunction negation as failure optional arcs (new) data source identification (new) relative temporal milestones ?? safe negation representation: RDF N-Triples N3 Turtle TriX (and probably any other serialization of an RDF graph) report style: aggregate graph bindings solution propositions -- The details of these follow... 1. Disjunction is supported. Multiple queries in the same input graph are evaluated as disjunct, and multiple target templates in the same query are evaluated as disjunct. Thus { [a rdfq:Query; ...] [a rdfq:Query; ...] [a rdfq:Query; ...] } equates to { [a rdfq:Query; ...] OR [a rdfq:Query; ...] OR [a rdfq:Query; ...] } and { [a rdfq:Query; rdfq:target [...]; rdfq:target [...]; rdfq:target [...] ] } equates to { [a rdfq:Query; rdfq:target [...]; OR rdfq:target [...]; OR rdfq:target [...] ] } -- 2. Node Selection by Pattern is supported. C.f. rdfq:re. Match subject node label: [:target [:resource [:re "...some_regular_expression..."]]]. Match predicate node label: [:target [:predicate [:re "...some_regular_expression..."]]]. Match object node label: [:target [:property [:re "...some_regular_expression..."]]]. -- 3. Negation as failure is supported. E.g. Find people who manage others but are not managed by anyone else: [:target [a ex:Person; ex:manages []; ex:managedBy :null]]. -- 4. Optional arcs can be supported by a subclass of rdfq:Value which is optional. I.e. rdfq:OptionalValue rdfs:subClassOf rdfq:Value . and thus a query such as the following [:select ( "email" "snailmail" ); :target [ex:emailAddress [:id "email"]; ex:snailMailAddress [a :OptionalValue; :id "snailmail"]]]. would require bindings for email values but would not require bindings for snailmail values. This is not presently defined for RDFQ, but I've now added it. -- 5. Not sure exactly how safe negation works. I have to look more closely at that. RDFQ may provide for it (or be easily extended to do so). -- 6. All three report styles are supported by RDFQ: If no rdfq:select property is specified for any query, the results are aggregate. If an input graph includes only one query, which has a single rdfq:select property defined, then the results are bindings (expressed though as RDF using the Result Set Vocabulary rather than an ascii formatted table). If either multiple queries are included in the input graph and/or multiple rdfq:select properties are defined, then the results comprise a set of solution propositions where multiple, distinct Result Sets are provided in the result graph. If multiple queries are specified in the input where one or more have no rdfq:select property and one or more do, then the results include both aggregate, binding, and (if more than one selection set, soluton propositions) in the same results. Thus, the nature of the results depends on the nature of the query input. -- 7. The representation for RDFQ is an RDF graph. How it's serialized is irrelevant to the evaluation of RDFQ queries. I promote the use of Turtle as a keyboard friendly encoding which is human-friendly, but whether one uses RDF/XML, N3, N-Triples, Turtle, TriX, or any other serialization of an RDF graph is not really significant, IMO. Still, if you're going to classify solutions in terms of the RDF serializations employed, you'd probably want to add Turtle to the list. -- 8. Data source identification is supported by RDFQ such that queries can be constrained to named graphs having specific characteristics. E.g. the following query asks for the title of all resources modified in the past day, but only if asserted in authenticated graphs published by John or Mary: [:select ( "title" ); :graph [swp:assertedBy [a swp:Warrant; swp:authority John]]; :graph [swp:assertedBy [a swp:Warrant; swp:authority Mary]]; :target [dc:title [:id "title"]; dct:modified [:le :one-day-ago]]]. Note the disjunction between the mulitply specified graphs. The graph specifications essentially equate to a pre-query, identifying all graphs which match one of the specified graph templates, against which all target templates are evaluated. C.f. "Named Graphs, Provenance and Trust", Jeremy J. Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler http://www.hpl.hp.com/techreports/2004/HPL-2004-57.html (coming soon...) -- 9. RDFQ provides support for relative temporal milestones, such as one-day-ago, one-year-ago, etc. I think this is a very important and practical feature of any query language dealing with resource descriptions, and you may wish to add this feature to your vocabulary. -- 10. I think the following example query more optimally expresses what you are aiming for: [ a rdfq:Query ; rdfq:select ( "port" "bindingName" ) ; rdfq:target [ rdf:type <http://schemas.xmlsoap.org/wsdl/service> ; wsdl:hasPort [ rdfq:id "port"; wsdl:binding [ wsdl:name [ rdfq:id "bindingName" ] ; wsdl:hasBinding [ wssoap:style <http://schemas.xmlsoap.org/wsdl/soap/document> ]]]]] . -- That's it. ;-) Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Monday, 5 April 2004 08:54:32 UTC