[Taxacom] Showing the importance of natural history collections
and the networks they are building
Timothy Jones
tjone54 at tigers.lsu.edu
Sun Apr 27 12:17:35 CDT 2014
2014
Howdy All,
Have been following this interesting thread and have a few questions
concerning implementation of DOI's across our identification tools/DBs.
Would I approach my establishments publishing arm for access (to use their
annual license/fee) ? Plus another question about costs - was only able to
find one RA's costs page - here-
http://www.crossref.org/02publishers/20pub_fees.html.
Would a web-based tool be 1.00 US or 0.06 cents? Lastly, are these costs
variable, meaning, can you go bargain shopping for DOI's? Big sale
today...:)
Thanks,
Tim
On Sat, Apr 26, 2014 at 6:00 AM, Roderic Page <Roderic.Page at glasgow.ac.uk>wrote:
> Hi Peter,
>
> Whether freezing snapshots is the responsibility of the provider or user
> is worth discussing. I don't think it's necessarily "insane" to provide a
> GUID for each download, but I realise that this will generate a lot of
> identifiers that won't get used.
>
> Yes, the data set that a user ends up with after they have filtered,
> cleaned, and edited it should be preserved. Ideally the provider should be
> able to get that cleaned data back to make use of it. If you want to
> encourage such behaviour, then one approach would be to offer to host that
> cleaned data (and mint a DOI). That way you create an incentive for the
> user to (a) archive the data with an identifier, and (b) to give you back
> the cleaned data.
>
> Regarding citing collections, yes, having a paper that describes the
> collection is a good idea. When I developed phylogenetic software I did the
> equivalent, namely writing paper about the software so people could cite
> that (if I hadn't, my citation count would look pretty dire). But asking
> people to cite the collection paper as well as the data set identifier is
> inconvenient (and it's not the thing they actually use in their work), but
> better to have a mechanism that automatically links the collection (or
> collection paper) to each data identifier.
>
> One thing that I'm constantly puzzled by is the frequency with which
> people insist others should do something: they should cite this collection,
> they should cite that collection. Surely it would be better to think about
> the behaviour you want (people citing your stuff), and then figure out how
> to make it a no brainer for them to do that. For example, if you want
> people to archive data derived from your collection, give them a reason to
> do so by providing them with that archiving service, and give them a DOI
> they can cite. Everybody wins.
>
> Regards
>
> Rod
>
> On 26 Apr 2014, at 01:44, Peter Oboyski <pt_oboyski at hotmail.com> wrote:
>
> > A very topical discussion. Representing a museum generating data that is
> destined for the web, which will be picked up by aggregators and other
> users, I know this topic to be terribly complicated at several levels. But
> I will focus here just on the "snapshot" issue. I agree it is important to
> freeze a moment in time (as a snapshot) that represents the data used for a
> particular analysis/publication. But this task is the responsibility of the
> data user, not the provider. The user may draw data from multiple sources,
> do their own massaging, editing, vetting, etc. This unique data set should
> be archived (with a GUID or as supplementary data in a journal). But it is
> insane to expect a data provider to mint a DOI or other GUID for every
> download - most of which will not result in publication. Our database
> changes every hour. It behooves any data generating operation to track the
> addition and editing of data. This could be as simple as 'date-added' and
> date-edited' fields with a 'edit-remarks' field to note changes made during
> each edit. Most users will not make use of this information, but it is
> worth tracking.
> >
> > But this does not address the original point of this thread. We have
> spent a lot of resources and person-hours to build and populate our
> open-access database. We would like not only proper recognition for this
> effort, but also an opportunity to explain its sources, history, and
> limitations. This is best served by a published article that 'explains' the
> database, but does not provide the data itself (which is constantly
> changing). I would expect a user of our data to cite this publication
> (eh-hem, which we have yet to publish) as well as archive a version of the
> data they used for their analysis/publication. Likewise, I would expect
> aggregators to link back to our database website where this information is
> available.
> >
> > Pete
> >
> > ------------------------------------------------------------
> > Peter T Oboyski, PhD
> > Collections Manager & Senior Museum Scientist
> > Essig Museum of Entomology
> > 1170 Valley Life Science Building
> > University of California, Berkeley
> >
> > mailing address:
> > 1101 VLSB, #4780
> > Berkeley, CA 94720
> >
> > http://nature.berkeley.edu/~poboyski/
> > http://essig.berkeley.edu
> >
> > essig.museum at gmail.com
> > 510.643.0804 (work phone)
> > 510.847.0360 (cell phone)
> > --------------------------------------------------------------
> >
> >> From: deepreef at bishopmuseum.org
> >> To: Roderic.Page at glasgow.ac.uk; Taxacom at mailman.nhm.ku.edu
> >> Date: Thu, 24 Apr 2014 15:02:21 -1000
> >> Subject: Re: [Taxacom] Showing the importance of natural history
> collections and the networks they are building
> >>
> >> Thanks, Rod -- good answers.
> >>
> >> It matters because GUIDs of all sorts (including DOIs) are completely
> >> useless (and, in fact, exacerbate the problems more than solve
> problems) if
> >> people are not clear on what is actually being identified by the
> identifier.
> >> If I mint an identifier for a taxon name, then someone misinterprets it
> as
> >> being for a taxon concept, that's bad. If I mint an identifier for a
> >> location, and someone else misinterprets it as an event (yes, this does
> >> happen), that's bad. If I mint an identifier for a dynamic data
> source, and
> >> someone misinterprets it as representing a static data source, that's
> bad.
> >> I know you like to think the world would be a better place if we just
> stuck
> >> DOIs on everything; but sloppy application of identifiers is like sloppy
> >> taxonomy -- it makes things harder for everyone else.
> >>
> >> Aloha,
> >> Rich
> >>
> >>> -----Original Message-----
> >>> From: Roderic Page [mailto:Roderic.Page at glasgow.ac.uk]
> >>> Sent: Thursday, April 24, 2014 10:18 AM
> >>> To: Taxacom at mailman.nhm.ku.edu
> >>> Cc: Richard Pyle
> >>> Subject: Re: [Taxacom] Showing the importance of natural history
> >> collections
> >>> and the networks they are building
> >>>
> >>> Hi Rich,
> >>>
> >>> I have two standard responses to this question:
> >>>
> >>> 1. Who cares about versions? No, really - we keep worrying about this,
> but
> >>> does anybody actually take versions into account? For example, GenBank
> has
> >>> versioned DNA sequences and I have never seen anyone cite a sequence
> >>> accession number AND version. So, to a first approximation, I don't
> think
> >> this
> >>> is the issue people make it out to be. Anyone every seen a versioned
> link
> >> to a
> >>> Wikipedia page?
> >>>
> >>> 2.OK, so you really, really, care about versions. Then I think one
> answer
> >> is to
> >>> provide a DOI for the data e.g., 10.1234/data (which you can think of
> as
> >> either
> >>> all the versions, or the latest version), and a DOI for each version
> >> (e.g.,
> >>> 10.1234/data.v1, 10.1234/data.v2). If, like most folks, you couldn't
> care
> >> less
> >>> ("just give me the latest version please") then you'd use the DOI for
> the
> >> data
> >>> (10.1234/data) that resolves to the latest version. If you care about
> the
> >>> version (e.g., reproducibility is your thing) then use the DOI for the
> >> particular
> >>> version (e.g., 10.1234/data.v1).
> >>>
> >>> There are examples of versioned DOIs in the wild. For example,
> >>> http://dx.doi.org/10.12688/f1000research.2-92.v1 is a versioned DOI.
> >>> CrossRef supports versions through Crossmark
> >>> http://www.crossref.org/crossmark/i to handle things like errata,
> >>> retractions, etc.
> >>>
> >>> Regards
> >>>
> >>> Rod
> >>>
> >>> P.S. For the sake of all our sanity, let us never speak of LSID
> metadata
> >> vs data
> >>> ;)
> >>>
> >>> On 24 Apr 2014, at 20:50, Richard Pyle <deepreef at bishopmuseum.org>
> >>> wrote:
> >>>
> >>>> Agreed! I forgot to mention that the archived snapshot documents in
> >>>> our planned system would be assigned persistent identifiers (most
> likely
> >>> DOIs).
> >>>>
> >>>> However, this raises another issue that I have not seen adequately
> >>>> addressed in any of these discussions about identifiers for datasets
> >>> (including DOIs):
> >>>>
> >>>> Is there an expectation that the object represented by an identifier
> >>>> remains static? In the case of traditional publications, this seems
> to
> >> be the
> >>> case.
> >>>> When I dereference a DOI, I get a digital document (or a landing page
> >>>> for a digital document). In my mind, that DOI identifies the
> >>>> conceptual object (i.e., the published work as an abstract entity, not
> >>>> any particular digital manifestation/instantiation of the published
> >>>> work, such as a particular PDF file on a particular hard drive
> >>>> somewhere). But in the case of "traditional" publications (including
> >>>> electronic publications, and as opposed to datasets), the content of
> >>>> the object is expected to remain static over time. A hundred years
> >>>> from now, when I (more likely my grandchildren) dereference a DOI,
> >>>> they will get the same information content (at least at a
> >> human-perception
> >>> level, if not a bit-identical data file) that I get today.
> >>>>
> >>>> Now, I know lots of people (particularly Rod) like to say we should
> >>>> assign DOIs to "datasets". That's fine, and totally within scope of
> >>>> what DOIs were intended for. But is it implicit that a DOI assigned
> >>>> to a dataset is actually assigned to a *snapshot* of that dataset at a
> >>>> particular moment in time? Or is the DOI representing the conceptual
> >>>> notion of the dataset, which changes in content over time?
> >>>>
> >>>> So, I could assign a single DOI to the Bishop Museum fish collection
> >>>> dataset, representing the "conceptual" notion of the Bishop Museum
> >>>> fish collection dataset. Tomorrow the content is likely to be
> >>>> different from what it is now. To me, this seems to border on useless.
> >>>> One of the critical issues of citing databases that comes up again and
> >>>> again is to include the date on which the dataset was accessed (see my
> >>>> previous post). Is that date part of the permanent DOI metadata? If
> >>>> so, there may be hundreds of DOIs issued for the Bishop Museum fish
> >>>> collection dataset, each one representing a particular moment in time
> >>>> for which someone wishes to be able to cite the dataset content.
> >>>>
> >>>> Glancing over through the DOI specification, it seems to me that there
> >>>> is an implicit assumption that the document identified by a DOI is
> >>>> static in content. But I haven't read it thoroughly, and am by no
> means
> >> an
> >>> expert.
> >>>>
> >>>> So, my question to Rod (and anyone else) is: if we assign an
> >>>> identifier such as a DOI to a dataset, is there an expectation that
> >>>> the dataset indicated by the identifier is static? Or, might it be
> >>>> dynamic? In the parlance of LSID-speak, what is implicitly the
> "data",
> >> vs.
> >>> the "metadata"?
> >>>>
> >>>> Aloha,
> >>>> Rich
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: taxacom-bounces at mailman.nhm.ku.edu [mailto:taxacom-
> >>>>> bounces at mailman.nhm.ku.edu] On Behalf Of Roderic Page
> >>>>> Sent: Thursday, April 24, 2014 9:19 AM
> >>>>> To: Taxacom at mailman.nhm.ku.edu
> >>>>> Subject: Re: [Taxacom] Showing the importance of natural history
> >>>> collections
> >>>>> and the networks they are building
> >>>>>
> >>>>> Surely we can learn from past mistakes and do this properly.
> >>>>> Citations are meaningless unless they are counted, and the way to do
> >>>>> this efficiently is with identifiers such as DOIs, not developing
> >>>>> some arbitrary way of citing databases or datasets. Mint DOIs for
> >>>>> collections, mint DOIs for datasets
> >>>> (GBIF
> >>>>> is heading down this route), make data a first class citizen by
> >>>>> making it
> >>>> trivially
> >>>>> easy to cite. Don't moan about people not citing data if you haven't
> >>>>> made
> >>>> it
> >>>>> easy for them to do so. If you value your data, make it easy to cite
> >>>>> -
> >>>> give it a
> >>>>> DOI.
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>> Rod
> >>>>>
> >>>>> Sent from my iPhone
> >>>>>
> >>>>>> On 24 Apr 2014, at 19:34, "Richard Pyle"
> >>> <deepreef at bishopmuseum.org>
> >>>>> wrote:
> >>>>>>
> >>>>>> Hi Mary,
> >>>>>>
> >>>>>> I have LONG supported this notion. One of the problems, though, is
> >>>>>> that very few databases allow future users to see what the database
> >>>>>> contained on the date on which it was accessed. In an ideal world,
> >>>>>> all online databases would include a parameter "asOfDate" or
> >>>>>> something similar, where users can pass in a particular date and see
> >>>>>> what the database consisted of as of that date. For some systems
> >>>>>> (which maintain robust edit logs or "audit trails", or maintain
> >>>>>> explicit versioning), it would be possible to do this; but for many
> >>>>>> systems it
> >>>> would
> >>>>> not.
> >>>>>>
> >>>>>> Recognizing this issue, about ten years ago we conceived of a system
> >>>>>> where users of our online databases could select an option to
> >>>>>> "publish" a full snapshot of the query results they examined. The
> >>>>>> idea would be for a user to construct a query of the database and
> >>>>>> get a result-set back, then upon deciding that this result-set is
> >>>>>> the one to be cited, there would be a button that "published" the
> >>>>>> result set as an XML file (which could be represented as a styled
> >>>>>> PDF or converted to Excel, complete with its own title, authorship
> >>>>>> [jointly the person constructing the query, and the database owner],
> >>>>>> full data set, and its own "references" section that cited the
> >>>>>> original sources of the data). This XML file would then be
> >>>>>> permanently archived for future access, and would be the digital
> >>>>>> object cited in the work for
> >>>> which it
> >>>>> was generated.
> >>>>>>
> >>>>>> We never followed through with the development of that concept
> >>>>>> (budget issues, different priorities, etc.); but there may yet be
> >>>>>> some value in doing it. For example, perhaps there could be an
> >>>>>> automated system that allowed users of online databases to snap-shot
> >>>>>> result-sets directly into a publication venue such as the
> Biodiversity
> >> Data
> >>> Journal.
> >>>>>>
> >>>>>> Speaking of that journal, we are planning to publish a regional
> >>>>>> checklist (fishes of the Northwestern Hawaiian Islands) in BDJ that
> >>>>>> changes the way such regional checklists are created. Basically, we
> >>>>>> build an evidence-based checklist of occurrence records for
> >>>>>> within-scope taxa at within-scope region, and store this in a
> >>>>>> database. The checklist is annotated and curated by the authors,
> >>>>>> who vet all the data, flag dubious records, confirm taxonomic
> >>>>>> identifications, etc. The checklist is then published in a highly
> >>>>>> structured form (ala BDJ), with a link back to the database. The
> >>>>>> link would then go to a page that displays everything as it appeared
> >>>>>> in the published version, as well as all data that were altered or
> >>>>>> added since the moment of publication. The "vetted" (published)
> >>>>>> records would be formatted clearly to distinguish from all the
> >>>>>> un-vetted, "raw" data that became available following the
> >>>>>> publication. That way people who come to that website could see the
> >>>>>> full content of what was published, *AND* all of the new information
> >>>>>> that has become available since the time it was published.
> >>>>>> Eventually, when there is enough new information, it would be vetted
> >>>>>> again and a new-snapshot generated and published (in the form of a
> >>>>>> "revised" checklist, or new-records paper, or whatever). The idea
> >>>>>> is to be able to clearly show the full dataset as it was
> >>>>>> snapshot-published, and also give acces to up-to-the-moment
> >>>>>> additional data; thus avoiding the current problem with regional
> >>>> checklists,
> >>>>> which is that they become obsolete the moment they are published.
> >>>>>>
> >>>>>> In any case, I fully support the idea of more consistent and
> >>>>>> deliberate citation of online data systems in the "references"
> >>>>>> section of publications, and I'd like to see us move even beyond
> >>>>>> that to a standard system that allows people to immediately compare
> >>>>>> what was available at the time the dataset was cited to what is
> >>>>>> currently in the
> >>>>> dataset now.
> >>>>>>
> >>>>>> Aloha,
> >>>>>> Rich
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: taxacom-bounces at mailman.nhm.ku.edu [mailto:taxacom-
> >>>>>>> bounces at mailman.nhm.ku.edu] On Behalf Of Mary Barkworth
> >>>>>>> Sent: Thursday, April 24, 2014 6:49 AM
> >>>>>>> To: (Taxacom at mailman.nhm.ku.edu)
> >>>>>>> Subject: [Taxacom] Showing the importance of natural history
> >>>>>>> collections
> >>>>>> and
> >>>>>>> the networks they are building
> >>>>>>>
> >>>>>>> The other day I reviewed a paper that stated it drew information
> >>>>>>> from lots
> >>>>>> of
> >>>>>>> databases and networks but to find out which one had to go to the
> >>>>> authors'
> >>>>>>> web site and click on a pull-down list. That started me thinking of
> >>>>>>> how to
> >>>>>> get
> >>>>>>> more recognition for collections, databases, and networks.
> >>>>>>> Suggestion: Collections, databases, and networks that contributed
> >>>>>>> significantly to development of any paper, poster, pamphlet, report
> >>>> etc.
> >>>>>>> should be cited in the references section (the old "Literature
> cited"
> >>>>>> section).
> >>>>>>> We should do this ourselves, ask other authors to do so when
> >>>>>>> reviewing papers, and promote the idea at meetings we go to in
> >>>>>>> which people make use of collections data - whether of
> >>>>>>> environmental consultants,
> >>>>>> politicians, or
> >>>>>>> ecologists. Having collections and networks (and floras consulted
> >>>>>>> too)
> >>>>>> listed
> >>>>>>> in the reference section would mean that publishers will start
> >>>>>>> marking
> >>>>>> them
> >>>>>>> up and search engines may find them, all of which would, I suspect,
> >>>>>>> make
> >>>>>> it
> >>>>>>> easier to show how fundamental collections and networks are to
> >>>>>>> today's research. Below I have some suggested formats for networks
> >>>>> that I use.
> >>>>>>> 1. SEINet Network. 2014+. Provider of records from over 60 US
> >>>>>> herbaria.
> >>>>>>> Accessed via http://ngpherbaria.org<http://ngpherbaria.org/>, 23
> >>>>>>> April
> >>>>>> 2014.
> >>>>>>> 2. NGPHerbaria.org. 2014+. Portal to records from over 60 US
> >>>>>> herbaria.
> >>>>>>> Accessed via http://ngpherbaria.org<http://ngpherbaria.org/>, 23
> >>>>>>> April
> >>>>>> 2014.
> >>>>>>> 3. Intermountainbiota.org. 2014+. For records to herbaria of
> >> Utah
> >>>>>> State
> >>>>>>> University's campuses. Accessed via
> >>>>>>>
> >>> http<http://ngpherbaria.org/>://intermountainbiota.org<http://ngphe
> >>>>>>> rb
> >>>>>>> ari
> >>>>>>> a.org/>, 23 April 2014.
> >>>>>>> 4. BHSC. 2014+. Records from the herbarium of Black Hills
> State
> >>>>>> University.
> >>>>>>> Accessed via http://swbiodiversity.org/, 23 April 2014
> >>>>>>> 5. Intermountain Herbarium. 2014+. Records from the herbarium
> >> of
> >>>>>> Utah
> >>>>>>> State University, Logan Campus. Accessed via
> >>>>>>> https://www.idigbio.org/
> >>>>>>> 23 April 2014 Logically, one could also ask to see herbaria from
> >>>>>>> which one borrowed specimens listed in the References cited rather
> >>>>>>> than (or in addition to) acknowledgments.
> >>>>>>> I am a plant person. I would think that the same approach would
> >>>>>>> serve
> >>>>>> other
> >>>>>>> natural history collections and networks but perhaps not.
> >>>>>>> Comments welcome.
> >>>>>>> Mary
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Taxacom Mailing List
> >>>>>>> Taxacom at mailman.nhm.ku.edu
> >>>>>>> http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
> >>>>>>> The Taxacom Archive back to 1992 may be searched at:
> >>>>>>> http://taxacom.markmail.org
> >>>>>>>
> >>>>>>> Celebrating 27 years of Taxacom in 2014.
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Taxacom Mailing List
> >>>>>> Taxacom at mailman.nhm.ku.edu
> >>>>>> http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
> >>>>>> The Taxacom Archive back to 1992 may be searched at:
> >>>>>> http://taxacom.markmail.org
> >>>>>>
> >>>>>> Celebrating 27 years of Taxacom in 2014.
> >>>>>
> >>>>> _______________________________________________
> >>>>> Taxacom Mailing List
> >>>>> Taxacom at mailman.nhm.ku.edu
> >>>>> http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
> >>>>> The Taxacom Archive back to 1992 may be searched at:
> >>>>> http://taxacom.markmail.org
> >>>>>
> >>>>> Celebrating 27 years of Taxacom in 2014.
> >>>>
> >>>
> >>> ---------------------------------------------------------
> >>> Roderic Page
> >>> Professor of Taxonomy
> >>> Institute of Biodiversity, Animal Health and Comparative Medicine
> College
> >> of
> >>> Medical, Veterinary and Life Sciences Graham Kerr Building University
> of
> >>> Glasgow Glasgow G12 8QQ, UK
> >>>
> >>> Email: r.page at bio.gla.ac.uk
> >>> Tel: +44 141 330 4778
> >>> Fax: +44 141 330 2792
> >>> Skype: rdmpage
> >>> Facebook: http://www.facebook.com/rdmpage
> >>> LinkedIn: http://uk.linkedin.com/in/rdmpage
> >>> Twitter: http://twitter.com/rdmpage
> >>> Blog: http://en.wikipedia.org/wiki/Roderic_D._M._Page
> >>> Citations:
> >>> http://scholar.google.co.uk/citations?hl=en&user=4Z5WABAAAAAJ
> >>> ORCID: http://orcid.org/0000-0002-7101-9767
> >>
> >>
> >> _______________________________________________
> >> Taxacom Mailing List
> >> Taxacom at mailman.nhm.ku.edu
> >> http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
> >> The Taxacom Archive back to 1992 may be searched at:
> http://taxacom.markmail.org
> >>
> >> Celebrating 27 years of Taxacom in 2014.
> >
> > _______________________________________________
> > Taxacom Mailing List
> > Taxacom at mailman.nhm.ku.edu
> > http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
> > The Taxacom Archive back to 1992 may be searched at:
> http://taxacom.markmail.org
> >
> > Celebrating 27 years of Taxacom in 2014.
>
> ---------------------------------------------------------
> Roderic Page
> Professor of Taxonomy
> Institute of Biodiversity, Animal Health and Comparative Medicine
> College of Medical, Veterinary and Life Sciences
> Graham Kerr Building
> University of Glasgow
> Glasgow G12 8QQ, UK
>
> Email: r.page at bio.gla.ac.uk
> Tel: +44 141 330 4778
> Fax: +44 141 330 2792
> Skype: rdmpage
> Facebook: http://www.facebook.com/rdmpage
> LinkedIn: http://uk.linkedin.com/in/rdmpage
> Twitter: http://twitter.com/rdmpage
> Blog: http://en.wikipedia.org/wiki/Roderic_D._M._Page
> Citations:
> http://scholar.google.co.uk/citations?hl=en&user=4Z5WABAAAAAJ
> ORCID: http://orcid.org/0000-0002-7101-9767
>
>
> _______________________________________________
> Taxacom Mailing List
> Taxacom at mailman.nhm.ku.edu
> http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
> The Taxacom Archive back to 1992 may be searched at:
> http://taxacom.markmail.org
>
> Celebrating 27 years of Taxacom in 2014.
>
--
Timothy M. Jones
Life Science Annex Building, Room A257
Louisiana State University
Baton Rouge, LA 70803
Website - http://www.herbarium.lsu.edu/keys/
More information about the Taxacom
mailing list