Re: Use case: AR-2: "Federated query"

(with alberto technical mode on :)

On Mar 18, 2004, at 9:02 AM, Patrick Stickler wrote:

>> == Intent: Task & Roles
>>
>> Actor/User Agent needs to seamlessly query/access/integrate related 
>> chunks/pieces of data coming from a set of decentralized 
>> heterogeneous sources, and get presented an unified view over a the 
>> whole result-set/data-set.
>>
>
> While this is an important, and needed, application, this seems out of 
> scope
> to me.
>
> Some particular service could provide a DAWG conformant interface to a 
> virtual
> knowledge store which constitutes a federation of heterogenous 
> knowledge from
> a broad range of disparate repositories -- but a DAWG agent should not 
> be concerned
> with, or even be aware of, such federation.

good point - but this would only be yet another specialized system, 
where your "DAWG conformant service" would kind of centralize the query 
functionality again, and it would need to provide a sort of "brokering 
service" to a specific broad range of repositories. And this is not 
exactly how the Web works to me - but basically yet another centralized 
SQL/DBMS query system, where the client is requested to ask to a 
specific service specific questions, while not the other way around.

What about if in your case that "DAWG service" is down or not 
accessible? Is the query failing or the client has to piggy back to 
some alternative/spare service/solution?

Shouldn't the client instead be able to ask specific questions to 
specific distributed repositories directly?

i.e. what I have in mind is a kind of HTML for data

then you would need a DAWG aware client to interpret such a mark-up and 
doing the querying/aggregation job for you - ideally, like HTML pages 
(HTTP and the Web) allow today to seamlessly inline pictures in one 
unified view, there might be new Web browsers/clients/applications 
which might do the same for data.

For example, imagine an HTML TABLE aggregating pieces of information 
taken from a bunch of URIs - perhaps using some XPath/XPointer to the 
the end of them to pin-point to specific nodes/values :)

>
> Such a service would be very useful, and I expect it to be done often, 
> but it
> has IMO no affect on how queries are expressed and submitted to 
> services for
> resolution.
>
> The same goes for any form of distributed query.

Er. the same would apply to only a kind distributed query systems, 
which you can control/interface to the federation and wrap around a 
"centralized" DAWG service. What I meant is more general...

>
> (or have I missed something more fundamental, Alberto, in your test 
> case?)

my only concern in the AR-2 use-case was to start to consider the 
possibility that DAWG queries might effectively spawn over the Web - 
and then we might need some little syntactic sugar to express such a 
federation bits into the query.

(just to try to make you understanding what I meant)

E.g. in an hypothetical extended RDQL syntax (almost playing here in 
the example) i.e. "get me all items titles and they geo-position" - 
where RSS items and their locations are sitting in two separated 
sources

SELECT
	?item ?title ?lat ?long
FROM
	<file://my-rss-feeds.rdf>
	<jdbc:postgresql://www.foo.com:5555/lat-long>
WHERE
	( ?db1 dc:source <file://my-rss-feeds.rdf> ) // local RDF/XML source
	( ?item rdf:type rss:item ?db1 )
	( ?item dc:title ?title ?db1 )
	( ?db2 dc:source <jdbc:postgresql://www.foo.com:5555/lat-long> ) // 
remote SQL database
	( ?item geo:lat ?lat ?db2)
	( ?item geo:long ?long ?db2)


I hope it is clearer now...

cheers

Alberto

Received on Thursday, 18 March 2004 06:24:28 UTC