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 <[log in to unmask]> 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 <[log in to unmask]> 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
>>
>> [log in to unmask]
>> http://go-to-hellman.blogspot.com/
>>
>