- From: Alberto Reggiori <alberto@asemantics.com>
- Date: Thu, 18 Mar 2004 12:24:23 +0100
- To: Patrick Stickler <patrick.stickler@nokia.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
(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