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
can be usable outside your institution for identification purposes,
and your institution can maintain some sort of identification
machinery as long as the OpenURL is expected to be useful, then it's
fine to use it in rft_id. If you intend the uri to connote identity it
only in the context that you're building urls for, then use rft_dat
which is there for exactly that purpose.
On Sep 15, 2009, at 12:17 PM, Jonathan Rochkind wrote:
> If it's a URI that is indeed an identifier that "unambiguously
> identifies the referent", as the standard says... I don't see how
> that's inappropriate in rft_id. Isn't that what it's for?
>
> I mentioned before that I put things like http://catalog.library.jhu.edu/bib/1234
> in my rft_ids. Putting http://somewhere.edu/our-purl-server/1234
> in rft_id seems very analogous to me. Both seem appropriate.
>
> I'm not sure what makes a URI "locally meaningful" or not. What
> makes http://www.worldcat.org/bibID or http://books.google.com/book?id=foo
> "globally meaningful" but http://catalog.library.jhu.edu/bib/1234
> or http://somewhere.edu/our-purl-server/1234 "locally meaningful"?
> If it's a URI that is reasonably persistent and unambiguously
> identifies the referent, then it's an identifier and is appropriate
> for rft_id, says me.
>
> Jonathan
>
> Eric Hellman wrote:
>> 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 comfortable with the idea of including a URI based on
>>> your own local service in rft_id, then including any old public
>>> URL in rft_id.
>>>
>>> Then at least your link resolver can say "if what's in rft_id
>>> begins with (eg) http://telstar.open.ac.uk/, THEN I know this is
>>> one of these purl type things, and I know that sending the user
>>> to it will result in a redirect to an end-user-appropriate access
>>> URL."
>>> Cause that's my concern with putting random URLs in rft_id, that
>>> there's no way to know if they are intended as end-user-
>>> appropriate access URLs or not, and in putting things in rft_id
>>> that aren't really good "identifiers" for the referent at all.
>>> But using your own local service ID, now you really DO have
>>> something that's appropriately considered a "persistent
>>> identifier" for the referent, AND you have a straightforward way
>>> to tell when the rft_id of this context is intended as an access
>>> URL.
>>>
>>> Jonathan
>>>
Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA
[log in to unmask]
http://go-to-hellman.blogspot.com/
|