-----Original Message-----
From: Code for Libraries [mailto:[email protected]] On
Behalf Of Rosalyn Metz
Sent: 15 September 2009 14:42
To: [email protected]
Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
you could force a timestamp if people don't include a date.
and I like the idea of going to the Internet Archive of a
website, because then you're not having to get into the
business of handling www.bbc.co.uk differently than cnn.com
and someblog.org.
i also like the idea of using a redirect. you could
theoretically write a source parser (i'm assuming youre using
SFX based on what you said about bX) that says if my rfr_id =
mylocalid and the item is a website (however you choose to
identify the website...which if you're writing your own
source parser you could put website in the rft_genre even
though its not technically a metadata format but you just
want your source parser to forward the url on anyway, so the
link resolver isn't actually going to do anything with it)
bypass everything and just direct to the internet archive of
the website.
all of this is of course kind of hackish...but really isn't
the whole thing hackish? there were a few source parsers
that would be good models for writing something like this.
but i have no idea if they still exist because i haven't
looked at the back end of sfx in about a year.
On Tue, Sep 15, 2009 at 5:12 AM, O.Stephens
<[email protected]> wrote:
I agree with this Rosalyn. The issue that Nate brought up
was that the content at http://www.bbc.co.uk could change
over time, and old content might be moved to another URI -
http://archive.bbc.co.uk or something. So if course A
references http://www.bbc.co.uk on 24/08/09, if the content
that was on http://www.bbc.co.uk on 24/08/09 moves to
http://archive.bbc.co.uk we can use the mechanism I propose
to trap the links to http://www.bbc.co.uk and redirect to
http://archive.bbc.co.uk. However, if at a later date course
B references http://www.bbc.co.uk we have no way of knowing
whether they mean the stuff that is currently on
http://www.bbc.co.uk or the stuff that used to be on
http://www.bbc.co.uk and is now on http://archive.bbc.co.uk -
and we have a redirect that is being applied across the board.
Thinking about it, references are required to include a
date of access when citing websites, so this is probably the
best piece of information to use to know where to resolve to
(and we can put this in the DC metadata). Whether this will
just get too confusing is a good question - I'll have at
think about this.
Owen
PS using the date we could even consider resolving to the
Internet Archive copy of a website if it was available I
guess - this might be useful I guess...
Owen Stephens
TELSTAR Project Manager
Library and Learning Resources Centre
The Open University
Walton Hall
Milton Keynes, MK7 6AA
T: +44 (0) 1908 858701
F: +44 (0) 1908 653571
E: [email protected]
-----Original Message-----
From: Code for Libraries [mailto:[email protected]]
On Behalf
Of Rosalyn Metz
Sent: 14 September 2009 21:52
To: [email protected]
Subject: Re: [CODE4LIB] Implementing OpenURL for simple
web resources
oops...just re-read original post s/professor/article
also your link resolver should be creating a context
object with each
request. this context object is what makes the openurl
unique. so
if you want uniqueness for stats purposes i would image the link
resolver is already doing that (and just another reason to use an
rfr_id that you create).
On Mon, Sep 14, 2009 at 4:45 PM, Rosalyn Metz
<[email protected]>
wrote:
Owen,
rft_id isn't really meant to be a unique identifier
(although it can
be in situations like a pmid or doi). are you looking
for it to be?
if so why?
if professor A is pointing to http://www.bbc.co.uk and
professor B is
pointing to http://www.bbc.co.uk why do they have to have unique
OpenURLs.
Rosalyn
On Mon, Sep 14, 2009 at 4:41 PM, Eric Hellman
<[email protected]> wrote:
Nate's point is what I was thinking about in this comment in my
original
reply:
If you don't add DC metadata, which seems like a good
idea, you'll
definitely want to include something that will help you
to persist
your replacement record. For example, a label or
description for the link.
I should also point out a solution that could work for
some people
but not
you- put rewrite rules in the gateways serving your
network. A bit
dangerous and kludgy, but we've seen kludgier things.
On Sep 14, 2009, at 4:24 PM, O.Stephens wrote:
Nate has a point here - what if we end up with a commonly
used URI
pointing at a variety of different things over time, and
so is used
to indicate different content each time. However the
problem with a 'short URL'
solution (tr.im, purl etc), or indeed any locally assigned
identifier that acts as a key, is that as described in
the blog post
you need prior knowledge of the short URL/identifier to
use it. The
only 'identifier' our authors know for a website is it's
URL - and
it seems contrary for us to ask them to use something
else. I'll
need to think about Nate's point - is this common or an
edge case? Is there any other approach we could take?
Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA
[email protected]
http://go-to-hellman.blogspot.com/
The Open University is incorporated by Royal Charter (RC
000391), an exempt charity in England & Wales and a charity
registered in Scotland (SC 038302).
