 |
 |
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 1.0. 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 OpenURL. Jonathan 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? > >