Cool URIs don't change
Hot URIs change constantly
Warm URIs change sometimes, every once in a while

Frozen URIs are structurally immutable

@gaditb all URIs are structurally immutable…… they are strings………

@Lady Sure but "cool URIs don't change" is using "URI" as synechdoche for "the 'X identifies Y' relationship between the URI string and the content".

So similarly here. The relationship is immutable.

@gaditb mhm

in practice you can’t have a URL be both frozen and dereferencable but it’s really easy to have a URL which is frozen and not dereferencable!

@Lady Elsewhere in responses, @cpsdqs and I came up with data: URIs and cryptographic-identifier URIs, like magnet: or ipfs: , as dereferenceable frozen URIs.

@gaditb @cpsdqs magnet identifiers are often not dereferencable–they require peers. IPFS presumably as well.

for data: URIs, you do have to qualify “dereferencable” specifically to mean “on the Web”; data: URIs can always be converted into a stream of bytes, but it is an embedded stream, not a stream accessible using the Internet

(consequently, you can’t have two data: URI resources which link to each other)

@Lady @cpsdqs But doesn't that apply to https?: URIs as well?
If the server isn't there (or has changed at. like. all.), the content's not dereferenceable. Or am I misunderstanding what you mean by that?

I was counting "dereferenceable" to mean "normal engagement with that URI using normal tools around it can convert it to the content* it represents".
(* does that have to be a sequence of bytes in particular? ... probably.)

@gaditb @cpsdqs no, that is what i’m saying

i would be willing to bet the vast majority of http(s) identifiers ever assigned are not, today, dereferencable

and the probability that an identifier be dereferencable decreases with the stability of the thing being referred to. a magnet link, which refers only to a specific sequence of bytes, stops being dereferencable the moment that specific sequence of bytes stops being known

it's not possible to have a URL which refers both to a specific thing and which can survive entropy. this is not true of “non-frozen” URLs. even if you lose the original representation of a thing at a given http(s) URL, you can serve something close, or a placeholder for that thing, or an updated version of that thing. the less frozen the URL is, the more dereferencability can be maintained; they are competing concerns

@gaditb @cpsdqs (note that dereferencability across time is the primary goal of COOL uri’s)

@Lady @cpsdqs @Lady @cpsdqs AHHH okay.
A magnet: URI breaks and can't be dereferenced if there is ever a time where no-one on the tracker has the specific sequence of bytes.

An isbn:* URI can be dereferenced as long as anyone has a physical or scanned copy.

(* urn:isbn: ?)

And the Ark website is something about that type of thing.

Follow

@gaditb @cpsdqs yes so basically there are two situations:

• you want to identify something WITH all its cultural trappings. for example, you want to cite “the standard that WHATWG currently calls HTML”. the DNS is pretty good at this. but these URIs are inherently fragile, because cultural trappings change. HTML used to be specified by W3C, not WHATWG. the URL changed when a different organization took over

• you want to identify something WITHOUT all its cultural trappings. you just want the thing. these URIs can be very stable, and increasingly stable the more precise you get about “the thing”. but you can’t dereference these identifiers, because they don’t encode any social/cultural information about how to access the identified resource

the idea behind DOIs, ARKs, etc is that you create identifiers of the second type, and then maintain a registry which links them to identifiers of the first type. this requires out-of-band information which cannot be encoded in the URI (like, who maintains the registry? this could change, and has to be allowed to change without changing the URI). but it lets you can bridge the gap between identifiers which are stable and identifiers you can use

Sign in to participate in the conversation
📟🐱 GlitchCat

A small, community‐oriented Mastodon‐compatible Fediverse (GlitchSoc) instance managed as a joint venture between the cat and KIBI families.