- From: Graham Klyne <GK@NineByNine.org>
- Date: Fri, 20 Sep 2002 11:41:14 +0100
- 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 UTC