 |
 |
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 contexts where we know this is sensible behaviour). 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? I certainly wouldn't assume that even given a http URI in the rft_id that was a URL for the resource it would be the best place to resolve for our users (similar to the situation of having a DOI supplied in rft_id - this may help, but locally access may be via an aggregator etc.) What I'm actually suggesting (I think) is we strictly treat an http URI in the rft_id field as a URI, initially ignoring the fact that it may be a URL. We would (as Nate said) use the URI as a key to identify the destination URL - although in some cases that could end up being the original URI (i.e. if the lookup service had nothing to say about it) 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? I have some sympathy with the point that Jonathan makes about avoiding the use of 'library specific' standards, it feels like this is one of those situations where it is appropriate - but if there are suggestions of more general methods that achieve the same outcomes I'd be interested. As an aside, one other advantage of using OpenURL in this context does deliver consistency of approach across all our references - but perhaps this isn't a good enough reason to adopt it if there are good alternatives. Owen ________________________________________ From: Code for Libraries [[log in to unmask]] On Behalf Of Eric Hellman [[log in to unmask]] Sent: 14 September 2009 19:52 To: [log in to unmask] Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources 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 documentation and > according to > it it has no use. > > On Mon, Sep 14, 2009 at 1:55 PM, Eric Hellman <[log in to unmask]> > 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 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 [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 has no use. >>> this >>> might >>> be a good one for it. >>> >>> just my 2 cents. >>> Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA [log in to unmask] 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).