[DorothySim]

Is there a benefit of using tag URI instead of a regular old URL? E.g. tag:blogger.com,1999:blog-555 vs https://blogger.com/1999/blog-555 The only difference I see is that URL should point to something (can be referenced in a browser) which may or may not be an additional benefit.

[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

[dragonwriter]

> Is there a benefit of using tag URI instead of a regular old URL?

You don't need to control a domain name to issue tags.

Tags issued under an authority (domain name or not) are associated with a time, so remain valid and unique even if you abandon or lose the domain name, etc., providing the authority in the future.

Because tag URIs are explicitly not a scheme that provides location information, the resource does not have to be accessible by a particular protocol for the tag to be meaningful and accurate, and the URI doesn't communicate false expectations to readers familiar with the scheme when the resource is not accessible. (And, for similar reasons, tags don't risk conflicting with actual locators in the future.)