Search the Taxacom archive · Browse by month · Mirror of the former lists.ku.edu archive (1992–2025)

[Taxacom] Showing the importance of natural history collections and the networks they are building

Peter Oboyski pt_oboyski at hotmail.com
Fri Apr 25 19:44:56 CDT 2014 

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.

More information about the Taxacom mailing list