"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.

-t

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" [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 [[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
>>(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" <[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 :)
>>> regards,
>>> robert
>>>
>>> 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
>>>>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" <[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
>>>>>>>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         [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/
>Attrib-Noncomm-Share   http://creativecommons.org/licenses/by-nc-sa/2.5/