So that will teach me to post a moderately controversial opinion, then leave to take the kids out for a pizza dinner.
I agree with what has been said so far, an in particular with Jonathan's latest e-mail below. Abstraction layers are good. Hiding abstraction layers from users is even better. If the best you can do is an external Handle/PURL set-up, then it is better than nothing. If you have some control and institutional commitment to a URL space -- creating "cool URIs" [1] to your content, if you will -- then by all means do that. If you can also attempt to future-proof your URL space with something like ARKs [2], then I think it is the best of all worlds. [1] http://www.w3.org/Provider/Style/URI [2] https://confluence.ucop.edu/display/Curation/ARK Peter On Jan 26, 2011, at 6:23 PM, Jonathan Rochkind wrote: > > What some in this thread are frowning on is having an "abstraction layer" > such that the persistent URL for your web page or resource is not the URL > that typical users see in their browser location bar when viewing that > resource or web page. > > If your abstraction layer can make that so, then I don't think anyone in this > thread would frown upon it. > > If your abstraction layer can't make that so... then I personally still agree > it's sometimes an appropriate solution, the best trade-off, an acceptable > evil. > > But it's worth spending some time thinking about if you can set it up to do > that instead. > > Some shops have more technical capacity than others. If you are at a shop > that can't even do their own apache install, then you are pretty much at the > bottom of 'technical capacity' (which isn't an insult, that's where some > people are), there isn't much of anything you can do, and you should be > telling your vendors that you want them to provide you with software that > does it right. That's pretty much all you can do. But STILL requires you to > have enough understanding to tell the vendor what 'right' is and know if > they've done it or not. If you can't even do that... well, you'll get what > you get, so it goes. > > ________________________________________ > From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Shearer, > Timothy J [tshea...@email.unc.edu] > Sent: Wednesday, January 26, 2011 5:45 PM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] to link or not to link: PURLs > > Right, they are not the same, which is why I wondered if there was > opposition to an abstraction layer in principle. > > A major problem for institutions who cannot afford to build is that they > license systems. Licensed systems are often less than ideal. > > When an institution is in that scenario it either doesn't have the > resources to tweak the system or the system is so closed as to be > un-tweakable (or both). > > So your options, unless I'm missing something, are to stick with the bad > urls your system provides, or to invest in an abstraction layer. > > I realize that the abstraction layer doesn't solve many of the problems > (SEO, harvested indexes, user's re-use from the object they are looking > at), but it does seem to solve some problems. Published urls (say in > Worldcat, Open Library, and elsewhere). Taking advantage of linked data > locally when you do have resources (e.g, an enhancing interface that > extends functionality, or a preservation layer where a persistent > identifier in the form of links would be handy). > > mod_rewrite assumes Apache, and that you may configure it. > > So I'm wondering if an abstraction layer is frowned upon in principle (as > opposed to specific dislike or PURLS or handles). > > And, even if it's not ideal, whether it still presents utility, even in > less than ideal implementations. > > -t > > > On 1/26/11 5:09 PM, "Robert Forkel" <xrotw...@googlemail.com> wrote: > >> as far as i can see, dislike of handles and PURLs doesn't mean >> commitment to one system which will work in perpetuity, but only >> commitment to own one domain in perpetuity. once you commit to that >> you may create an abstraction/redirection layer with mod_rewrite :) >> regards, >> robert >> >> On Wed, Jan 26, 2011 at 11:01 PM, Shearer, Timothy J >> <tshea...@email.unc.edu> wrote: >>> Peter, are you opposed to an abstraction layer in principle? My reading >>> of your response is that there's an assumption that there is one >>> "system" >>> and that it will work in perpetuity. We are in the unfortunate but I >>> think fairly common position of having multiple systems, of aspiring to >>> pare that down, and fully expectant that we'll need to migrate at some >>> point even if we find perfection in the near to mid term. Having a link >>> abstraction layer would make those transitions easier on our users, and >>> on >>> the world of linked data in general. >>> >>> Tim >>> >>> >>> On 1/26/11 4:51 PM, "Peter Murray" <peter.mur...@lyrasis.org> wrote: >>> >>>> On Jan 26, 2011, at 3:24 PM, Erik Hetzner wrote: >>>>> >>>>> At Wed, 26 Jan 2011 13:57:42 -0600, >>>>> Pottinger, Hardy J. wrote: >>>>>> >>>>>> Hi, this topic has come up for discussion with some of my >>>>>> colleagues, and I was hoping to get a few other perspectives. For a >>>>>> public interface to a repository and/or digital library, would you >>>>>> make the handle/PURL an active hyperlink, or just provide the URL in >>>>>> text form? And why? >>>>>> >>>>>> My feeling is, making the URL an active hyperlink implies confidence >>>>>> in the PURL/Handle, and provides the user with functionality they >>>>>> expect of a hyperlink (right or option-click to copy, or bookmark). >>>>> >>>>> A permanent URL should be displayed in the address bar of the user零 >>>>> browser. Then, when users do what they are going to do anyway (select >>>>> the link in the address bar & copy it), it will work. >>>> >>>> ...which is why I intensely dislike Handles and PURLs. Man-up >>>> (person-up? byte-up?) and make a long-term commitment to own the URLs >>>> you >>>> mint with your digital asset management system. -- Peter Murray peter.mur...@lyrasis.org tel:+1-678-235-2955 Ass't Director, Technology Services Development http://dltj.org/about/ Lyrasis -- Great Libraries. Strong Communities. Innovative Answers. The Disruptive Library Technology Jester http://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
