- From: Danny Ayers <danny@panlanka.net>
- Date: Wed, 21 Feb 2001 00:14:28 +0600
- To: <ssarkar@ayushnet.com>
- Cc: <www-rdf-interest@w3.org>
<- 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