RE: Decentralized RDF Distribution

:Aaron Swartz:
: ***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.

Not true. Any insert can have side effects on any application that is itself
performing inserts based on its chain of reasoning (such as a forward chainer in
a rules base, or a relational db trigger mechanism that in turn causes an update
to the db). It might be "solved" if you have a truth maintenance system in place
to keep track of things.


:Aaron Swartz:
: ***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.

I agree with Seth. Modification is an atomic unit of work consisting of a
retract followed by an assert.


:Aaron Swartz:
: 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_

Reification is more problematic than this. Insertion of a refication into a
store is atomic. But it's not clear whether the resulting reification quads
should be atomic when it comes to units of work such as retract and update or
whether the quad members are or are not fully independent.

I raised this last year wrt to procedural semantics for dealing with refication
in a assert/retract system (namely there isn't any).
<http://lists.w3.org/Archives/Public/www-rdf-interest/2000Nov/0209.html>

Bill de hOra

Received on Monday, 19 February 2001 12:02:47 UTC