"If the best you can do is an external Handle/PURL set-up, then it is better than nothing."
I would say that it's SOMETIMES better than nothing. It depends on what you're doing, what your requirements and goals are. Not every application needs long-term persistence of URLs -- whether through an 'abstraction layer' or not. ('abstraction layer' is just an implementation detail to get long-term persistence of URLs accross systems changes, right? You don't always need something called an 'abstraction layer' to do that). Almost every application does need bookmarkable URLs for the short/medium-term though. If you're sacrificing short-term bookmarkable URLs for long-term-goal persistent but confusing/non-transparent/not-discoverable URLs, that may or may not be a good trade off.
From: Code for Libraries [[log in to unmask]] On Behalf Of Shearer, Timothy J [[log in to unmask]]
Sent: Thursday, January 27, 2011 10:03 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] to link or not to link: PURLs
Thanks Peter (and everyone), that's what I was fishing for. We haven't
yet gone there, and this whole conversation has been very helpful.
On 1/26/11 6:48 PM, "Peter Murray" <[log in to unmask]> wrote:
>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"  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 , then I think it is the best of all worlds.
>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
>> 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 [[log in to unmask]] On Behalf Of
>>Shearer, Timothy J [[log in to unmask]]
>> Sent: Wednesday, January 26, 2011 5:45 PM
>> To: [log in to unmask]
>> 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
>> 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.
>> On 1/26/11 5:09 PM, "Robert Forkel" <[log in to unmask]> 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 :)
>>> On Wed, Jan 26, 2011 at 11:01 PM, Shearer, Timothy J
>>> <[log in to unmask]> wrote:
>>>> Peter, are you opposed to an abstraction layer in principle? My
>>>> of your response is that there's an assumption that there is one
>>>> and that it will work in perpetuity. We are in the unfortunate but I
>>>> think fairly common position of having multiple systems, of aspiring
>>>> 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
>>>> abstraction layer would make those transitions easier on our users,
>>>> the world of linked data in general.
>>>> On 1/26/11 4:51 PM, "Peter Murray" <[log in to unmask]> 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
>>>>>>> text form? And why?
>>>>>>> My feeling is, making the URL an active hyperlink implies
>>>>>>> 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$BNm(B
>>>>>> browser. Then, when users do what they are going to do anyway
>>>>>> 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
>>>>> mint with your digital asset management system.
>Peter Murray [log in to unmask] 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/