Comments on: locators http://mediacommons.futureofthebook.org/mcpress/plannedobsolescence Publishing, Technology, and the Future of the Academy Mon, 02 Jan 2012 17:10:11 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Jesse Pearlman Karlsberg http://mediacommons.futureofthebook.org/mcpress/plannedobsolescence/four-preservation/locators/#comment-2194 Jesse Pearlman Karlsberg Thu, 11 Nov 2010 17:21:22 +0000 http://mediacommons.futureofthebook.org/mcpress/plannedobsolescence/?page_id=161#comment-2194 Just a copy edit to offer here. In the quote from Manoff, "insure" ought to read "ensure." If this error is in the original, perhaps a "[sic]" is in order. Just a copy edit to offer here. In the quote from Manoff, “insure” ought to read “ensure.” If this error is in the original, perhaps a “[sic]” is in order.

]]> By: Sean Gillies http://mediacommons.futureofthebook.org/mcpress/plannedobsolescence/four-preservation/locators/#comment-783 Sean Gillies Mon, 11 Jan 2010 10:29:09 +0000 http://mediacommons.futureofthebook.org/mcpress/plannedobsolescence/?page_id=161#comment-783 The problem with URLs isn't inherent fragility but that we often don't get the identifier space of our information architecture straight before we begin to publish resources on the web [1]. Major web "properties" like Wikipedia can and do maintain their URLs as their infrastructures change. 9 years ago http://www.wikipedia.org/wiki/Computing was served by a Perl CGI script on a single server. Now it's served by 200 application servers, 20 database servers and 70 cache servers [1]. Wikipedia's data has moved many times, yet the original URL still exists, now redirecting to a language-specific variant (http://en.wikipedia.org/wiki/Computing in my case). Maintaining the original URL is Wikipedia's policy. Nine years might not seem very long to a librarian, but there's no technical reason why (given funding) that policy can't continue indefinitely, even if Wikipedia grew tenfold, physically relocated their data center, switched to app servers written in Erlang, or switched from Squid to Varnish. [1] http://www.w3.org/Provider/Style/URI [2] http://www.datacenterknowledge.com/archives/2008/06/24/a-look-inside-wikipedias-infrastructure/ The problem with URLs isn’t inherent fragility but that we often don’t get the identifier space of our information architecture straight before we begin to publish resources on the web [1]. Major web “properties” like Wikipedia can and do maintain their URLs as their infrastructures change. 9 years ago http://www.wikipedia.org/wiki/Computing was served by a Perl CGI script on a single server. Now it’s served by 200 application servers, 20 database servers and 70 cache servers [1]. Wikipedia’s data has moved many times, yet the original URL still exists, now redirecting to a language-specific variant (http://en.wikipedia.org/wiki/Computing in my case). Maintaining the original URL is Wikipedia’s policy. Nine years might not seem very long to a librarian, but there’s no technical reason why (given funding) that policy can’t continue indefinitely, even if Wikipedia grew tenfold, physically relocated their data center, switched to app servers written in Erlang, or switched from Squid to Varnish.

[1] http://www.w3.org/Provider/Style/URI
[2] http://www.datacenterknowledge.com/archives/2008/06/24/a-look-inside-wikipedias-infrastructure/

]]>