Re: Calendar sharing and synchronization

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