[urn] Re: General grumble about incorporating other identifi ers into URNs

Yep, and that was how the debate ended up. Before that time, many of us
assumed that anything more complicated than a simple string comparison
denoted hidden semantics that qualified as metadata outside the URN
itself's function.

<insert "weather map" vs "the weather map right now" vs "the weather map
last week" conversation here>

Sorry, just reminiscing...


On Thu, Mar 12, 2026 at 9:35 PM Dale R. Worley <[email protected]> wrote:

> Michael Mealling <[email protected]> writes:
> > I vaguely remember this specific issue with ISBNs and ISSNs popping up a
> > very long time ago, and the quasi-consensus was that non-URN concepts of
> > equivalence specific to an existing, or otherwise, namespace should be
> > handled through namespace-specific metadata retrieved about the thing
> being
> > identified. E.g. the general equivalent of an "also known as" field.
> >
> > The URN "resolution" infrastructure could still be easily stood up. ;-)
>
> Hmmmm...  I re-read the urn:isbn registration a few days ago and it was
> as I remember.  Specifically, if you're comparing a urn:isbn with a
> 10-digit number, you first have to prefix it with 978 to make the
> 13-digit form.  The initial proposal had a lookup step where the
> tester-of-equivalence would go to some web site to do the conversion,
> but that looked like it would be an operational nightmare compared to
> just hard-coding into the registration how the 10-digit space was
> embedded into the 13-digit space.
>
> Dale
>


-- 

Michael Mealling

+1-678-640-6884
LinkedIn <https://www.linkedin.com/in/mealling/> - Twitter
<https://linkedin.com/mmealling> - Instagram
<https://www.instagram.com/mmealling/>
Starbridge Venture Capital <[email protected]>, Space Frontier
Foundation <[email protected]>

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]