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 peter.mur...@lyrasis.org 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 [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
Re: [CODE4LIB] to link or not to link: PURLs
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 [CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Shearer,
Timothy J [tshea...@email.unc.edu]
Sent: Thursday, January 27, 2011 10:03 AM
To: CODE4LIB@LISTSERV.ND.EDU
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 peter.mur...@lyrasis.org 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 [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
Re: [CODE4LIB] to link or not to link: PURLs
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.
Agreed. The operative phrase here is trade off as these inevitably come
into play when choices are made.
With very few exceptions, it's not realistic to believe that conceptual
problems can be solved outright. Consequently, solutions based on the notion
that they can inevitably ignore the costs associated with those paths.
A URL is already an abstraction, as is a domain name, as is a file system.
The question for any addressing issue is what level of abstraction is most
appropriate for the task at hand.
kyle
Re: [CODE4LIB] to link or not to link: PURLs
2011/1/27 Jonathan Rochkind rochk...@jhu.edu:
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.
I *think* this may be pertinent, but it may also be a tangent.
For the DLG[1] and CRDL[2], we make use of what for
lack of a better term I refer to as the DLG handle service.
It's internal to our shop, but external to the collections it
serves, and is my attempt to be able to provide bookmarks
to items that may have been retrieved via non-bookmarkable
urls.
Both DLG and CRDL are aggregators of both local and
state-wide/nation-wide collections. So the handle service
maintains a concept of repository (the owner of the collection),
collection, and item. Each of these has an ID, e.g., the
ID for the repo Digital Library of Georgia is 'dlg', for the coll
Vanishing Georgia is 'vang', for the item Photograph of Lillian
Carter, Plains, Sumter County, Georgia, 1976 is 'sum150'.
The item's bookmark then (with some handwaving about the
repo id) is:
http://dlg.galileo.usg.edu/vang/id:sum150
Other examples:
A persistent url for a query in DLG:
http://dlg.galileo.usg.edu/query:bush
Item records *in the aggregator database* of DLG:
http://dlg.galileo.usg.edu/id:dlg_bald_am-451
http://dlg.galileo.usg.edu/id:dlg_vang_sum150
Item records in the collections' sites:
http://dlg.galileo.usg.edu/bald/id:am-451
http://dlg.galileo.usg.edu/vang/id:sum150
And similar examples from CRDL:
http://crdl.usg.edu/query:bush
http://crdl.usg.edu/id:lbj_timeline
http://crdl.usg.edu/id:dlg_bald_am-1259
http://crdl.usg.edu/id:wsu_wsuboh_jacktanner
To get to the point, when we display an item (in the
interfaces that we control ourselves) we include in
the item display a Bookmark url that is one of these
handles. For example, the actual url for the last item
above looks something like this:
http://crdl.usg.edu/cgi/crdl?action=retrieve;rset=001;recno=4
That's clearly not bookmarkable outside of the existing
browser session, so in the item display, we have this
line:
Bookmark: http://crdl.usg.edu/id:wsu_wsuboh_jacktanner
In that line, the URL *is* clickable.
I realize that this handle strategy flies in the face of
opacity, since the handle contains indicators of
ownership. I guess I'm just not in that camp, at least
not for these collections.
Again, I'm not sure the above is really a useful response
to the original query, but it came to mind, so I thought
I'd toss it in.
Regards,
Brad
[1] http://dlg.galileo.usg.edu/
[2] http://crdl.usg.edu/
Re: [CODE4LIB] to link or not to link: PURLs
Hi, this has been a really interesting and informative discussion. I wonder if I might be able to redirect it a bit back to my original question, with the understanding that, as the discussion has made clear, a PURL or Handle is not an ideal solution? If, for the sake of argument, you are dealing with software which provides permanent URLs (say, for example, DSpace's out-of-the-box use of the Handle system), would it be desirable to make these persistent links actual hyperlinks, when they are presented to the user? Here's my take on it: 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). :-) Just to be clear, I think this is a good thing, and is a compelling argument for making PURLs/Handles active links. Thoughts? -- HARDY POTTINGER pottinge...@umsystem.edu University of Missouri Library Systems http://lso.umsystem.edu/~pottingerhj/ No matter how far down the wrong road you've gone, turn back. --Turkish proverb
Re: [CODE4LIB] to link or not to link: PURLs
On Thu, Jan 27, 2011 at 12:05 PM, Pottinger, Hardy J. pottinge...@umsystem.edu wrote: If, for the sake of argument, you are dealing with software which provides permanent URLs (say, for example, DSpace's out-of-the-box use of the Handle system), would it be desirable to make these persistent links actual hyperlinks, when they are presented to the user? Yes. -- Brad
Re: [CODE4LIB] to link or not to link: PURLs
If you don't have any confidence in the URL, then why would you bother giving it out at all? Links are links. Make them active. On Wed, Jan 26, 2011 at 14:57, Pottinger, Hardy J. pottinge...@umsystem.edu 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). Thanks for your input. -- HARDY POTTINGER pottinge...@umsystem.edu University of Missouri Library Systems http://lso.umsystem.edu/~pottingerhj/http://lso.umsystem.edu/%7Epottingerhj/ No matter how far down the wrong road you've gone, turn back. --Turkish proverb
Re: [CODE4LIB] to link or not to link: PURLs
If you don't have any confidence in the URL, then why would you bother giving it out at all? Links are links. Make them active. Hi, David, I agree. And thanks! 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). :-) Just to be clear, I think this is a good thing, and is a compelling argument for making PURLs/Handles active links. Any other takers? --Hardy
Re: [CODE4LIB] to link or not to link: PURLs
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’s browser. Then, when users do what they are going to do anyway (select the link in the address bar copy it), it will work. best, Erik Hetzner Sent from my free software system http://fsf.org/. pgp80PT94Qhgm.pgp Description: PGP signature
Re: [CODE4LIB] to link or not to link: PURLs
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’s 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 -- Peter Murray peter.mur...@lyrasis.orgtel:+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 Jesterhttp://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
Re: [CODE4LIB] to link or not to link: PURLs
+1 for eric and peter. A resource's URL has to be the one in the location bar. That's the one the delicious bookmarklet will grab, etc. On Wed, Jan 26, 2011 at 10: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’s 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 -- 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/
Re: [CODE4LIB] to link or not to link: PURLs
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¹s 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 -- Peter Murray peter.mur...@lyrasis.orgtel:+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 Jesterhttp://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
Re: [CODE4LIB] to link or not to link: PURLs
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 -- 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/
Re: [CODE4LIB] to link or not to link: PURLs
Seems like your link abstraction layer should be baked into your system, so the URL your users see in the location bar IS the one that your link abstraction layer is handling and you are committing to persisting. There's no reason a URL has to begin with 'purl.org' to be part of a persisting abstraction layer, neccesarily. If your URL is http://myapp.myuniversity.edu/record/12345, then you can change systems all you want, the new system just still needs to be addressable at that URI, and still needs to know what /record/12345 is. But yeah, we've often got to deal with software written by other people that doesn't do that. On 1/26/2011 5:01 PM, Shearer, Timothy J 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 Murraypeter.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¹s 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 -- Peter Murray peter.mur...@lyrasis.orgtel:+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 Jesterhttp://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
Re: [CODE4LIB] to link or not to link: PURLs
At Wed, 26 Jan 2011 17:01:05 -0500, Jonathan Rochkind wrote: It's sometimes not feasible/possible though. But it is unfortunate, and I agree you should always just do that where possible. I wonder if Google's use of the link rel=canonical element has been catching on with any other tools? Will any browses, delicious extensions, etc., bookmark that, or offer the option to bookmark that, or anything, instead of the one in the address bar? The W3C WWW Technical Architecture Group has some interest in making 302 found redirects work as they were supposed to in browsers [1], but there is not a lot of movement there, as far as I know. In the meantime I believe that we should strive in all cases to ensure that the URL in the address bar is the permanent URL. best, Erik 1. http://www.w3.org/QA/2010/04/why_does_the_address_bar_show.html Sent from my free software system http://fsf.org/. pgpTc0ywBEOv1.pgp Description: PGP signature
Re: [CODE4LIB] to link or not to link: PURLs
On Wed, Jan 26, 2011 at 5:11 PM, Jonathan Rochkind rochk...@jhu.edu wrote: Seems like your link abstraction layer should be baked into your system, so the URL your users see in the location bar IS the one that your link abstraction layer is handling and you are committing to persisting. Which I think is what UNT does(?) An example of how to do it? http://digital.library.unt.edu/ark:/67531/metapth60974/ Kevin
Re: [CODE4LIB] to link or not to link: PURLs
Yep,using a globally unique identifier like an ARK is better than my /records/12345 example,that's a better way to do it for sure. So in that example, http://digital.library.unt.edu/ark:/67531/metapth60974/ is what you access, http://digital.library.unt.edu/ark:/67531/metapth60974/ is what you see in your browser location bar, and they can switch software systems all they want, as long as the new system lives at http://digital.library.unt.edu, and can take an ARK and give you your think -- without a redirect. [One way to do that on top of a system that doens't otherwise care about it would be to use apache reverse proxy -- so long as the system has SOME url template with a slot for an ARK. Although the system has to care enough to _generate_ the right URLs in links too, I guess, but that sometimes just requiers changing at a view/template layer, that may be easier to change than the actual controller/URL parsing/handling layer. ]. On 1/26/2011 5:27 PM, Kevin S. Clarke wrote: On Wed, Jan 26, 2011 at 5:11 PM, Jonathan Rochkindrochk...@jhu.edu wrote: Seems like your link abstraction layer should be baked into your system, so the URL your users see in the location bar IS the one that your link abstraction layer is handling and you are committing to persisting. Which I think is what UNT does(?) An example of how to do it? http://digital.library.unt.edu/ark:/67531/metapth60974/ Kevin
Re: [CODE4LIB] to link or not to link: PURLs
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 -- Peter Murray peter.mur...@lyrasis.orgtel:+1-678-235-2955 Ass't Director, Technology Services
Re: [CODE4LIB] to link or not to link: PURLs
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
Re: [CODE4LIB] to link or not to link: PURLs
What a timely discussion. In the morning, Montana State Library will be attempting to answer the question: do we need to continue making permanent URLs to access our state pubs collection? It's not clear to me what the handiness of permanent URLs is. Just tried a PURL from our Montana state pubs collection. What appears in the address bar for bookmarking when the resource is access is NOT the PURL id but the target URL at the Internet Archive? According to a recent post here on a similar topic, John Kunze, the creative developer of ARKs, said for permanency to take place, one needs a reserve access repository in place. So, we set up and maintain PURLS at purl.org for a long-term horizon say 50 years. We setup a reserve repository. We create a bridge table for redirecting our targets from IA to the reserve repository when we need it. If we need the reserve targets, we modify the PURLS at purl.org. It takes two days, which is OK for legacy state publication because the current ones are still online. Are we are good to go for fifty years from now when a move is needed? In the meantime, the reserve repository fails, or purl.org fails, or nothing fails, but URL technology changes or repository technology changes. What we actually need 50 years from now is nothing like we have set up to help us make the transition to reserve repository. So, maintenance of permanency is more than creating permanent URLs, it means keeping up with 50 years of obsolescence. Why not tend to the links in our catalog. Plan in a detailed way to shift to a reserve repository understanding the target links required. Change this plan every time obsolescence rears its ugly head. When the plan is needed, do it. If there are still URLs, generate the new target list and the bridge table from current records if there is still such a thing. Overlay the records and be good to go with whatever actually is needed at the time its need? Say it take 30 days to do this. This would probably be OK for state publications. In the meantime, save time and money creating and maintaining permanent URLs that will be obsolete when we need them. What am I missing?
