You might find the WebCite service [1] to be of some use.
Thanks - I'll have a look (although obviously Mike's experience is worrying)
Of course it cannot work retroactively, so it is best if
researchers use it in the first place.
It seems the number of our authors/researchers using
: [CODE4LIB] Implementing OpenURL for simple web resources
Hi Owen, all:
This is a very interesting problem.
At Tue, 15 Sep 2009 10:04:09 +0100,
O.Stephens wrote:
[...]
If we look at a website it is pretty difficult to reference
it without
including the URL - it seems to be the only
At Wed, 16 Sep 2009 13:39:42 +0100,
O.Stephens wrote:
Thanks Erik,
Yes - generally references to web sites require a 'route of access'
(i.e. URL) and 'date accessed' - because, of course, the content of
the website may change over time.
Strictly you are right - if you are going to link to
True. How, from the OpenURL, are you going to know that the rft is meant
to represent a website?
I guess that was part of my question. But no one has suggested defining a new
metadata profile for websites (which I probably would avoid tbh). DC doesn't
seem to offer a nice way of doing this (that
...@open.ac.uk
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On
Behalf Of Rosalyn Metz
Sent: 14 September 2009 21:52
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
oops...just re-read original post s
858701
F: +44 (0) 1908 653571
E: o.steph...@open.ac.uk
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On
Behalf Of Rosalyn Metz
Sent: 14 September 2009 21:52
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On
Behalf Of Rosalyn Metz
Sent: 15 September 2009 14:42
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
you could force a timestamp if people don't include
Owen, I might have missed it in this message -- my eyes are starting
glaze over at this point in the thread, but can you describe how the
input of these resources would work?
What I'm basically asking is -- what would the professor need to do to
add a new: citation for a 70 year old book;
) 1908 653571
E: o.steph...@open.ac.uk
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On
Behalf Of Ross Singer
Sent: 15 September 2009 15:56
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
Owen, I
A suggestion on how to get a prof to enter a url.
I use this bookmarklet to add a URL to Hacker News:
javascript:window.location=%22http://news.ycombinator.com/submitlink?u=%22+encodeURIComponent(document.location)+%22t=%22+encodeURIComponent(document.title)
I'm tempted to suggest an api
O.Stephens wrote:
True. How, from the OpenURL, are you going to know that the rft is meant
to represent a website?
I guess that was part of my question. But no one has suggested defining a new
metadata profile for websites (which I probably would avoid tbh). DC doesn't
seem to offer a
September 2009 14:42
To: CODE4LIB@LISTSERV.ND.EDU
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
O.Stephens wrote:
Thanks Rosalyn,
As you say we could push a custom value into rfr_genre. I'm a bit torn on this,
as I guess I'm trying to do something that isn't 'hacky' - or at least not from
the OpenURL end of it. It might be that this is just wishful thinking, and that
I'm just trying to
] On
Behalf Of Jonathan Rochkind
Sent: 15 September 2009 16:30
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
Wait, are you really going to try to do this with _SFX_ too?
I missed
that part. Oh boy. Seriously, I think you are in for a world
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On
Behalf Of Ross Singer
Sent: 15 September 2009 15:56
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
Owen, I might have missed it in this message
: Code for Libraries [mailto:code4...@listserv.nd.edu] On
Behalf Of Ross Singer
Sent: 15 September 2009 15:56
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
Owen, I might have missed it in this message -- my eyes are
starting glaze over
Of Jonathan Rochkind
Sent: 15 September 2009 16:52
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
I do like Ross's solution, if you really wanna use OpenURL.
I'm much more comfortable with the idea of including a URI
based on your own local
I think using locally meaningful ids in rft_id is a misuse and a
mistake. locally meaningful data should goi in rft_dat, accompanied by
rfr_id
just sayin'
On Sep 15, 2009, at 11:52 AM, Jonathan Rochkind wrote:
I do like Ross's solution, if you really wanna use OpenURL. I'm much
more
Yes, you can.
On Sep 15, 2009, at 11:41 AM, Ross Singer wrote:
I can't remember if you can include both metadata-by-reference keys
and metadata-by-value, but you could have by-reference
(rft_ref=http://telstar.open.ac.uk/1234rft_ref_fmt=RIS or something)
point at your citation db to return a
On Tue, Sep 15, 2009 at 12:06 PM, Eric Hellman e...@hellman.net wrote:
Yes, you can.
In this case, I say punt on dc.identifier, throw the URL in rft_id
(since, Eric, you had some concern regarding using the local id for
this?) and let the real URL persistence/resolution work happen with
the
Hi Owen, all:
This is a very interesting problem.
At Tue, 15 Sep 2009 10:04:09 +0100,
O.Stephens wrote:
[…]
If we look at a website it is pretty difficult to reference it
without including the URL - it seems to be the only good way of
describing what you are actually talking about (how many
The process by which a URI comes to identify something other than the
stuff you get by resolving it can be mysterious- I've blogged about a
bit: http://go-to-hellman.blogspot.com/2009/07/illusion-of-internet-identity.html
In the case of worldcat or google, it's fame. If you think a URI
IIRC you can also elide url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx as that
is the default.
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
2009/9/14 O.Stephens o.steph...@open.ac.uk:
However, we also want to use OpenURL even where the reference is to a more
straightforward web resource - e.g. a web page such as http://www.bbc.co.uk.
This is in order to ensure that links provided in the course material are
persistent over time.
Sent: 14 September 2009 15:06
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
2009/9/14 O.Stephens o.steph...@open.ac.uk:
However, we also want to use OpenURL even where the
reference is to a more straightforward web resource - e.g. a
web page
Could you give us examples of http urls in rft_id that are like that?
I've never seen such.
On Sep 14, 2009, at 11:58 AM, Jonathan Rochkind wrote:
In general, identifiers in URI form are put in rft_id that are NOT
meant for providing to the user as a navigable URL. So the
receiving
At Mon, 14 Sep 2009 14:48:23 +0100,
O.Stephens wrote:
I'm working on a project called TELSTAR (based at the Open
University in the UK) which is looking at the integration of
resources into an online learning environment (see
http://www.open.ac.uk/telstar for the basic project details). The
Most link resolvers aren't going to know what to do with that -- they
aren't going to know that that OpenURL is meant to represent a web page,
and that the URL in rft_id should be provided to the user.
In general, identifiers in URI form are put in rft_id that are NOT meant
for providing to
Well, in the 'wild' I barely see any rft_id's at all, heh. Aside from
the obvious non-http URIs in rft_id, I'm not sure if I've seen http URIs
that don't resolve to full text. BUT -- you can do anything with an
http URI that you can do with an info uri. There is no requirement or
guarantee
As I'm sure you're aware, the OpenURL spec only talks about providing
services, and resolving to full text is only one of many possible
services. If *all* you know about a referent is the url, then
redirecting the user to the url is going to be the best you can do in
almost all cases. In
ok no one shoot me for doing this:
in section 9.1 Namespaces [Registry] of the OpenURL standard (z39.88) it
actually provides an example of using a URL in the rfr_id field, and i
wonder why you couldn't just do the same thing for the rft_id
also there is a field called rft_val which currently
Eric Hellman wrote:
http://catalog.library.jhu.edu/bib/NUM identifies a catalog record- I
mean what else would you use to id the catalog record. unless you've
implemented the http-range 303 redirect recommendation in your catalog
(http://www.w3.org/TR/cooluris/), it shouldn't be construed
On Mon, Sep 14, 2009 at 8:48 AM, O.Stephens o.steph...@open.ac.uk wrote:
What we are considering is the best way to represent a web page (or similar -
pdf etc.) in an OpenURL. It looks like we could do something as simple as:
http://resolver.address/?
url_ver=Z39.88-2004
It's not correct to say that rft_val has no use; when used, it should
contain a URL-encoded package of xml or kev metadata. it would be
correct to say it is very rarely used.
On Sep 14, 2009, at 1:40 PM, Rosalyn Metz wrote:
ok no one shoot me for doing this:
in section 9.1 Namespaces
Huh, I can't even FIND a section 9.1 in the z39.88 standard. Are we
looking at the same z39.88 standard? Mine only goes up to chapter 4. Oh
wait, there it is in Chapter 3, section 9.1 okay.
While that example contains an http URI, I would say it's intended as an
unambiguous identifier URI
Yes, what Nate said is what I'm trying to say.
Nate, they aren't _trying_ to use the target URL as a uniquely
identifying key. They're _trying_ to use it as... a target URL! They
just can't find anywhere but rft_id to stick a target URL.
But the problem with that is exactly what Nate
If you have a URL that can be used for a resource that you are
describing in metadata, resolvers can do a better job providing
services to users if it is put in the openurl. The only place to put
it is rft_id. So let's not let one resolver's incapacity to prevent
other resolvers from
sorry eric, i was reading straight from the documentation and according to
it it has no use.
On Mon, Sep 14, 2009 at 1:55 PM, Eric Hellman e...@hellman.net wrote:
It's not correct to say that rft_val has no use; when used, it should
contain a URL-encoded package of xml or kev metadata. it
What the spec for z39.88 says is that rfr_id (and all the other _id's)
must be URIs.
the info:sid samespace was defined to allow minting of identifiers for
the specific purpose of identifying referrers. the info uri was
defined to allow non-resolving identifiers to have a place to live
I disagree. Putting URIs that unamiguously identify the referent, and
in some cases provide additional 'hooks' by virtue of additional
identifiers (local bibID, OCLCnum, LCCN, etc) is a VERY useful thing to
do to me. Whether or not they resolve to an end-user appropriate web
page or not.
i'd like to point out that perhaps the reason that SFX (and other link
resolvers) don't use the rft_id in a particular way is because no one
has pushed it to. for example, it is possible for you to have the
word dinosaur link to an openurl and provide services for dinosaurs,
but the question is:
whoopsthat should be rfr_id not rft_id.
http://resolver.address/?
url_ver=Z39.88-2004
url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx
rfr_id=mylocalid
rft_dat=urlhttp://www.bbc.co.uk/url
On Mon, Sep 14, 2009 at 2:39 PM, Rosalyn Metz rosalynm...@gmail.com wrote:
i'd like to point out that
You're absolutely correct, in fact, all the ent_val fields are
reserved for future use! They went in and out of the spec. I'm trying
to remember from my notes. It's better that they're out.
On Sep 14, 2009, at 2:05 PM, Rosalyn Metz wrote:
sorry eric, i was reading straight from the
2009/9/14 Jonathan Rochkind rochk...@jhu.edu:
Seriously, don't use OpenURL unless you really can't find anything else that
will do, or you actually want your OpenURLs to be used by the existing 'in
the wild' OpenURL resolvers. In the latter case, don't count on them doing
anything in
It's not dead in the sense that it is not in use -- it is, in wide
use. It is dead in the sense that, in my opinion, it is not going to
evolve or change. It is highly unlikely that the majority of 'in the
wild' OpenURL link resolvers or generators (referrers) are going to do
anything with
On Mon, 14 Sep 2009, Mike Taylor wrote:
2009/9/14 Jonathan Rochkind rochk...@jhu.edu:
Seriously, don't use OpenURL unless you really can't find anything else that
will do, or you actually want your OpenURLs to be used by the existing 'in
the wild' OpenURL resolvers. In the latter case, don't
I can't imagine that SFX has some fundamental assumption that an http
URL in rft_id is never ever something that can be used for access, and
even if it did, it would be letting the tail wag the dog to suggest
that other resolvers should not do so; some do.
There are also resolvers that
Yep, that's a pretty good summary of my personal advice Joe, thanks.
Obviously others like Eric may have other opinions, that's just mine.
Joe Hourcle wrote:
On Mon, 14 Sep 2009, Mike Taylor wrote:
2009/9/14 Jonathan Rochkind rochk...@jhu.edu:
Seriously, don't use OpenURL unless you
Of course it's possible. But if you're counting on all (or a majority)
of actually in-the-wild resolvers to do a certain thing, you should
probably do some investigation to see if that assumption is true. Some
probably do some probably don't. If the usefulness of your technique
depends on
From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of Eric Hellman
[e...@hellman.net]
Sent: 14 September 2009 19:52
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
You're absolutely correct, in fact, all
O.Stephens wrote:
I guess it is part of the reason that I'm asking the question, as if we also
know that the rft was a website, it would be very odd behaviour (I think) to
use an http URI in the rft_id that wasn't the website URL?
True. How, from the OpenURL, are you going to know that the
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.
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
On Mon, 14 Sep 2009, Eric Hellman wrote:
The original question was whether it's a good idea to use OpenURL for a URL
persistence application.
Issues with using PURL are that
1. it only works with one website- PURL paths don't travel, though there have
been proposals to get around this.
2.
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
I still think that rft_id IS meant to be a unique identifier! Again,
5.2.1 of z3988 says of the *_id fields:
An Identifier Descriptor unambiguously specifies the Entity by means of
a Uniform Resource Identifier
(URI).
I guess 'unambiguous' isn't exactly the same thing as 'unique',
56 matches
Mail list logo
