- From: <ssarkar@ayushnet.com>
- Date: 20 Feb 2001 08:47:00 -0800
- To: aswartz@upclink.com
- Cc: www-rdf-interest@w3.org
On Sun, 18 February 2001, Aaron Swartz wrote: > > URI: http://logicerror.com/decentralizedRDF > > **Introduction and Overview > > > Here's what such a system would look like: You have a number of nodes > with RDF storage systems and interfaces to the distribution system. To > make a change to the database, you make it on your local copy and then > distribute it to the other nodes. Within a reasonable lag time all of > the databases will be synchronized. > Insert/update/deletes cannot be done on RDF documents unless there are back-end relational database repositories for RDF data/metadata. 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. > **Integration with RDF > > ***Updates and Deletes > > Updates (modifying triples) and deletes (removing triples) are more > difficult, and require entering an area that RDF has been afraid to > touch: time. Most RDF systems do not factor time into the equation, or > at least, they do it in a simplistic way. > 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. There are many other possibilities for such a system. > > -- > Aaron Swartz <me@aaronsw.com>| ...schoolyard subversion... --ssarkar@ayushnet.com
Received on Tuesday, 20 February 2001 11:48:07 UTC