W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

Re: federation use case

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
Message-ID: <OF47D03FBD.17F36E03-ONC1256EE0.0059B87C-C1256EE0.0061C71A@agfa.com>

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 
>> Merging two documents can be done purely at the RDf level but often it 
>> 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 
>> Interestingly, that is how I do matching within a single query in 
>> Bindings are passed from one part, say, the WHERE clause, to an 
>> clause.  The bindings are substituted into a pattern before graph 
>> The only difference is that all queries (conjunctive graph matches) go 
>> 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:44 UTC