- From: Dan Brickley <danbri@w3.org>
- Date: Wed, 10 Nov 1999 15:15:27 -0500 (EST)
- To: Chris Waterson <waterson@netscape.com>
- cc: Dan Connolly <connolly@w3.org>, www-rdf-interest@w3.org
On Wed, 10 Nov 1999, Chris Waterson wrote: > Dan Brickley wrote: > > Syncing is much trickier; if you're looking at (and editing) the result of > > such a giant graph merge, it is not immediately clear what should happen > > with edits. I'm not sure how the Mozilla folks > > (http://www.mozilla.org/rdf/doc/) handle this: their API > > allows RDF graphs to be aggregated into a single virtual graph, and this > > graph (I believe) to have new facts added into it, edits etc. Quite how > > the aggregate routes assertions and edits to the datasources it aggregates > > over is an interesting question... > > It's a hack :-). And implementor feedback on (informal) requirements for RDF APIs... > . The composite datasource treats the datasources it aggregates as > totally ordered from "most local" (e.g., a store of "personal > overrides") to "most remote" (e.g., some immutable-to-me sitemap pulled > from the web). this seems reasonable, very nice in fact, in and of itself. The granularity of doing edits/additions per assertion (ie. per RDF statement) rather than per sub-graph seems wrong though: some datasource may accept some but not all properties used in a chunk of data you're asserting. So if you are pouring in 300 triples, this sounds like some might end up in the wrong place. > . Each datasource may either accept or reject an assertion. > > . The composite datasource tries to apply to assertion in each > datasource starting with the "most remote", working back to the "most > local". > > . The process stops as soon as a datasource accepts the assertion, in > which case the composite datasource has accepted the assertion. If no > datasource accepts the assertion, the compsite datasource rejects it. > > In practice, these semantics are too weak, and we usually just address > assertions directly to an individual "leaf" datasource. > chris > The datasources aren't given much to go on regarding the nature of the transaction though -- it's like they're hearing fragments of conversation go past and wondering which bits to believe. I'm wondering whether a message-oriented approach (my reading of GINF's architecture, see http://www-diglib.stanford.edu/diglib/ginf/ 'Generic Interoperability Framework') would make these things easier? ie. instead of just broadcasting triples at a pile of RDF datasources and expecting them to do something sensible, use RDF to package up a message saying 'this graph <here> is an update of Dan Connolly's calendar entry'. All the time we're dealing with edits/additions at the grain of single RDF assertions, I can't see how we can have a sensible strategy for asserting into aggregated views. From what I've seen of existing RDF implementations, an API for navigation and graph-oriented query for RDF models seems somewhat of a low hanging fruit. When we get into territory of describing semantics of 'add this RDF statement' into (virtual) graphs, this seems trickier. I'm not sure where a pragmatic line should best be drawn. One approach might be for aggregating graphs to _always_ reject assertions since they're unqualified to route them? Dan
Received on Wednesday, 10 November 1999 15:15:30 UTC