A bit about PURLs
inkdroid.org
inkdroid.org
The functionality is basically the same as PURLs.
> every PID is a service commitment involving at least some sweat equity
These things need to be as stable as possible because people are going to rely on them. Here's where the stupid starts creeping in. You can mutate the representation all you want but don't ever change the URL and everyone has a domain name right? oh, they don't... Ok, I'll make PURLs. A single domain name that will last until the end of time and I'll allow people to register a portion of the namespace and do redirects to their own domain and THAT can change without breaking things.
Why do these need to last until the end of time? I can make a URL that represents something, say the Mona Lisa, and you can mint your own URL to the exact same Mona List and if we want we can say that your URL is the same as my URL but that doesn't work really well so we'll just tell you to never change URLs. Then we have blank nodes. What's that you say? They're existential nodes. They're nodes that have no identity. But I thought the great thing about using URLs was that we can all have our own namespace? Well, that's tedious and sometimes we just don't care but if you do we can make them locally permanent through a process called Skolomization. They're just opaque URLs but they need to have structure. But I thought they were opaque? Sort of. We're going to have namespaces! You'll organize your data into hierarchical namespaces based on the URL. But I thought we were working with graphs? You are, but your labels and identifiers are hierarchical, but opaque.
Then we're going to use these identifiers, that can be arbitrarily long and random, in databases. Well, that sucks, so we'll just map them to something more reasonable and maintain a huuuuuge table and mostly ignore them locally, except where we can't. Then we'll have reasoning - except where we can't - and we'll pile our house of cards on top of JSON. Oh, and we'll have a constraint language called, SHACL, defined in more RDF because why not. Who doesn't like noodling about with a graph serialized to a tree and hope you get everything right.
It's a death from a thousand cuts and the entire way you'll be told, by a bunch of academicians, how stupid you are for not marveling and appreciating this wonder that they've constructed.
I come away with the opposite reaction: exposed "pipes", in this instance, are undesirable. Their being exposed raw probably contributes to the kind of problem that PURLs were created to cure.
URLs are document identifiers foremost—that's what they're supposed to be. Too often, though, they reflect instead the organizational scheme of the current content hierarchy (apt to change at someone's whim sometime in the future) or expose details of the underlying tech stack. You see this in blogs a lot. Take this post, for example. This document's identifier is <https://inkdroid.org/2021/12/16/purl/>. It could just as easily be <https://inkdroid.org/blog/2021/12/16/purl/> or <https://blog.inkdroid.org/2021/12/16/purl/>, and at some point in the future, after a tech migration, it very well might be. This is a problem. I've seen companies submit blog posts to HN, and then just a month or two later switch something up in their publishing pipeline, so now the link at the top of the discussion doesn't resolve anymore. Nobody seems to care about this. In a concrete example I recall, I reached out to someone involved to say that their link is returning a 404, and the response was basically, "Yep. It is. We switched things up," and not, "Oh shit, I didn't even think about that. Let me go fix it." I think this is an indictment of the tooling. For all the breathless fawning about how flexible this or that static site generator is, the reality is that what you might call the revealed position (akin to revealed preference) of most people is that it's too much of a chore to worry about—or in other words, these things aren't all that great at all, and the aforementioned fawning is all just masturbatory technofetishism—a reason to spend an afternoon evaluating the latest hyped thing and then a couple days migrating to the one whose marketing pull resonated with you the most.
The author here mentions an early gig as a university librarian. One thing that gets me is that institutions like universities should be particularly sensitive to things like preservation and longevity. But universities break shit all the time! There's something about tech where, as soon as people are cognizant of a computer's involvement, they rewire their thoughts and drop their standards—or worse: push for obvious breakage and treat you like you're insane (or a bit slow) if you suggest that maybe we shouldn't be doing things this way. (Or maybe it's an instance of Ra making an appearance <https://srconstantin.wordpress.com/2016/10/20/ra/>.)
Separately, one idea I've been toying with is resolving bibliographic citations in their original format. To give an example:
One scholar might cite a work as: Licklider, J. C. R. (1965). Libraries of the future. Cambridge, MA: MIT Press.
Another might cite the same work as: Licklider, J. C. R. Libraries of the Future. Cambridge: MIT Press, 1965.
What I'm proposing is that when a publisher becomes aware of a citation (perhaps they can set up an open endpoint, à la Trackback from the early 2000s), then they recognize it and set up a resolvable reference if it doesn't already exist. The effect of publication of the previous two works would result in two new permanent identifiers being minted:
https://mitpress.mit.edu/Licklider, J. C. R. (1965). Libraries of the future. Cambridge, MA: MIT Press.
https://mitpress.mit.edu/Licklider, J. C. R. Libraries of the Future. Cambridge: MIT Press, 1965.
That is, you take a bibliographic citation in its original format—as it appears in the printed text of the citing work—and then turn it into a fully qualified URL by tacking it onto the end of the domain associated with the publishing authority. The closest related work that I know of happening right now is the Visual Meta system.
The proposed scheme exploits the fact that an HTTP resource really can be named just about anything, and there are essentially a limitless number of identifiers that you can mint, since redirects are basically free. The result is truly durable URLs, but what's important is that we push for the appropriate cultural changes where we recognize how valuable this infrastructure is, and the powers that be live up to their obligations to not break these things as wantonly as is currently tolerated. Maybe with such a scheme, absent most evidence of being overtly "syntaxy", people will be more likely to recognize its utility.
URIs are identifiers, URLs are locators. A lot of standards replaced “URL” with “URI” as part of the idea that we should be using identifiers that may coincidentally be locators rather than principally direct locators, but neither the terminology nor the substance has been super successful, though I think you are the first person I’ve seen who has zealously adopted the idea but not the terminology (the reverse is much more common.)
I've seen this argument before—that URLs came first—and it's junk. The accusation of URIs as a retcon is itself a retcon.
First, even if we grant all of your premises, the fact that URLs are URIs contradicts the entire argument.
Secondly, it was always about identifiers. Not making any appearance in TBL's "Information Management: A Proposal" is the term URL (and neither does "locator", nor the related term "address"). URLs wouldn't appear for years. What he does spend time discussing, though—from the very beginning—are names, i.e., identifiers. By 1992, and before the first URL RFC appeared, TBL is writing about "UDIs"–Universal Document Identifiers. In fact, the agreement to work on URLs was an agreement that was made during an IETF BOF session called... "Universal Document Identifiers BOF"—using the same terminology as TBL's UDI memo.
But even all this minutiae is beside the point; none of this even matters, since...
> rather than principally direct locators[...] I think you are the first person I’ve seen who has zealously adopted the idea
You have to be misreading me. What offense of zealotry have I committed here that doesn't comport with closely held values of admirers and beneficiaries of URLs?
The entire point of the message you responded to is that I want the link <https://mitpress.mit.edu/Licklider,%20J.%20C.%20R.%20(1965)....> to work. That's an identifier _and_ a URL (not least of all because all URLs _are_ identifiers). If you somehow think I'd be happy if it functioned as a URI without also exhibiting the properties we've come to expect of URLs (live ones, that is)—e.g. that it might be true that after poking it into the your browser, it doesn't actually do anything—then you have greatly misunderstood me and missed the point entirely. It needs to be able to resolve, using existing URL-supporting client software (commodity browsers, etc.) An identifier that does not function as a locator—one that doesn't "contain enough information to allow the document or index to which it refers to be accessed" as TBL wrote in 1992—is simply not an implementation of what I wrote out in the previous message.
I didn't make that argument.
I said that a number of standards replaced reference to URLs in earlier versions with references to URI in later ones as part of a movement among those involved in the standards to focus (refocus, if you prefer) on identifiers whereas previous usage in the context of those standards had focused on URLs function as locators.
And, also, that this was less successful in shaping actual usage than the people involved had hoped in many cases.
Fine, but that's not exculpatory. What that means, then, is that what you wrote is a comment that has no bearing on the thing that I wrote.
Do you have something that is relevant to what I wrote—or is your input in the thread limited to the sort of dismissive, superficially-relevant-but-not-really pseudo-retort from your first comment?