University of Glasgow

Roderic Page

![JSTOR Logo RGB
60x76](https://lh3.googleusercontent.com/-rrpRKGbMfmU/Va-a080CEpI/AAAAAAAAD9w/3fkk0z-H3sI/JSTOR_Logo_RGB_60x76.gif?imgmax=800 "JSTOR_Logo_RGB_60x76.gif"){border="0"
width="60" height="76" style="float:right;"}Browsing JSTOR\'s [Global
Plants](http://plants.jstor.org) database I was struck by the [number of
comments](http://plants.jstor.org/comments) people have made on
individual plant specimens. For example, for the [Holotype of
*Scorodoxylum hartwegianum*
Nees](http://plants.jstor.org/stable/10.5555/al.ap.specimen.k000534285)
(K000534285) there is a [comment from Håkan
Wittzell](http://plants.jstor.org/stable/10.5555/al.ap.specimen.k000534285#comment-1870490692)
that the \"Collection number should read 1269 according to Plantae
Hartwegianae\". In JSTOR the collection number is 1209.

Now, many (if not all) of these specimens will also be in GBIF. Indeed,
K000534285 is in GBIF as <http://www.gbif.org/occurrence/912442645>,
also with collection number 1209. A GBIF user will have no idea that
there is some doubt about one item of metadata about this specimen.

So, an obvious thing to do would be to make the link between the JSTOR
and GBIF records. Implementing this would need so fussing because (sigh)
unlike DOIs for articles we don\'t have agreed upon identifiers for
specimens. So we\'d need to do some mapping between the specimen barcode
**K000534285**, the JSTOR URL
**http://plants.jstor.org/stable/10.5555/al.ap.specimen.k000534285**,
and the GBIF record **http://www.gbif.org/occurrence/912442645**.

In addition to providing users with more information, it might also be
useful in kickstarting annotation on the GBIF site. At the moment GBIF
has no mechanism for annotating data, and if it did, then it would have
to start from scratch. Imagine that a person visiting occurrence
912442645 sees that it has already attracted attention elsewhere (e.g.,
JSTOR). They might be encouraged to take part in that conversation
(because at least one person cared enough to comment already). Likewise,
we could feed annotations on the GBIF site to JSTOR.

A variation on this idea is to think of annotations such as those in the
JSTOR database as being analogous to the tweets, blog posts, and
bookmarking that [altmetric](http://altmetric.com) tracks for academic
papers. Imagine if we applied the same logic to GBIF and had a way to
show users that a specimen has been commented on in JSTOR Plants?
Thinking further down the track, we could image adding other sorts of
\"attention\", such as citations by papers, vouchers for DNA sequences,
etc.

It would be a fun project to see whether the [Disqus](http://disqus.com)
API enabled us to create a tool that could match JSTOR Global Plants
comments to GBIF occurrences.


Browsing JSTOR's Global Plants database I was struck by the number of comments people have made on individual plant specimens. For example, for the Holotype of
<em>
 Scorodoxylum hartwegianum
</em>
Nees (K000534285) there is a comment from Håkan Wittzell that the "Collection number should read 1269 according to Plantae Hartwegianae". In JSTOR the collection number is 1209. Now, many (if not all) of these specimens will also be in GBIF.

Altmetrics, Disqus, GBIF, JSTOR, and annotating biodiversity data

![Goet008353](http://lh6.ggpht.com/-SqCFT317KsY/USYK37wEBaI/AAAAAAAACds/03qIna4dzAI/goet008353.jpg?imgmax=800 "goet008353.jpg"){border="0"
width="137" height="200" style="float:right;"}Somehow I get the feeling
that botanists haven\'t got the \"open data\" religion. Not only is the
list of plant names list [behind a really bad
license](http://iphylo.blogspot.com/2010/12/plant-list-nice-data-shame-it-not-open.html),
but the [Global Plants Initiative (GPI)](http://gpi.myspecies.info/)
hides its type images behind a JSTOR Plant Sciences paywall. Why is
botany determined to keep its data under wraps?  
  
For example, the first specimen on the JSTOR site is the [GOET008353,
the isotype of *Aa achalensis*
Schltr.](http://plants.jstor.org/specimen/goet008353). You can see a
thumbnail of the specimen (shown on the right), but if you want the full
image you need to have a subscription, otherwise you see this message:  
  

> The resource you are attempting to access is part of JSTOR Plant
> Science. JSTOR Plant Science is currently being offered free of charge
> for all JSTOR participants and not for profit institutions. To learn
> more about JSTOR Plant Science, please contact plants@jstor.org.

  
  
So, without a subscription you don\'t get to see this in high resolution
(the JSTOR site features a higher resolution image and associated
viewer):  
  
![Resolver](http://lh6.ggpht.com/-wm5FI8buKnk/USYK2inNMdI/AAAAAAAACdk/5U6MWq7tP_A/resolver.jpg?imgmax=800 "resolver.jpg"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="409" height="600"}  
  
Why would herbariums hand over this imagery? I [complained about this on
Facebook](http://www.facebook.com/rdmpage/posts/10200339079135576) and
Chuck Miller responded that the original herbaria retain control over
the images, so they aren\'t locked away. However, I then when to the
herbarium that has this specimen (the [Type Database of Herbarium
Göttingen (GOET)](http://www.uni-goettingen.de/de/186917.html) and
search for this specimen I eventually find it listed as
[4966](https://gwdu64.gwdg.de/pls/herbar/typen$typen.QueryViewByKey?P_ID=4966&Z_CHK=7130).
There is no image!  
  
So, the only place I can see this image is on JSTOR, for which I need a
subscription. I\'m also puzzled by the fact that JSTOR refers to this as
\"GOET008353\", whereas the original herbarium refers to it as \"4966\".
GBIF also has this specimen, which it refers to as [GOET GOET-Typen
4966](http://data.gbif.org/occurrences/736142455). The GOET008353 is a
barcode given to types as part of the GPI digitisation programme.
Unfortunately, neither the originating herbarium nor GBIF seems to know
about this.  
  
In summary, we have three databases with data on this specimen, each
with a different specimen identifier, none of which link to each other,
and the available imagery is behind a paywall.  
  
Clearly botany hasn\'t gotten the memo about open data\...


Somehow I get the feeling that botanists haven't got the "open data" religion. Not only is the list of plant names list behind a really bad license, but the Global Plants Initiative (GPI) hides its type images behind a JSTOR Plant Sciences paywall. Why is botany determined to keep its data under wraps?

Why are botanists locking away their data in JSTOR Plant Science?

![](http://www.jstor.org/templates/jsp/_jstor/images/jstor_logo.gif){align="right"}  
As much as I like the idea of a globally unique, resolvable identifier,
my recent experience with JSTOR is making me wonder.  
  
JSTOR has three identifiers for articles it archives, DOIs, SICIs, and
stable URLs (the later being introduced with the new platform released
April 4, 2008). Previously JSTOR would publish DOIs for many of its
articles. However, not all of these work, and many are now embedded in
the HTML (say, in [Dublin Core meta
elements](http://dublincore.org/documents/dcq-html/)) but not publicly
displayed.  
  
I suspect the issue is the [moving
wall](http://www.jstor.org/page/info/about/archives/journals/movingWall.jsp):  

> Journals in JSTOR have \"moving walls\" that define the time lag
> between the most current issue published and the content available in
> JSTOR. The majority of journals in the archive have moving walls of
> between 3 and 5 years, but publishers may elect walls anywhere from
> zero to 10 years.

Now, imagine that a publisher has an article on its web site, complete
with a DOI, and that article is then add to JSTOR, but is still
displayed on the publisher\'s site.  
  
![](http://www.jstor.org/covergifs/systbiol/cover.gif){align="left"
hspace="7"}  
To make this concrete, consider the article by Baum *et al.* . On the
InformaWorld site this is displayed with
[doi:10.1080/106351598260879](http://dx.doi.org/10.1080/106351598260879).
The same article is also in JSTOR, with the URL
<http://www.jstor.org/pss/2585367>. No DOI is displayed on the page, but
if you look at the HTML source, we find:  

. The DOI prefix **10.2307** is used for all JSTOR DOIs, and some for
Systematic Biology still work, e.g.
[10.2307/2413524](http://dx.doi.org/10.2307/2413524).  
  
Now, what happens when the JSTOR moving wall overlaps with publisher\'s
material? What happens if a publisher digitises back issues, then
assigns them DOIs? Do the JSOR DOIs then die (as some of them seem to
have already done)? And what happens to the poor sap like me, who has
been linking to JSTOR DOIs in the naive belief that DOIs don\'t die?  
  
Suddenly separating identity from resolution is starting to look very
attractive\...  
  


As much as I like the idea of a globally unique, resolvable identifier, my recent experience with JSTOR is making me wonder. JSTOR has three identifiers for articles it archives, DOIs, SICIs, and stable URLs (the later being introduced with the new platform released April 4, 2008). Previously JSTOR would publish DOIs for many of its articles.

When DOIs collide and then disappear: when is a unique, resolvable identifier a bad idea?

I think this isn\'t supposed to happen, but here\'s a paper with **two**
DOIs.  
  
The first DOI is
[doi:10.1651/0278-0372(1997)17\[253:MPAOTC\]2.0.CO;2](http://dx.doi.org/10.1651/0278-0372(1997)17%5B253:MPAOTC%5D2.0.CO;2),
which links to a record served by BIOONE. The second is
[doi:10.2307/1549275](http://dx.doi.org/10.2307/1549275), which links to
a JSTOR record
([sici:0278-0372(199705)17:2\<253:MPAOTC\>2.0.CO;2-O](http://links.jstor.org/sici?sici=0278-0372%28199705%2917%3A2%3C253%3AMPAOTC%3E2.0.CO%3B2-O&origin=crossref)).  
  
The paper is:  

> **Morphology-Based Phylogenetic Analysis of the Clawed Lobsters
> (Family Nephropidae and the New Family Chilenophoberidae)**  
> Dale Tshudy, Loren E. Babcock  
> *Journal of Crustacean Biology*, Vol. 17, No. 2 (May, 1997), pp.
> 253-263  

  
[![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGUfm6xtCqbfnNUiTGZLC8TpHIf7Do3Armifezmmh11FtLOrOzCVYm6pqo0HT69ZFYhFQ7I94aokGfbUioiJZ4hOqKbJ0Bxf-hLNFDgvTGYYIMDbHiksC2bn2OUDKPZadbeL4M/s320/jstor.jpg){#BLOGGER_PHOTO_ID_5062151852948349250
style="float:middle; margin:0 0 10px 10px;cursor:pointer; cursor:hand;"
border="0"}](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGUfm6xtCqbfnNUiTGZLC8TpHIf7Do3Armifezmmh11FtLOrOzCVYm6pqo0HT69ZFYhFQ7I94aokGfbUioiJZ4hOqKbJ0Bxf-hLNFDgvTGYYIMDbHiksC2bn2OUDKPZadbeL4M/s1600-h/jstor.jpg)  
Now, the digital versions served by BIOONE and JSTOR is different, in
that BIOONE serves full text HTML and a PDF, whereas JSTOR serves
scanned images, but this is the **same** article.  
  
As an added \"feature\", the BIOONE DOI **doesn\'t work**, which in my
experience is often the case with BIOONE DOIs.


I think this isn't supposed to happen, but here's a paper with
<strong>
 two
</strong>
DOIs. The first DOI is doi:10.1651/0278-0372(1997)17[253:MPAOTC]2.0.CO;2, which links to a record served by BIOONE.

Messaggi di Rogue Scholar

Altmetrics, Disqus, GBIF, JSTOR, and annotating biodiversity data

Why are botanists locking away their data in JSTOR Plant Science?

When DOIs collide and then disappear: when is a unique, resolvable identifier a bad idea?

Duplicate DOIs