W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2004

Re: RDFQ - RDF Queries in RDF

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Mon, 5 Apr 2004 15:54:06 +0300
Message-Id: <5284648A-8700-11D8-9EE7-000A95EAFCEA@nokia.com>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: "ext Eric Prud'hommeaux" <eric@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:


    arbitrary graph
    variable predicates
    literal evaluation
    node selection by pattern
    negation as failure
    optional arcs (new)
    data source identification (new)
    relative temporal milestones

    ?? safe negation


    (and probably any other serialization of an RDF graph)

report style:

    aggregate graph
    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; ...]
    [a rdfq:Query; ...]
    [a rdfq:Query; ...]


    [a rdfq:Query;
     rdfq:target [...];
     rdfq:target [...];
     rdfq:target [...] ]

equates to

    [a rdfq:Query;
     rdfq:target [...];
     rdfq:target [...];
     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.


"Named Graphs, Provenance and Trust",
Jeremy J. Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler
(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 Stickler
Nokia, Finland
Received on Monday, 5 April 2004 08:54:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:26 UTC