W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2001

Re: Decentralized RDF Distribution

From: Seth Russell <seth@robustai.net>
Date: Mon, 19 Feb 2001 02:11:13 -0800
Message-ID: <3A90F140.547B3259@robustai.net>
To: Aaron Swartz <aswartz@upclink.com>
CC: RDF Interest <www-rdf-interest@w3.org>
Aaron Swartz wrote:

> URI: http://logicerror.com/decentralizedRDF

I like this point of view :)

> 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.

I agree that (eliminating trust) is a legitimate simplification of the
problem, we should be able to get the system running and then add trust as
an after thought.  But I don't think that we can usefully simplify any
problems by (eliminating discovery); rather we need to build in the system
some basic assumptions relevant to discovery.  Everybody will encounter
(experience) the semantic triples at different times through different
feeds - some will have many triples in their experience of a specific
context; others will have encountered very few if any in  that context.
You can't just eliminate that basic predicament and be talking about the
same system.   I think you can only say that discovery can be eliminated
for a coherent interest group of people within a given context.   Within
that narrow sub cloud, the triples should (over time) tend to be the same.

> ***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.

I don't think it makes much sense to modify a triple.  Rather you need to
remove it; then perhaps add a different one.  So we have here only two
basic transactions insert and remove ... which may be better named assert
and retract.

> 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_

I think this is a good idea, have the original author assign a uri to each
triple.  The reified statement then is a quadruple [ statementUri,
subject, predicate, object].  When we assert triples, that's what goes
into the semantic cloud.  When people talk about those statements to the
cloud, they refer to them by putting the statementUri in the subject.  I
love it, it's simple.

If anybody is interested we could discuss how to actually do that in a
practical way with little or no change to the  M&S bible.  Anybody care to
suggest a uri format?

> **Related Links
>
>  - Finding RDF Services (or: imminent death of usenet predicted)[4] -
> Daniel Brickley[5] proposes a decentralized system for distributing
> RDF via USENET.

If you all are are behind using USENET, then I'm prepared to put some time
into drafting an RFC for the group.  I suggest going through the extra
effort to make it a group in the big 4 (not an alt group), that way it
will be propagated almost immediately to everybody's news server -
otherwise we run the risk of very few people having access to it.   May I
suggest some potential names:  comp.iffosystems.semantic .. or
comp.infosystems.rdf ... or comp.infosystems.rdf-feed ... or
comp.infosystems.semantic-cloud.

Seth
Received on Monday, 19 February 2001 05:01:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:48 GMT