 |
 |
Jonathan Rochkind writes: > Isn't there always a single point of failure if you are expecting > to be able to resolve an http URI via the HTTP protocol? Yes (modulo the use of multiple servers at a single IP address). But failure of a given document is typically not catastrophic -- there are plenty of other documents out there. Failure of the PURL server means failure of every document that has a PURL. What's more, PURL doesn't _replace_ the existing point of failure, it just adds another one: remember that purl.org doesn't itself serve any documents, it just redirects to where the document actually: for example, http://purl.org/dc/terms/ redirects to http://dublincore.org/2008/01/14/dcterms.rdf# So if either purl.org or dublincore.org goes down, you're nadgered. > Now, if you have a collection of disparate http URIs, you have > _many_ points of failure in that collection. Any entity goes down > or ceases to exist, and the http URIs that resolved to that > entity's web server will stop working. > > I'd actually rather have a _single_ point of failure, in an > organization that resources are being put into to ensure > persistence, then hundreds or thousands of points of failure, many > of which are organizations that may lack the mission, funding, or > understanding to provide reliable persistence. Sounds like what you want is a single _host_, which really would either work or not. At the moment, if you use PURLs, you know none of them will work if the PURL server goes down, and you still have the problem of individual server flakiness. _/|_ ___________________________________________________________________ /o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk )_v__/\ "You take two bodies and you twirl them into one, their hearts and their bones, and they won't come undone" -- Paul Simon, "Hearts and Bones"