As people get their brains in gear with new RDF ideas, I'd like to propose one of my own. It's a cross between an RDF testbed, a demo and an interoperability checker. Here's the idea: A reasonable goal for RDF should be to implement basic database functions (insert, update, delete) in a decentralized fashion. I'd appreciate comments and pointers to related work to me or firstname.lastname@example.org.
The utility of this kind of system is obvious -- there are many situations where people have data which they'd like to be widely distributed in a decentralized fashion. To simplify the problem, we can assume that all everyone involved is trusted (eliminating trust) and that we know who everyone else is (eliminating discovery). We'll also forget about the case where two changes to the system conflict.
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.
Inserts (adding triples) has been already solved. To insert data to the decentralized database, you simply publish it to the Web at a well-known location.
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.
The simplistic way to manage this would be to assign each triple a URI and then publish updated information on each of the statements. However, by doing this, we run into the tricky problem of both asserting and reifying a statement at the same time. @@ reification experts should let me know how to do this
Updates can be implemented through the removal of one triple and the addition of another.
Part of LogicError. Powered by Blogspace, an Aaron Swartz project. Email the webmaster with problems.