Kahn Overhauling the Internet
Whanana sent us an article about information objects as visualized by Robert Kahn.
The article is written from a fairly childish place (it explains DNS for crying out loud, and the bulk of it is a history lesson obviously designed for a mainstream paper) but Kahn's Digital Object Identifier concept is interesting. If anyone has links to RFCs and the like, please post them in the comments.
First of all, what's scary about the DoD putting its library on-line?
Second of all, only people who create nothing think that the creative work of others should be free. If copyright holders want to be able to track their work and make sure that their work is only available to people who have acquired a licence, I don't see a problem. In fact, it will be a HUGE help to individual authors/musicians/artists/whatevers, since they can take care of managing distribution all by themselves without needing a big company to handle it. Of course, promotion is still an issue, but that's another debate...
If you want to be a thief, you'll hate this. If you want to actually use the net to find stuff and be reimbursed for the things you create, you'll love it.
-jon
Remember Amalek.
The idea of objects being passed around by handles is the original concept for the Internet as espoused by Dr. Alan Kay. This is how he originally envisioned Object-Oriented information models. Now the Internet is being re-invented to change it from the simple collection of connection paths to a real highway where real self-contained objects can be passed around. This may be better, maybe not. I guess it depends on how it's implemented. If each object has to be accompanied by a slew of "helpers" to allow the recieving node to interpret it, this could get ugly. But if a single, open, method is used, this could be beautiful. Imagine a fully portable object going from platform to platform totally transparent to the user!
.NET and I just hope the geniuses who are behind this idea don't get mown down by Microsoft's marketing muscle.
Of course, it'll have to compete with
Steven
-- I have marked myself unwilling to moderate-- I don't have other accounts to artificially inflate the karma of
Is he going to use the Genesis device?
A system serial number with bits reversed, and packed against the top of the 64 bit word.
An object creation counter for that system serial number -- under localized control/increment.
I had to continually fight off people who wanted to subdivide the 64 bits into fields, the way IP was. The primary discipline I wanted people to follow was to keep routing information out of the object identifier so that object locations could be changed dynamically. It was amazing how many times I had to explain this to people who should have known better.
Unfortunately, I didn't explain it to the right people at DARPA, although I did have a couple of meetings with David P. Reed about it when he was still at MIT's LCS.
I touch on some of this history in a couple of documents, one written recently and one written at the time.
Until I read the article about Kahn, I didn't realize that DARPA chose the IP nonsense at almost exactly the time that the AT&T/Knight-Ridder project that was funding me made a bad choice of vendors that resulted in my resignation from that particular high-profile effort and try to strike out on my own turning 8MHz PC's into multiuser network servers (which I actually succeeded in doing after a lot of blood letting, but that's another story).
Seastead this.
Since I've been involved in this discussion for some time I thought I'd recycle some of my old comments :-)
Date: Thu, 20 May 1999 16:46:26 -0400 (EDT)
From: "Arthur P. Smith"
To: discuss-doi@doi.org
Subject: Re: [Discuss-DOI] DOI: Current Status and Outlook
On Wed, 19 May 1999, Norman Paskin wrote:
> A paper which provides a summary of the current thinking on DOI has
> just been published in D- Lib magazine at
> http://www.dlib.org/dlib/may99/05paskin.html
This does answer a lot of questions we had, mostly in what seems
to be the right direction. The relationship with INDECS on metadata
issues looks like a particularly good resolution ("functional granularity"
is essentially what I was looking for in one of my earlier
questions). It looks like a specific metadata "Genre" needs to be
worked out in detail for journal articles (re reference linking) - and
it's not clear who has responsibility for this (the IDF or someone else?)
but at least at the level specified in this article it looks workable.
But to some extent the paper shows the DOI is a solution in search
of a "killer application" (mentioned several times in the article).
There's a chicken-and-egg problem here: the potential applications seem
to require widespread adoption before they become useful.
As one of the final bullets says: "Internet solutions are unlikely to
succeed unless they are globally applicable and show convincing power
over alternatives" - does the DOI as described show convincing power
over the alternatives?
It's sometimes hard to know what counts as an alternative, but the
following systems (some listed in the article) could be
alternatives for at least some of the things the DOI does:
1. the handle system itself
2. uniform resource names
3. IETF's DNS-based Naming Authority Pointer
4. Persistent URL's (PURL's)
5. rule-based reference linking (link managers, Urania, S-Link-S)
6. a global LDAP/directory service
Alternatives 1-4 provide a variety of routes for creating a unique
digital identifier for something - we really don't NEED the DOI just
to have digital identifiers, though DOI does provide a handy rallying
point for those of us providing intellectual property in digital form.
Alternative 2 is the highest level of digital identifier, but perhaps
that is all we really need? There is room for many "naming authorities" -
perhaps even each publisher could be their own naming authority. That
would depend on widespread adoption of (3) which may or may not happen,
and resolution of general registration processes too.
As the article mentions, general implementation of URN's is quite
limited even after almost a decade of work. Is there a reason why
nobody has found it particularly useful yet?
Alternative 1 is, to some extent, a non-issue (a DOI is, after all,
just a handle) and is also, to some extent, the same issue. Any
publisher could, with or without DOI, register as a handle naming
authority and create handles for its digital objects. Is some of
the DOI work duplicating what has already been done (or should have
been done) for the handle system itself? As the handle system web
pages mention (http://www.handle.net/) it is at least receiving some
use as a digital identifier of intellectual property by NCSTRL,
the Library of Congress, DTIC, NLM, etc. Does the DOI provide
convincing power over using the handle system directly?
Alternative 4 (PURL's) is critiqued at length in the article,
particularly on the issue of resolution (section 3). Perhaps I
don't understand properly, but I don't quite agree with some of
the arguments against PURLs. Any digital identifier can be used to
offer great flexibility in resolution - a local proxy can redirect to a local
cache or resource, for example, for ANY of the unique identifiers
under question. Once resolved, the "document" resolved to can
itself contain multiple alternative resolutions. And a handle is only
going to have multiple resolutions if the publisher puts it there
(who else has the authority to insert the data?). So I think the
single vs. multiple redirection issue is a red herring. I do agree it's
nice to have a more direct protocol (though from looking at the details
of the way handles are supposed to resolve there is a lot of
back-and-forth there too). As far as being a URN or not, there's
no reason why PURLs couldn't be treated as legitimate digital identifiers,
even if they are simply URL's at the moment. On "scalability" - the
current handle implementation doesn't seem particularly scalable
either. Only 4 million handles per server? Only 4 global servers
(with 4 backups that seem to point to the very same machines on
different ports)? And those servers seem to all be in the D.C. area...
Not that I think PURLs are wonderful, but does the DOI provide
convincing power over using PURLs, as far as identification and
resolution goes?
Which is presumably why we've been told DOI's have to do
more than just identification and resolution. Hence metadata, to
provide standard information to allow "look-up", multiple-resolution,
and digital commerce applications. This actually makes a lot of
sense. And the other id/resolution alternatives do not
seem to meet the INDECS criteria as well as the DOI can.
But what does this have to do with reference linking, the
first "killer application" mentioned? The look-ups required there
are almost certainly going to be more easily performed with
specialized databases (A&I services) or direct rule-based
linking (alternative 5) and in fact this is already
being done, generally without the use of DOI's. The DOI does not seem to
make the linking process easier, so there's no "convincing power"
here it would seem.
I added alternative 6 (global directory service) as a wild-card -
this seems to be a major focus of "network operating system" vendors -
Novell's NDS, Oracle's OID, Microsoft's Active Directory - these seem
to be systems intended to hold information on hundreds of
millions of "objects" available on a network - an example being the
personal information of a subscriber to an internet service provider.
But another potential application of these is to identify and provide
data on objects available on the net - intellectual property or other
things available for commerce. Is this something the DOI could
fit into, or is it something that could sweep URN's, handles, DOI and
all the rest away? I really don't know, but it seems like
something to watch closely over the next year or so.
Energy: time to change the picture.
Anyone else notice the part about the central Object Id database? Just think how much grief ICANN has caused with the DNS root. I love to think what the Object Id Root owner will be like. This is a lame duck. Companies will probably love it (in theory), however, it cant function in the real world unless almost everyone adopts it. And god knows that wont happen.