Federating purl.org ?

I suggested a while back that PURLs have become quite important, at least for some aspects of the Web (particularly Linked Data as it happens), and that the current service at purl.org may therefore represent something of a single point of failure.

I therefore note with some interest that Zepheira, the company developing the PURL software, have recently announced a PURL Federation Architecture:

A PURL Federation is proposed which will consist of multiple independently-operated PURL servers, each of which have their own DNS hostnames, name their PURLs using their own authority (different from the hostname) and mirror other PURLs in the federation. The authorities will be "outsourced" to a dynamic DNS service that will resolve to proxies for all authorities of the PURLs in the federation. The attached image illustrates and summarizes the proposed architecture.

Caching proxies are inserted between the client and federation members. The dynamic DNS service responds to any request with an IP address of a proxy. The proxy attempts to contact the primary PURL member via its alternative DNS name to fulfill the request and caches the response for future requests. In the case where the primary PURL member is not responsive, the proxy attempts to contact another host in the federation until it succeeds. Thus, most traffic for a given PURL authority continues to flow to the primary PURL member for that authority and not other members of the federation.

I don't know what is planned in this space, and I may not have read the architecture closely enough, but it seems to me that there is now a significant opportunity for OCLC to work with a small number of national libraries (the British Library, The Library of Congress and the National Library of Australia spring to mind as a usefully geographically-dispersed set) to federate the current service at purl.org ?

Comments

[Jerome McDonough]

You mean someone's finally getting around to a real, distributed persistent identification/resolution mechanism? And it only took 15 years....

[Jonathan Rochkind]

Wait, won't the "handle" protocol do this already? Why not just use "handle" instead of continuing to develop Purl to do things handle already does? Is there something I'm missing that Purl does that handle does not? I think handle can do everything purl does, plus what apparently people want purl to do but it doesn't yet (federate), plus a bunch of things purl doesn't want (no problem, don't use them).

[Andy Powell]

@Jerome Well... PURLs have been persistent for all or most of that 15 years. Right?

@Jonathan I might be mis-interpretting you here, but what the Handle system is capable of or not is kinda a moot point here isn't it? The point is, PURLs are heavily used, particularly in the context of Linked Data. They are out there, right now, as http URIs and we can't take them back or easily change them. What we can do (and this is what Zepheira have been doing) is to improve the architecture so that their ongoing persistence is better guaranteed.

Or are you suggesting that we could replace the whole PURL service and replace it with a Handle-based system that was both 'federated' (in the sense used in this PURL work) and that ensured the ongoing resolution of all existing http://purl.org URIs?

Even if you are suggesting that, and even if you are right, I'm not sure I see an appetite for that particular route and, in any case, the federated PURL work already appears to have been done??

[Jeff Young]

I suspect that the OpenURL community already has servers deployed at some of the appropriate nodes. If they could learned to overcome their skepticism of the possibility of identifying concepts in the real world (rather than just describing them in ContextObjects), I think that great things could happen. The skepticism runs deep, though.