This sounds like an interesting service, but makes me wonder, wouldn't it just be simpler to do a Wayback machine like thing (which I think the article says is sometimes done) than to try to update all URLs.
> every PID is a service commitment involving at least some sweat equity
> 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/>. 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 r...
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've seen this argument before—that URLs came first
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?
Ah, the raw underbelly of the semantic web exposed for all to see. The semantic web is what you get when you let the Lisa Simpsons of the world run things. It all starts with a seemingly reasonable premise. We need unambiguous names for things and we need lots of them. Do we already have something for that? Sure DNS, and by extension URLs. So since I have my own namespace to work with I can come up with names all day without clashing with anyone else. But just a name is pretty opaque. It could be anything. How do I interrogate it and ask it what it is? Well, when you ask for an http url it returns you something. How about we have it return what it knows about itself. Ok, but now we have a problem. We have the thing, and some representation of that thing. I might have a URL that's supposed to represent you but the page that comes back has a mime type, size, etc and you are not 12Kb. So what do we do? No problem, we'll not really return anything, we'll do a 303 redirect or use fragment identifiers so the the url for the thing with the fragment is differers from the page without the fragment.
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.
10 comments
[ 2.8 ms ] story [ 36.5 ms ] thread> every PID is a service commitment involving at least some sweat equity
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 r...
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?
The functionality is basically the same as PURLs.
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.