OK, really must stop avoiding what I'm supposed to be doing (writing a paper, already missed the deadline), but continuing the theme of LSIDs and short URLs, it occurs to me that LSIDs can be seen as a disaster (don't work in webrowsers, nobody else uses them, hard to implement, etc.) or an opportunity. The URL shortening service bit.ly provides information on each shortened URL (e.g., http://bit.ly/3R6apo, such as a summary of the URL
statistics on how the URL is being accessed
conversations (who is talking about this URL)
and lastly metadata harvested from the URL using services such as Open Calais
Imagine we provided the same services for LSIDs. In other words, instead of a simple HTTP proxy such as http://bioguid.info, the proxy stores information on how often the LSID is resolved (and by whom), where the LSID has been cited (web pages, papers, etc), and what metadata is has (the last bit is easy, we don't need a tool like Open Calais). We could extend this to other identifiers, such as DOIs (for which we could do things like show whether the DOI has been bookmarked by Connotea, CiteULike, etc.).
Now, if one of our large projects (e.g., GBIF or EOL) showed a little bit of ambition and creativity and did something like this, we could have a cool tool. Plus, we'd be aggregating metadata along the way. I think this could lead to the first "killer app" for biodiversity informatics.
1 comment:
There's open source software that does the link shortening, a short/witty domain could be thought up, I like the idea of integrating this with OpenCalais and harvesting metadata that way, and can see how it *could* point to a DOI if it could determine it by the link it's holding. Only thing is, getting nice charts and reports that bit.ly are providing, I hadn't seen that component, suppose it wouldn't be too hard to grep out once you had the URL in a database...
Post a Comment