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

RE: Query use cases

From: Graham Klyne <GK@NineByNine.org>
Date: Fri, 20 Sep 2002 11:41:14 +0100
Message-Id: <5.1.0.14.2.20020920112318.03c80960@127.0.0.1>
To: "Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com>
Cc: "'RDF Rules'" <www-rdf-rules@w3.org>

Andy,

I guess it depends on exactly on how you view "application wrapper" -- is 
it part of the application or part of the service the application uses.  I 
see the query engine here as an application service, which usefully hides 
some of the mundane structuring details.  I don't think that's at odds with 
what you're suggesting.  I have not so far had cause to consider updates.

FWIW, I've now done a toy implementation for both containers and lists, 
which uses special items in the query to denote container or list 
membership -- effectively a syntactic extension to the QBE form.

e.g.
    Container *member* ?Member
or
    List *element* ?Element

(I reserve a URI in my implementation, so it might be viewed as a packaged 
version of the inference approach noted below, assuming only "well-formed" 
lists)

Because my query engine works by returning variable bindings (not triples), 
I don't have to worry about the show/hide logic you describe, but OTOH I 
have no direct way to determine exactly what container membership property 
was associated with a given member.

Some other comments/observations:
- using a primitive interface to the triple store, it's not easy to get the 
members of an rdf:Seq container in order -- the best approaches I can think 
of require two passes;  e.g. one to find the highest membership property, 
and another to select the members in order, or alternatively to copy all 
the member-statements to a separate area and then sort them by membership 
property.
- I found the logic to extract container members was pretty ugly, requiring 
as it did an analysis of the URI form to determine whether membership was 
being indicated.  I suppose a cleaner way to deal with this might be to 
flag container membership properties at parse time, since they are 
something of a special case.
- by comparison, the logic to query over daml:collection style lists was 
very clean, and the ordering takes care of itself.

(I emphasize, these comments apply to a primitive statement-store interface 
-- I'm sure the issues could be overcome more cleanly by a more 
sophisticated interface/implementation.  But, for example, I didn't notice 
anything in the Jena Model interface that might have helped.)

#g
--

At 09:37 AM 9/20/02 +0100, Seaborne, Andy wrote:
>Graham,
>
>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 ...
>
>works.
>----
>         Andy
>
>-----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
>
>
>Andy,
>
>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.)
>
>#g
>--
>
>At 05:08 PM 9/16/02 +0100, Seaborne, Andy wrote:
>
> >Graham,
> >
> >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
>a
> >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
>around
> >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?
> >
> >Yes!
> >
> >         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
> >the
> > >query should return only the list head and start part way down (unlikely
> >the
> > >query would do this match but possible).  I didn't notice anything DQL
> >about
> > >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
> >
> >Quite!
> >
> >I thought that an implied rdf:member property might be used, so a QBE might
> >be:
> >
> >      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 -
>what
> > >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?
> >
> >#g
> >
> >
> >-------------------
> >Graham Klyne
> ><GK@NineByNine.org>
>
>-------------------
>Graham Klyne
><GK@NineByNine.org>

-------------------
Graham Klyne
<GK@NineByNine.org>
Received on Friday, 20 September 2002 07:19:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:53:09 GMT