Re: date in URN

Hi Karen!

[ You wrote: ]

} Peter,
} We've been through some of these arguments about the degree of
} user-friendliness before (I'm sure you were there - didn't we do some
} of this in Houston?)

<sigh> Yup...

} .  .  .   I believe that
} we've perpetuated a slight mistake in the URI WG by calling these
} things URNs ("names") because too people assume that a name has to be
} human friendly.  These things should be as human unfriendly as we can
} get away with, to discourage their direct use by humans.  They are
} serving a different purpose at a different level of abstraction than
} human friendly names.

I agree, we're definitely talking about two sets of
functionality here, although I'm not yet convinced there's
something wrong with calling these things "names". We just
need to be careful about what we think we can do with
them. For me, the requirements for comparision and
dereferencing remain the defining elements.

Depending upon how we do it, I think dereferencing does
mean we need a human friendly part for when humans must
select these things. For dereferencing, we obviously want
to focus on the mechanical processing capabilities and
might be willing to sacrifice readibility here if it makes
it work.

Taken together this probably means that a URN probably
needs two components, and that we need to be able to
process/handle the two separately. Still, I think they
also need to remain bound together as in gopher menu
items. So, perhaps this means a URN should look like:

  <naming authority>:[<optional human readible string]>:<unique ID>

Note! I'm not proposing a syntax, I'm proposing a set of
components here...

					- peterd


  ...there is reason to hope that the machines will use us kindly, for
  their existance will be in a great measure dependent on ours; they will
  rule us with a rod of iron, but they will not eat us...

                                               - Samuel Butler, 1872

Received on Sunday, 25 June 1995 12:06:25 UTC