University of Glasgow

Roderic Page

This is not a post I\'d thought I\'d write, because OpenURL is an awful
spec. But last week I ended up in vigorous debate on Twitter after I
posted what I thought was a casual remark:  
  

> If you publish bibliographic data and don\'t use COinS
> [ocoins.info](http://t.co/RwO0fEKYID "http://ocoins.info/") you are
> doing it wrong (I\'m looking at you
> @[europepmc_news](https://twitter.com/europepmc_news))
>
> --- Roderic Page (@rdmpage) [March 8,
> 2013](https://twitter.com/rdmpage/status/309957666179018752)

  
  
This ended up being a marathon thread about OpenURL, accessibility,
bibliographic metadata, and more. It spilled over onto a previous blog
post ([Tight versus loose
coupling](http://iphylo.blogspot.co.uk/2013/01/tight-versus-loose-coupling.html))
where [Ed Summers](http://twitter.com/edsu) and I debated the merits of
[Context Object in Span (COinS)](http://ocoins.info/).  
  
This debate still nags at me because I think there\'s an underlying
assumption that people making bibliographic web sites know what\'s best
for their users.  
  
[Ed
wrote](http://iphylo.blogspot.co.uk/2013/01/tight-versus-loose-coupling.html#comment-822988405):  
  

> I prefer to encourage publishers to use HTML\'s metadata facilities
> using the
>
> tag and microdata/RDFa, and build actually useful tools that do
> something useful with it, like Zotero or Mendeley have done.

  
That\'s fine, I like embedded metadata, both as a consumer and as a
provider (I provide Google Scholar-compatible metadata in
[BioStor](http://biostor.org)). What I object to is the idea that this
is all we need to do. Embedded metadata is great if you want to make
individual articles visible to search engines:  
![Metadata1](http://lh6.ggpht.com/-flB6YJaB4jc/UUBXSRd8hFI/AAAAAAAAChM/ecj6XmfkkWA/metadata1.png?imgmax=800 "metadata1.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="460" height="172"}  
Tools like Google (or bibliographic managers like Mendeley and Zotero)
can \"read\" the web page, extract structured data, and do something
with that. Nice for search engines, nice for repositories (metadata
becomes part of their search engine optimisation strategy).  
  
But this isn\'t the only thing a user might want to do. I often find
myself confronted with a list of articles on a web site (e.g., a
bibliography on a topic, a list of references cited in a paper, the
results of a bibliographic search) and those references have no links.
Often those links may not have existed when original web page was
published, but may exist now. I\'d like a tool that helped me find those
links.  
  
If a web site doesn\'t provide the functionality you need then, luckily,
you are not entirely at the mercy of the people who made the decisions
about what you can and can\'t do. Tools like
[Greasemonkey](http://en.wikipedia.org/wiki/Greasemonkey) pioneered the
idea that we can hack a web page to make it more useful. I see COinS as
an example of this approach. If the web page doesn\'t provide links, but
has embedded COinS then I can use those to create OpenURL links to try
and locate those references. I am no longer bound by the limitations of
the web page itself.  
  
![Metadata2](http://lh3.ggpht.com/-kfA1rXBukq0/UUBXTbihJfI/AAAAAAAAChU/OjGuHZbNQuQ/metadata2.png?imgmax=800 "metadata2.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="460" height="285"}  
This strikes me as very powerful, and I use COinS a lot where they are
available. For example, CrossRef\'s excellent [search
engine](http://search.crossref.org) supports COinS, which means I can
find a reference using that tool, then use the embedded COinS to see
whether there is a version of that article digitised by the Biodiversity
Heritage Library. This enables me to do stuff that CrossRef itself
hasn\'t anticipated, and that makes their search engine much more
valuable to me. In a way this is ironic because CrossRef is predicated
on the idea that there is one definitive link to a reference, the DOI.  
  
So, what I found frustrating about the conversation with Ed was that it
seemed to me that his insistence on following certain standards was at
the expense of functionality that I found useful. If the client is the
search engine, or the repository, then COinS do indeed seem to offer
little apart from God-awful HTML messing up the page. But if you include
the user and accept that users may want to do stuff that you don\'t
(indeed can\'t) anticipate then COinS are useful. This is the \"genius
of **and**\", why not support both approaches?  
  
Now, COinS are not the only way to implement what I want to do, we could
imagine other ways to do this. But to support the functionality that
they offer we need a way to encode metadata in a web page, a way to
extract that metadata and form a query URL, and a set of services that
know what to do with that URL. OpenURL and COinS provide all of this
right now and work. I\'d be all for alternative tools that did this more
simply than the Byzantine syntax of OpenURL, but in the absence of such
tools I stick by my original tweet:  
  

> If you publish bibliographic data and don\'t use COinS you are doing
> it wrong


This is not a post I'd thought I'd write, because OpenURL is an awful spec. But last week I ended up in vigorous debate on Twitter after I posted what I thought was a casual remark:This ended up being a marathon thread about OpenURL, accessibility, bibliographic metadata, and more.

Postagens de Rogue Scholar

In defence of OpenURL: making bibliographic metadata hackable