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