W3C home > Mailing lists > Public > www-rdf-rules@w3.org > September 2002

RE: Query use cases

From: Seaborne, Andy <Andy_Seaborne@hplb.hpl.hp.com>
Date: Fri, 20 Sep 2002 09:37:59 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04EBDA3B@0-mail-1.hpl.hp.com>
To: "'Graham Klyne'" <GK@NineByNine.org>
Cc: "'RDF Rules'" <www-rdf-rules@w3.org>


To me the application wrapper does know the details of containers - it is
the mapping between the data as is actually there and how the main
functionality of the application would like to see the data.  It's a
presentation of the RDF data - query seems to have two functions locating
information and extracting/presenting/formatting it to the application.

Your rules idea is good idea of how this can be captured beause a general
mechanism (inference rules) and some declarative choice (the rule set to
use) means that the application writer isn't burdened.  Some rule sets wil
be used by many applications to the point where the application writer
probably thinks of them as standard.

One thing though - the application may not want to see the original triples.
In creating a more convenient view for the application:

(?l rdf:_<n> ?m) => 
    show[(?l query:member ?m)],
    hide[match triple(s)] .

but update can become interesting.

The "hide match" is so that 

(?l rdfs:_N_superproprty ?m) =>
	show show[(?l query:member ?m)],
      hide ...


-----Original Message-----
From: Graham Klyne [mailto:GK@NineByNine.org] 
Sent: 18 September 2002 14:10
To: Seaborne, Andy
Cc: 'RDF Rules'
Subject: RE: Query use cases


I've been thinking some more about this.  I have sympathy with your view, 
and certainly agree that flattening should not be a "normal" mode of 
operation.  But I'm also having problems seeing how to make this part of an 
application wrapper without having the application code know all the 
details of the container structure.

I'm thinking in terms of something like a syntactic marker in the QBE 
template -- distinct from the actual data matched, in the same way that a 
variable name is a distinct element in a query -- that can effectively span 
the list structure.

I think a similar effect could be obtained in the proposed Jena2 framework 
by defining a new graph that is a closure of an input graph under some 
simple inference rules:

     ?l rdf:first    ?m
     ?l query:member ?m

     ?l rdf:rest     ?r
     ?r query:member ?m
     ?l query:member ?m

then query the derived graph for:

     ?l query:member ?m

To do something similar for the original RDF container forms would also 
require some special syntactic recognition of container membership 
properties for rdf:_1, rdf:_2, etc., to yield something like:

     ?l rdf:_<n> ?m
     ?l query:member ?m

(RDFcore has decided to define rdfs:member (or rdfs:contains, I can't 
definitively tell which) as a common superproperty for rdf:_n.)


At 05:08 PM 9/16/02 +0100, Seaborne, Andy wrote:

>Personally, I don't like the idea of flattening the list in the query
>results as the normal mode of operation - sometimes I do want the list as a
>list, they aren't just a way of encoding a bag for multiple properties,
>sometimes things like the order in the list matters or even the fact it is
>list at all.  I hoped the query system understood lists and treated them so
>as to return a thing explicitly marked as list, not a plain resource - that
>is just a convenience.
>My approach for your example would be to write an application wrapper
>the query results that did the flattening to make it look like multiple
>properties if the application so desired.  I see it as an application
>modelling decision.
> > Is that a request to submit an example?
>         Andy
>-----Original Message-----
>From: Graham Klyne [mailto:GK@NineByNine.org]
>Sent: 16 September 2002 16:35
>To: Seaborne, Andy
>Cc: Barnell, Alex; 'RDF Rules'
>Subject: RE: Query use cases
>At 12:57 PM 9/11/02 +0100, Seaborne, Andy wrote:
> >That's an interesting example (daml:collection) - presumably it suggests
> >query should return only the list head and start part way down (unlikely
> >query would do this match but possible).  I didn't notice anything DQL
> >this - maybe I missed it.
>My take was that the query would return the contents of the list, not the
>list itself; e.g.
>Thus a query against:
>     head first item1 ;
>          rest [ first item2 ;
>                 rest [ first item3 ;
>                        rest nil ] ] .
>might return matches against:
>     item1
>     item2
>     item3
> >The same is true of RDF alt/seq/bag - in many application situations it
> >would be nicest to mask the RDF encoding of the compound structure and
> >return a
>I thought that an implied rdf:member property might be used, so a QBE might
>      head rdf:member ?x .
>to return item1, item2, item3 in the above example, or in:
>      rdf:Seq rdf:_1 item1 .
>      rdf:Seq rdf:_2 item2 .
>      rdf:Seq rdf:_3 item3 .
> >Alex Barnell has been doing some work here on "RDFObjects" which provides
> >applications with a view of the RDF data as structured data items (e.g.
> >action items for working groups, vCards or iCal entries).
> >
> >Is this way of thinking about it - as higher level data abstractions -
> >is going on, do you think?
>Hmmm.... I'm not sure, but maybe yes.  In the sense that I want to treat a
>collection as an abstraction and query over it without being aware of its
>detailed encoding in RDF.
>By the way, the actual use case here is for document issue tracking, with
>issue history represented as a daml:collection style of list.  I want to
>form a simple query that will return successive elements of the list in the
>same way that I can currently query a repeated property value (but in the
>collection case, the order in which bindings are returned matches the
>collection order).
> >Would submit an example at
> >http://rdfstore.sourceforge.net/2002/06/24/rdf-query/, run by Alberto
> >Reggiori, which is a collection of query examples even if it's a use case
> >with no solution.
>Is that a request to submit an example?
>Graham Klyne

Graham Klyne
Received on Friday, 20 September 2002 04:39:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:13 UTC