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
I guess 'unambiguous' isn't exactly the same thing as 'unique',
depending on what you mean by 'unique', okay. But it's pretty clear to
me that rft_id is meant to be an identifier for the referent. Meaning
the same rft_id should not correspond to two different referents. (But
the same referent can certainly have multiple rft_id's, although it's
inconvenient when it has multiple ones within the same scheme/system, it
happens and is not disastrous).
Rosalyn Metz wrote:
> 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, 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
>> 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
>> [log in to unmask]