[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Visionaries] The Relative Semantic Web

From: Peter Minten
Subject: [Visionaries] The Relative Semantic Web
Date: Wed, 16 Apr 2003 19:23:04 +0200

Hi folks,

in search for a solution to the resolver problem I came to the conclusion that
the W3C made one major mistake when designing RDF: all RDF nodes must have
exactly one, unique, URI. I've tried to tackle this problem with link paths, but
the link path syntax is kludgy since it works around the actuall problem.

Now to refresh your memory: the resolver problem is "where is the node with URI
...". I tried solving it by locating the server based on the URI, it's not
elegant though, since if I wanted to put information about DotGNU on my own
webspace I wouldn't have the nice part in it that signals to users
immediately what it's about. I know however that the DotGNU RDF repository would
link to my stuff.

The internet today works with central DNS servers and assigned domains by
powerful authorities. I believe this system is weak, if somebody would take over
the authorities it would be easy enough to cause major damage. Beside that, I
simply don't like central authorities :-).

My new idea is to make node addresses relative and hooked up to the actual RDF
databases. So my stuff about how Forum works could be located at
dotgnu!people!PeterMinten!forum!howitworks (yes, a bang path :-), a link from my
node at DotGNU to the howitworks node on my own webspace. Again:
dotgnu => the central DotGNU node
dotgnu!people => the people node of DotGNU
dotgnu!people!PeterMinten => my node at DotGNU
dotgnu!people!PeterMinten!forum => a link to my own webspace, node forum
dotgnu!people!PeterMinten!forum!howitworks => the how it works node

Right, so what about collections? In link paths I solved this rather ugly with
conditions. But it's not really necessary if you avoid bags (bags are unordered
and thus undeterministic, making them unusable for addressing purposes). A
sequence, alt or linked list can be done like this:
foo!sequence!1!rest-of-stuff. It's also possible to use strings as indexers by
adding a property to the elements of the collection: indexer. The indexer
property would be a string that is unique in the collection. Having done that
you can simply use the indexer in the bang path instead of a number (and it
works with bags too): foo!sequence!bar!rest-of-stuff.

So how about finding the initial node, doesn't that require some kind of central
DNS authority? It could be done that way, but P2P technology, trust web
technology and some thinking makes it unnecessary. A hypothetical situation:

There 26 central node servers (so called start servers). I want to add the start
node 'silvernerd' to the system. What I do is contact one of the servers. The
server sees that the start node is uncoupled (free) and adds me. It also sends
an update to the other servers (this is easy using GNU.RDF) and since they trust
the server they add my start node too.

For resolving the node servers simply query their databases.

The real good part is yet to come. It's possible to have multiple groups of node
servers and they can be configured to trust eachother at a certain level. This
makes it possible to have a start node on one server group but not on another.
The good part is that there is no central authority. The down side of possible
netsplit can be resolved by putting the start servers name on the start of the
bang path in URI escapes (< >) like this: <startserver.uri>!nodes!dotgnu.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]