RE: Decentralized RDF Distribution

<- Insert/update/deletes cannot be done on RDF documents unless
<- there are back-end relational database
<- repositories for RDF data/metadata.

Not so - any kind of persistence could be used, and RDBMS might not even be
the best one for the job. Ok, so it's easy enough to store triples/quads as
records in a table, but when you come to doing anything with them you have
to use different structures - so persistence in a tree-structured DB/an
ODBMS could potentially be more efficient overall.

-> RDF documents
<- can be seen as views over one or more rdbms over the web.  Views
<- are updated by updating corresponding
<- data in back-end rdbms.  A transparent mechanism to
<- maintain consisteny over a set of RDF documents and
<- the multple back-end rdbms repositories is a solution
<- in this direction.

I think a modified version of the transaction (which encompasses distributed
sources of data) is a way to go. But note the word modified.

<- Time factor and update logs are maintained inside
<- rdbms data stores.  Each external RDF document can
<- also maintain a timestamp and an implicit URI to
<- the back-end database system(s).  Any attempt to
<- access RDF document(s) will make sure that the time
<- stamps on the document and the latest update on the
<- database(s) are the same.  If not, an implicit update
<- takes place through logs.

I strongly suspect more than this will be required - for instance (perhaps)
a system close to the database that monitors for potential infinite
loops/destructive conflicts. I reckon it would probably make sense to
associate such protection with the storage mechanism rather than with the
communication/inference systems.

There is one assumption your time-stamping approach is making, that I think
at least needs questioning -
will the most recent version of a piece of information always be the most
valid?

Cheers,
Danny.

Received on Tuesday, 20 February 2001 13:21:07 UTC