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
e...@hellman.net
http://go-to-hellman.blogspot.com/
