> Maybe this little post will whet someone else’s appetite to looking closer at PURL as a web infrastructure. I think it also is a great example of how exposed

> Maybe this little post will whet someone else’s appetite to looking closer at PURL as a web infrastructure. I think it also is a great example of how exposed pipes are useful when building applications that are meant to be infrastructure. 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/ https://inkdroid.org/2021/12/16/purl/>. It could just as easily be <https://inkdroid.org/blog/2021/12/16/purl/ https://inkdroid.org/blog/2021/12/16/purl/> or <https://blog.inkdroid.org/2021/12/16/purl/ 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/ 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. ... appropriately URL-encoded, of course (which can be done and is done transparently by most browsers, so the general public need not be bothered with the details), and each would redirect to the page that is currently available at <https://mitpress.mit.edu/books/libraries-future https://mitpress.mit.edu/books/libraries-future>. If at some point the canonical location resource changes, then so, too, should the target of the redirection. 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.