Re: [art] Software URNs for dependency representation

[Nico Williams <[e-mail]>]

On Tue, Jun 27, 2017 at 11:41:40AM -0700, Roy T. Fielding wrote:
> Hmm…
> 
>     https://dwid-org.github.io/uri/historical/draft-ietf-uri-roy-urn-urc-00.txt

Yeah, something like that.

I know -I'm certain- that we've had a discussion about this many times
in the past.  This is really all about how to name things in a way that
is location-independent yet dereferenceable.  A perennial debate, no?

URIs leave it to the scheme to bake in how to dereference.

URNs don't deal with automatic deref, though where a URN is more than
just a name -- where a URN is a named object that could be retrieved --
then there's generally at least an informal way to dereference.

Maybe we should distinguish pure names (e.g., as used in protocol
elements, such as OIDs) from named resources and then require a
dereference mechanism for the latter.  Right now the one mechanism we
have for this is defining a new URI scheme.

So a new URI scheme it would have to be today, though that is somewhat
dissatisfying: there are many URNs that name resources and which could
use a deref specification.

I'd rather be able name I-Ds and RFCs with URNs and have web software
universally be able to dereference those than have to add an rfc: URI
scheme to get the same effect.  But I'd live with an rfc: scheme, and
I'd live with an sw: scheme.

DOIs for software were mentioned.  But I think with software it's nice
to be able to see names and other metadata in the URI, and it's nice to
be able to have a very light-weight location resolution algorithm.

Yes, yes, we could have every name be a hash or UUID.  But URIs have a
way of leaking into UIs, so having somewhat human-readable URIs is
somewhat handy.  (Having a hash as part of a URI is not a problem
though.)

The location resolution algorithm I have in mind is dead trivial:
resolve the location of the base respository, add local part from the
URI.  The first part can be cached for a long time -- forever even, with
cache invalidation only upon failure.  The second part is dead trivial.

Any location resolution algorithm that requires online infrastructure at
all times will probably be very dissatisfying.  Thus I oppose the use of
DOIs as a primary mechanism for identifying software.

Nico
--