RE: Query use cases

Graham,

Yes - I think we are in agreement:  something like:

    +--------------+
    | Application  |
    +--------------+
    | Presentation |
    +--------------+
    |  Core query  |
    +--------------+

where the core query views the data presentation as if it were another
software using the core system, and the application views the data
presentation as part of "the system" it is using.  I tend to think of the
presentation as a translation to/from what the application would like to see
of the RDF and the actual RDF.

As to getting the elements in a sequence in order, it is tricky.  It is very
difficult to cache the seq structure because the application has the right
to modify the sequence at the encoding level anytime it so chooses.  The
"get all members, then sort" approach you outline looks better than 2-pass
in that it works in the presence of updates because a single bulk fetch form
the store is done.

In Jena, you can call Model.getSeq().iterator() to work over the contents in
a sequence on order but the implementation is not pretty.

One thing - with the rules you gave, don't you create duplicate statements?
As a model is a set, don't you loose the multiple occurrences of the same
value?  Of course, as you do variable bindings, you are OK here but it isn't
pure RDF rules.

	Andy

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


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 Monday, 23 September 2002 05:03:17 UTC