- From: Danny Ayers <danny@panlanka.net>
- Date: Mon, 19 Feb 2001 23:21:31 +0600
- To: <fmanola@mitre.org>, <www-rdf-interest@w3.org>
Hi, <out of touch ramblings> Some form of bracketing will be needed as Frank suggests - otherwise you could have a scenario very comparable to the transaction classic of debiting one bank account and crediting another - if you stop halfway you've got an invalid (or at least undesirable) state. Some form of imposing ACID on a group of triples? Ideally some form of existing grouping (or one that could be easily produced using an existing tool) - but what about putting the set of triples (or even URIs) that should behave together atomically in a bag? Or is there a neater way of grouping (potentially distributed) items? The transaction itself shouldn't be too problematic - the relevant part of the database made read-only for the duration of the transaction (snapshot taken), all (grouped) changes made, read-write reinstated - I see problems with queueing where the sequence of the transactions is important, maybe better to reject an incoming update (return to sender?) if an update is already in progress. </out of touch ramblings> This is obviously quite a crucial problem - does anyone happen know how Linda/Javaspaces handles it? Cheers, Danny. --- Danny Ayers http://www.isacat.net <- -----Original Message----- <- From: www-rdf-interest-request@w3.org <- [mailto:www-rdf-interest-request@w3.org]On Behalf Of Frank Manola <- Sent: 19 February 2001 22:38 <- To: www-rdf-interest@w3.org <- Cc: RDF Interest <- Subject: Re: Decentralized RDF Distribution <- <- <- Inserts may have been solved as far as the simple mechanics of <- publishing them is concerned, but the semantic aspects are essentially <- the same as those of updates and deletes: you have to deal with <- temporal (or nonmonotonic) effects: specifically, the idea that the set <- of assertions has now changed, and that may change what you now conclude <- from the set of assertions (a subsequent email has pointed out that an <- update can be considered a combined delete-and-add operation). The <- whole issue of transactions (in the database sense) comes in too, since <- you may want to make what is a semantically-consistent modification to <- the "database" that consists of several distinct operations (inserts, <- deletes, modifys), and want somehow to bracket that set of operations. <- <- --Frank <- <- Aaron Swartz wrote: <- > <- snip <- > <- > ***Inserts <- > <- > 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. <- > <- > ***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. <- > <- <- -- <- Frank Manola The MITRE Corporation <- 202 Burlington Road, MS A345 Bedford, MA 01730-1420 <- mailto:fmanola@mitre.org voice: 781-271-8147 FAX: 781-271-8752 <-
Received on Monday, 19 February 2001 12:24:00 UTC