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 in my rft_ids.  Putting 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 or 
"globally meaningful" but or "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.


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), 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
> [log in to unmask]