Some design notes

[Jonathan Rees]

As a way to get discussion started, I've started writing up my
thoughts on how the shared names beast might work, technically.

http://sharedname.org/page/Design_notes_(JAR)

This is a work in progress. It is certain to be incomplete, confusing,
and buggy. If you're only going to read it once, don't do it now; I
suggest you wait a week or so. If you're eager to get to work, then by
all means read it and respond with your questions and comments. I will
use them to improve the document.

These are just my own thoughts - not any representation of group
consensus.

Best
Jonathan

[Benjamin Dai]

Just curious, are there any use cases or requirements that Shared
Names has developed? This will help me better review and respond to
the design document.

Thanks!

Benjamin

[Alan Ruttenberg]

See "Requirements" on http://sharedname.org/page/Project_overview
-Alan

[Larry Lannom]

A few comments:

1, I don't know the resolution referenced in

"...may mislead someone into thinking that the URI names the document
visited as opposed to the record itself. (I'm not sure I believe this,
but it's the view espoused by the TAG in its httpRange-14 resolution,
and is a foundation of the linked-data architecture.) "

but I certainly agree that it is vital to be precise about what it is
you are identifying. For many users it probably won't matter whether
they think you are naming a thing or a description of that thing, but
if it is left vague you will find people arguing past each other down
the road.

2. "If the required state is shepherded somehow by a PURL or handle
server (something I have not thought much about), then those systems
would have to support master/slave state propagation. I believe the
handle system already has native support for replication,"

To the extent that I understand the problem, this would be a pretty
straight-forward handle system implementation. Each databank would
have a record in the handle system with a set of typed values
corresponding to whatever information or transforms you needed for
each databank. Those values could be maintained through some sort of
form interface, although if you need to control access you have to
maintain that as well. The sharedname servers would be zero-knowledge
servers, with caching, that would talk to the handle system,
understand the return values, and turn them into the appropriate http
responses. This is exactly what the handle system proxies do now. The
only trick, again as I understand things at this point, is to
accommodate identifiers for all individual records in the databanks
without actually carrying them all in the handle system. This can be
done, assuming a single pattern per namespace, where all appropriate
responses can be derived from the input http string combined with the
information for the namespace, and is all driven by that single
namespace record. Its all done inside the handle servers and the
sharedname servers would just be resolving handles. This is similar to
what we're currently doing with Max Planck. And you get master/slave
propagation just by configuring the handle servers appropriately.

4. "Then comes the hard part"

Right. As you point out in the front, survivability is probably your
biggest challenge. The technology is necessary but not sufficient.

Larry