From: Fisher Mark <FisherM@is3.indy.tce.com>
To: "'URI'" <uri@bunyip.com>
Subject: Re: date in URN
Date: Tue, 27 Jun 95 07:56:00 PDT
Message-Id: <2FF01C6B@MSMAIL.INDY.TCE.COM>
Karen R. Sollins writes in <199506261640.MAA08135@lysithea.lcs.mit.edu>:
>The intention was that "human transcribable" not be the same
>as "human friendly". "Human transcribable" was supposed to capture
>the idea that if you really needed to, you could type it on your
>keyboard; more likely you might cut and paste it. It was not intended
>to suggest that you ought to WANT to do these things. In fact, rather
>the opposite. (Just as an example, in our project, the ids we've been
>generating use only 16 letters, none of them vowels. You can type them,
>but you probably won't get a lot of meaning out of them.)
Something I have noticed quite often in relational database practice is the
idea of the customer ID (used as a primary key in customer sales
transactions) being an opaque, or at least translucent, ID. The reason
seems to be that humans can make use of a lot of the available context to
determine that "Joe Jones" of Flint, MI is not the same person as "Joseph
Jones" of Niles, MI, when "Joe Jones" used to live in Niles, MI. For
computers, so far is algorithmically a lot easier to track "Joe Jones" as
customer 55-26731 and "Joseph Jones" as 55-28943, updating their data as
appropriate (where perhaps the "55-" could indicate a Michigan customer (or
perhaps not :)). I have also seen this in other types of databases where an
ID is for a specific object, where objects can be invoices, electronic
components, etc. URN requirements appear to match well with requirements
for customer sale IDs in that both should be immutable and unique for all
time. Perhaps there is a lesson here...
======================================================================
Mark Fisher Thomson Consumer Electronics
fisherm@indy.tce.com Indianapolis, IN