It's not "dead" in the sense that it is not in use -- it is, in wide 
use.   It is "dead" in the sense that, in my opinion, it is not going to 
evolve or change.  It is highly unlikely that the majority of 'in the 
wild' OpenURL link resolvers or generators (referrers) are going to do 
anything with OpenURL other than what they do with it now -- which is 
basically using OpenURL like the pre-standardized "0.1" version, but in 
some (but not all) cases with the actual syntax updated to standardized 

So it's in use, in a very basic way, not taking advantage of the 
'sophisticated' features that OpenURL 1.0 tried to add. I say 'tried' 
because not only did they not catch on, but they are done in a very 
confusing and not entirely consistent way.  Most implementers of OpenURL 
generators or link resolvers do not understand the sophisticated aspects 
of OpenURL 1.0, they're just plugging bits into query parameters from 
templates, and often doing so in a non-standards compliant illegal way, 
that ends up working anyway cause the whole infrastructure has been 
built assuming certain things that are not in fact specified will be 
done or not done.

I think ideas to add extensions OR  new metadata formats (that OpenURL 
1.0 makes possible) to OpenURL are a lost cause. They are never going to 
catch on, and even trying to make them catch on is often going to mess 
things up for the established infrastructure that assumes they won't be 
done (Like, depending on who you talk to in this thread, assuming that 
rft_id is always suitable as an end-user access URL; or assuming it 
never is. heh.)  . And the only reason to use OpenURL instead of 
something a LOT less confusion is because of it's current wide 
adoption.  So new features, I throw up my hands.

If you sense a mixed message or ambivalence from me, it's because I am 
ambivelent. I have spent a lot of time with OpenURL in working on a 
significant project or two. I know it fairly well, and have used it and 
will continue to use it to do all sorts of stuff.  And I  have come to 
really dislike it, and wish it were different than it was. It's got the 
wrong kinds of abstraction and lacks the right kinds of flexibility.  
Nonetheless, I think we're stuck with it for _certain_ things, so I am 
concerned with people trying to move forward without increasing it's 
flaws yet further, that's important to me, so, yeah, I care about how 
people are using it even though I don't like it, cause I use it too and 
need to inter-operate with all sorts of stuff.   But if for a given 
project that did not necessarily need to operate with the existing link 
resolver infrastructure, if I could find a metadata standard other than 
OpenURL to use, especially one that's not just library world and (unlike 
OpenURL IMO) makes easy things simple and provides flexibility to do 
more complicated things more complicatedly...   I'd never consider using 


Mike Taylor wrote:
> 2009/9/14 Jonathan Rochkind <[log in to unmask]>:
>> Seriously, don't use OpenURL unless you really can't find anything else that
>> will do, or you actually want your OpenURLs to be used by the existing 'in
>> the wild' OpenURL resolvers. In the latter case, don't count on them doing
>> anything in particular or consistent with 'novel' OpenURLs, like ones that
>> put an end-user access URL in rft_id... don't expect actually existing in
>> the wild OpenURLs to do anything in particular with that.
> Jonathan, I am getting seriously mixed messages from you on this
> thread.  In one message, you'll strongly insist that some facility in
> OpenURL is or isn't useful; in the next, you'll be saying that the
> whole standard is dead.  The last time I was paying serious attention
> to OpenURL, that certainly wasn't true -- has something happened in
> the last few months to make it so?