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

Frozen URIs are structurally immutable

Follow

@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.

@Lady @cpsdqs That said it is extremely possible this is not a useful framework -- it was entirely motivated by the pun of "Cool URIs don't change" + different "temperatures" of data storage by cloud providers, punningly reinterpreting the "cool" from its original meaning into one that didn't exist at the time (but amusingly can be made to work).

I wasn't thinking about whether it'd be a useful concept.

@gaditb it is a useful concept in library science! altho the term of art there is “persistent identifier”. see arks.org/

it would also be a useful concept on the fediverse if fedi developers ever bothered to read a book on information science

@gaditb (for pURLs that aren’t MEANT to be dereferencable, see `tag:`, `urn:fdc:`, and `urn:uuid:`, among others)

@gaditb amusingly i think the most practical application for knowing the “heat” of URLs is with webcrawlers so they know how often to recrawl

@Lady Response header X-Temperature: Cool

----

My related hot take is DNS should be able to communicate similar information -- requests for "please limit request frequency to", commitments to "I'll aim to keep downtimes below X length, don't worry or assume I've broken down before then".

@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.

@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.