Please excuse the cross-posting
Web Services Librarian
The University of Miami Libraries seeks a creative, innovative individual to
provide leadership in the content, technology and effective user interfaces of
the Libraries web presence and promotes user-centered resources, digital
services,
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.
Because we can manipulate how we resolve the OpenURL if we want to and redirect
the user to an alternative location if we know the resource has moved from the
original URL. OK, the BBC homepage is not likely to move, but many other pages
are less stable of course.
Owen
Owen Stephens
TELSTAR
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
Dear all,
Apologies for cross-posting.
This year’s International Conference on Dublin Core and Metadata
Applications (DC 2009) is a month away. The theme of DC 2009 is Semantic
Interoperability of Linked Data. The conference will be held on 12-16
October 2009 in Seoul, Korea.
Participants are
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
Thanks for all the responses so far. I'm not at my desk right now, but some
quick responses...
I'm not suggesting that we should necessarily assume that a http URI in the
rft_id would resolve to the resource - but that this is a possibility (if we
want, we can restrict behaviour to rfr
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',
36 matches
Mail list logo
