I suppose this post is just to let that minuscule number of people who follow this blog know about the later add-on to the Australian Faunal Directory. It’s invisible, you see, unless you have a browser plug-in.
I jammed open urls in after all of the publication citations. These are present as a COinS span. These are sensed by a Firefox browser plugin.
I suppose the amazing thing is that they work pretty much as advertised. When you view an AFD page with the plug-in active, you can click the icon (which is configurable, thank God) and be taken to the world cat aggregator, which will cheerfully list the libraries closes to you that list the publication. So, from the AFD page to looking at a physical copy, it’s only a few clicks away. The CSIRO libraries and the various libraries at Australian universities feed data to WorldCat.
I’d like to get feedback from a Mendeley user. I came across this:
Also Mendeley’s Web Importer can now identify COinS embedded on other websites. This information can then be easily imported into your Mendeley research library. In addition, a COinS section is embedded in each of our article pages. This means that other bookmarklets can extract and process the information from Mendeley’s article pages.
I imagine that this means that you can now point Mendeley at, say, Hydroptila acinacis and it will pull out the references. It’d be nice to hear if it works.
Actually – I’ll twitter it.
Paul Murray's SFW Blog 
+1 for using COinS. One use is to locate the reference in an external database such as BioStor. For example, the COinS in the page http://biodiversity.org.au/afd/taxa/Picrocuma_rectangularis enable me to go to http://biostor.org/reference/114079 (via the OpenURL resolver http://biostor.org/openurl ). In addition to Firefox there is a COinS extension for Chrome https://chrome.google.com/webstore/detail/coins-2-openurl/dkbeocklhoekjladflofojohjhjgfpic (I use Safari and have a Javascript bookmarklet for the same purpose).
I quickly tested the page http://biodiversity.org.au/afd/taxa/Hydroptila_acinacis in Mendeley and no joy, Mendeley tries to bookmark the Web page. Mendeley will extract single COinS from BioStor (but mangles accented characters). Zotero does extract the multiple COinS on the page http://biodiversity.org.au/afd/taxa/Hydroptila_acinacis. It costs nothing to get a Mendeley account, so you may want to get one and fuss with the Import bookmark a little – in your copious free time, obviously ;)
A bit of a mixed bag, then. I get the impression that it’s a great idea and not a lot of people are doing it. To be fair – it’s taken me three or so years to get around to it. The firefox plugin comes with a few resolver presets. OpenResolver I am pretty sure doesn’t handle the spec (or maybe it is an earlier version). OCLC mangles accented characters – I have sent them some mail and it would be nice to see it fixed.
Other issues are that I haven’t found a registry of resolvers – didn’t know BioStore had one, and navigating the spec was tricky. I coaxed ir out of http://alcme.oclc.org, but only because I had previously worked on OAI-PMH and recognised the incantations you have to use.
It would be nice to get ’em into APNI and into our service layer output. So much to do – DOIs for as many of our publications as we can match, links to BHL, my taxonomic tree thingy, …
The OpenURL spec is horrific, so my resolver has to be reasonably forgiving in interpreting what it will accept. Part of the problem with OpenURL is that it was conceived to solve a problem that most people don’t have, namely, what is the “local copy” of some resource. Hence you get lots of local (e.g., library-specific) OpenURL resolvers that you are expected to discover from your local library. If everything is digitised then Google is much more efficient at finding things and (at least in the UK) there are other means to discover if you can access a resource (e.g., IP address).
The other issue with OpenURL is that it defines the input in vast detail, but is silent on the output, so every resolver is different. It’s not like a web service with a defined input and output.
I’m still occasionally updating my CouchDB version of AFD, and could add an OpenURL resolver to that site. Hence we could have AFD and the CouchDB AFD loosely coupled via COinS, where a user visiting AFD with a browser that supports COinS could discover the digital version of the reference with minimal effort. Let me know if this appeals as something to do.
I found the human-readable docs to be pretty byzantine, and frankly I didn’t attempt to read it all. Once I found the machine-readable stuff, I was ok. The trick is OAI-PMH, which is how the present their specs.
The key URL is this one:
http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListMetadataFormats
Once we work out that for the “key/value” format we are dealing with the “mtx” format, we can go here:
http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=mtx
Which lists the different record types. Then it’s a matter of knowing by magic that OpenURLs use the ctx format as their base:
http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=GetRecord&metadataPrefix=mtx&identifier=info:ofi/fmt:key:mtx:ctx
This specifies that you put the other stuff in a ctx object by prefixing the fields with “rfe.” (for fields relating to the referent). This is what (by my reading) OpenResolver gets wrong. It expects a parameter named “date” rather than “rfe.date”, and also does not recognise jtitle, btitle, and atitle – it only processes title.
But I only found those pages in the first place because one of the URLs in the doco uses “verb=GetRecord”, which I recognised as an OAIPMH thing. Oh, and it also put something else on the URL http://alcme.oclc.org/openurl/servlet/OAIHandler/extrastuff – I stripped back the path to find the real server. At least – I hope it;s the real server.
The other issue was the ctx_enc value: should it be “UTF-8” or “info:ofi/enc:UTF-8” ? I don’t know. The docs say “Legitimate values are taken from the IANA list”, which could mean either (what does “are taken from” mean, exactly?), but it doesn’t matter because the default is UTF-8, so I can leave the parameter out.
Final problem is that URLs are supposed to be 256 characters max (I think), but thank God most modern browsers and servers ignore this.
Not as happy with it as I could be. I’m reminded of the OAI-PMH spec itself, which mandates what prefix you are supposed to be using for the XML namespace in your request document. An unnecessary imposition.
“I’m still occasionally updating my CouchDB version of AFD, and could add an OpenURL resolver to that site. Hence we could have AFD and the CouchDB AFD loosely coupled via COinS, where a user visiting AFD with a browser that supports COinS could discover the digital version of the reference with minimal effort. Let me know if this appeals as something to do.”
Well, coupling them is a matter of someone putting the CouchDB resolver url into their browser plugin, which comes back to a comment I made before: no repository of what resolvers are out there. You could achieve the same effect by feeding your information into the OCLC aggregator, but that aggregator may only accept information from actual libraries.
The other issue is that tweaking AFD is not really where we want to be – I made the change because I was doing bug fixes and improvements that involved touching the parts of the app that generate the HTML for references (which don’t appear in the AFD public pages yet). We actually want to be working on the grand unification of names and references in a single system. It’s (of course) a money thing. Too many cool ideas, not enough resources. I imagine it’s the same for everyone.
I’d like to cobble together a resolver to latch onto our (slow, always out-of-date) service layer. I could do it by writing a simple service to redirect to a query to our existing publication search function … .
“tweaking AFD is not really where we want to be” Agreed, but I think there are a couple of ways we can think about this. One is “tight coupling” where we have globally unique identifiers that are reused and hence can create links between the things we care about (e.g., if AFD uses DOIs for references). The issue is converting bibliographic citations to identifiers, which requires work. Another approach is “loose linking”, where AFD, say, provides enough details for a link to be constructed later. COinS are one way to do this. This is a useful strategy for bibliographic references where the digital availability of references changes over time. Each week I’m adding anywhere from 10-1000 new articles to BioStor, for example, and publishers are continually adding DOIs for older content.
But ultimately yes, this stuff should be in one place. In a fit of hubris I’m building something along these lines for animal names. I think money is less of an issue than tackling the problem the “right” way.
OK, for fun I’ve added an OpenURL resolver to CouchDB AFD at http://iphylo.org/~rpage/afd/openurl (not intended to be viewed directly in web browser). If you resolve an AFD article COinS the service looks up the publication in CouchDB AFD (because I use the UUID part of the AFD LSID this is straightforward). If it finds the publication it will check if I’ve mapped it to something useful, such as a DOI, Handle, or BioStor id. If so, it send you there. If there’s no mapping it takes you to CouchDB AFD, if the reference isn’t found (for example, it’s been added since I harvested AFD) then you get a sad face. Obviously this could be tweaked, and a service-friendly interface added. But you get the idea. A user browsing http://biodiversity.org.au/afd/taxa/Hydroptila_acinacis can click on the COinS and (if they’ve set the resolver to http://iphylo.org/~rpage/afd/openurl ) go straight to the paper at http://dx.doi.org/10.1071/ZO9780745
As an aside, I don’t support OpenURL requests for journals (as opposed to individual articles).
For those that like to travel, having a camera with them is a necessity.
Mega pixels are how manufacturers measure the pixel count
of an image created by a camera. Some cameras are simple point and shoot while others have
many different modes for taking pictures.
You seem to have posted this in the wrong spot.