[pacaro]

I worked on a project that used "regular old URL" just like you suggest, for contract and service identifiers, which needed to be human read/write/generatable

Tag URIs would have been better because:

a) not everyone owns a domain, but tags allow email address as authority

b) it's confusing to many people to overload http URIs this way

c) as a contract identifier the URI doesn't need to point to anything, but this creates cognitive dissonance — this is probably part of b)

d) too damn long — tag URIs might suffer from this too. We were using these all over the place and there's no good way to truncate them

[DorothySim]

a) is particularly interesting to me. I thought about giving people ability to create their own namespaces and used https://user.example.com or https://example.com/user as a namespace but tag URI looks cleaner.

By the way why did you need human readable IDs? I'm asking out of curiosity because there is certain charm to just using UUIDs everywhere (and urn:uuid).

[pacaro]

There were some places, where only machines would interact with them, that we used urn:uuid. But we had UI, code, and log files etc, where developers needed to interact with them too