Re: date in URN

Karen R. Sollins writes in <>:
>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                   Indianapolis, IN

Received on Tuesday, 27 June 1995 08:57:15 UTC