 |
 |
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/