Re: RDFQ - RDF Queries in RDF

On Mon, Apr 05, 2004 at 03:54:06PM +0300, Patrick Stickler wrote:
> 
> 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

Not sure about this. Comments in line below:

>    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 [...] ]
> }

If I interpret this correctly, this is more a packaging of multiple
queries into one protocol exchange. The useful difference being if one
must ask a combinatorial factor of all the disjunction optoins. For
reference, see FatAnnotationQuery (EP-4) [1] where the query asks for
two properties that may be dc1.0 or 1.1. This seems like it would
require four queries in RDFQ.

Another litmus for disjunction is (if your language supports safe
negation) whether you can limit the results to not include X or Y. If
you can't, you must limit it from including X and then do the work
locally to remove Y.

[1] http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar/0083.html

> --
> 
> 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

-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741 (does not work in Asia)

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Wednesday, 7 April 2004 05:31:00 UTC