- From: Jos De_Roo <jos.deroo@agfa.com>
- Date: Thu, 29 Jul 2004 19:48:17 +0200
- To: eric@w3.org
- Cc: "Seaborne, Andy" <andy.seaborne@hp.com>, public-rdf-dawg@w3.org
EricP wrote: > On Thu, Jul 29, 2004 at 03:36:07PM +0100, Seaborne, Andy wrote: >> >> Eric wrote: >>> ===== A Practical Union Query ===== >>> >>> FOAF documents seldom have assertions of the form >>> A foaf:knows B. B foaf:depiction C. >>> so graph merging is required to answer queries like: >>> >>> ?who foaf:depiction ?pic1. >>> ?who foaf:knows ?whom. >>> ?whom foaf:depiction ?pic2. >>> >>> FOAF documents tend to be small so merging the graphs isn't too painful. >> >> Merging two documents can be done purely at the RDf level but often it is >> useful to "smush" the graphs together: in FOAF, that enables joining >> together the information about one person from separate files (separate >> bNodes). >> >> aggregation strategies <http://rdfweb.org/2001/01/design/smush.html> >> posted by DanC_tst at 2001-07-20 16:02 (+) >> in >> http://rdfig.xmlhack.com/2001/07/20/2001-07-20.html >> >>> ===== A Practical Federate Query ===== >>> >>> To date, my implementations are more simple than the efficient. The >>> first query returns a set of results and the second query is >>> iteratively performed for each of those results, ala: >> >> OK - I understand federation better - thanks for fleshing out the example. >> >> Interestingly, that is how I do matching within a single query in BRQL/Jena. >> Bindings are passed from one part, say, the WHERE clause, to an OPTIONAL >> clause. The bindings are substituted into a pattern before graph matching. >> The only difference is that all queries (conjunctive graph matches) go to >> the same source each time. > > I suspect that keeping a running table of bindings is a common way to > solve this problem. The Algae spec even mandated such an approach and > used that to define the opperations like conjunction, disjunction, > not, optional. It may be handy for BRQL to do the same, but I'd like > to hear from the backward chaining community on this. > > Jos, is it useful to define logical query operations in terms of the > affect on a "current" result set? Well, not fully clear what you mean, but we use queries like [] q:select {result}; q:where {currentresult1 . currentresult2}. where the '.' is conjunction and queries like [] q:select {result}; q:where {currentresult1}. [] q:select {result}; q:where {currentresult2}. which is like [] q:select {result}; q:where {currentresult1 OR currentresult2}. and for the "NOT" we have queries like [] q:select {}; q:where {currentresult}. > Is that easy to map into forward chaining terms? if you meant "backward chaining term", then above is easy :) i.e. for every [] q:select {result}; q:where {currentresult}. we assert a rule {currentresult} => {result}. and try to prove {result}. > I guess this is for the plain english part of the description as I bet > the algebra will be defined in terms sets. -- Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/
Received on Thursday, 29 July 2004 13:49:02 UTC