Re: federation use case

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