[Taxacom] OMG! DNA only descriptions! - Round Two

[Carlos Alberto Martínez Muñoz]

Just rescued from the spam folder after reading your reply in the online
Taxacom Markmail. Other two Taxacom emails by you were also there. Jeez!
Many thanks! :D
El sáb., 21 dic. 2019 a las 5:25, Richard Pyle (<deepreef at bishopmuseum.org>)
escribió:

> Actually…. I did reply (this morning), with the Excel file extract that
> you requested.  I guess you didn’t receive it?
>
>
>
> Historical note:  The original implication of ZooBank displayed the person
> who registered the record and the date/time of registration on the main
> page (under the LSID itself).  However, people complained that it was too
> much clutter, so the consensus was to hide it and make it available through
> a mouse-over.  We can always bring it back to the main page if a new
> consensus emerges.
>
>
>
> So… do I understand you don’t need me to re-send the Excel file?
>
>
>
> Aloha,
>
> Rich
>
>
>
> P.S. Check you SPAM folder, just in case…
>
>
>
> *From:* Carlos Alberto Martínez Muñoz <biotemail at gmail.com>
> *Sent:* Friday, December 20, 2019 12:36 PM
> *To:* Stephen Thorpe <stephen_thorpe at yahoo.co.nz>
> *Cc:* taxacom at mailman.nhm.ku.edu; Richard Pyle <deepreef at bishopmuseum.org>;
> dominique.zimmermann at nhm-wien.ac.at
> *Subject:* Re: [Taxacom] OMG! DNA only descriptions! - Round Two
>
>
>
> Great! Thanks! So "A group of people could concertedly hack priority and
> make it look as it never happened, unless that someone knows that hovering
> over the ZooBank LSID will reveal the true registering date and the
> registerer". Better that way? I found no description on the hovering
> feature in the Help section. That is why I requested a ZooBank extract to
> Rich Pyle a couple of days ago, requesting the user and registration date
> to be included. Rich has not yet replied to that email, but good that there
> is no more need for that.
>
>
>
> El sáb., 21 dic. 2019 a las 0:27, Stephen Thorpe (<
> stephen_thorpe at yahoo.co.nz>) escribió:
>
> "*but we will not be able to see it*."
>
> Yes you can see it! Just hover your cursor arrow over the orange LSID box
> on any ZooBank record. It tells you who registered the record and when.
>
>
>
> Stephen
>
>
>
> On Friday, 20 December 2019, 10:00:51 pm UTC, Carlos Alberto Martínez
> Muñoz <biotemail at gmail.com> wrote:
>
>
>
>
>
> Hello Stephen,
>
> Thank you for your reply. Please note that "ZooBank itself will record the
> date of registration as 04.01.2020" *but we will not be able to see it*.
> We will only see the content of the "Date Published" field, which is
> manually entered and does not reflect the date in which the record was
> created. Unless that ZooBank is further developed, we cannot see who
> created a record and on which date. I will explain below how ZooBank can be
> hacked.
>
> Meanwhile, imagine that two papers on the same genus come out in very
> close dates. The first paper, the one from my previous example, would be
> believed to be validly published on 01.01.2020, even if it was registered
> in ZooBank on 04.01.2020 and the pdf edited and republished on that date. A
> second paper, dealing with the same genus and new species comes out on
> 03.01.2020, being validly registered in ZooBank in advance (prospective
> registration). What will the community see? The community will see the pdf
> of paper 1 displaying the date of 01.01.2020 (because it was not edited,
> just like in Meierotto et al. 2019) and they will see the same information
> in ZooBank, 01.01.2020, because the person that wrote the entry in
> 04.01.2020 would have chosen 01.01.2020 manually in ZooBank. The community
> will also see the pdf of paper 2 displaying the date of 03.01.2020 and they
> will see the same information in ZooBank, 03.01.2020. Someone having to
> decide on the priority of the genus and/or the species, will deem the
> republished, later registered paper 1 as the one holding priority for three
> days over paper 2, when in fact it is paper 2 the one that has priority
> over paper 1 for one day. The result: The rightful author of paper 2 will
> be deprived of priority over his names and the true senior names will be
> put in synonymy with the junior names.
>
> How to hack ZooBank? It is possible to hack priority in ZooBank simply by
> selecting "This work has already been published" and manually entering a
> past date (retrospective registration). The resulting entry will look
> exactly like any other entry to the external users. The resulting LSID of a
> retrospective entry can then be copied and pasted into the reissued pdf,
> while the original pdf is wiped off. There is no difference between a
> prospective entry and a retrospective entry being shown by ZooBank. With
> current technology, it is totally possible to generate an LSID for a past
> date in ZooBank, display it as a past date and display that LSID and a past
> date on a newer pdf. A group of people could concertedly hack priority and
> make it look as it never happened. So no, your statement "The key point
> with a case like that described above is that ZooBank itself will record
> the date of registration as 04.01.2020" is incorrect. Internally, maybe,
> externally, we will see any date that was manually entered.
>
>
>
> Also, thank you for pointing out your concern with the "backdating
> problem" that you mentioned. I think that "backdating problem" is what I
> described and what you described is "delayed publication", something that
> we already have dealt with over centuries of printed publication. Maybe we
> need an analysis on delayed publication in the digital context.
>
>
>
> Cheers,
>
> Charlie
>
>
>
> El vie., 20 dic. 2019 a las 23:00, Stephen Thorpe (<
> stephen_thorpe at yahoo.co.nz>) escribió:
>
> Carlos wrote: 'What happens, for example, in the following case? An
> original online version is published on 01.01.2020 without being registered
> in ZooBank. On 04.01.2020, the publisher realizes the mistake, registers
> the publication in ZooBank, directly edits version 1, adds the ZooBank
> LSID, and reissues the paper but keeps the same date of 01.01.2020. Our
> community is nearly defenseless against something like this.'
>
>
>
> I don't see much point in me entering into a specific thread relevant to
> much wider concerns about the current state of zoological nomenclature (it
> is just one issue amongst thousands), however I will answer the above
> question. The stated date on a publication does not have to be correct.
> There needs to be a date specified, but it is not required to be correct.
> The key point with a case like that described above is that ZooBank itself
> will record the date of registration as 04.01.2020 and so, all other things
> being equal, that will be the actual date of (electronic) publication, even
> if  the date on the publication is 01.01.2020.
>
>
>
> However, a slightly more disturbing possibility is that something like
> this might happen: the date on the publication is 01.01.2020, the date of
> ZooBank registration is 04.01.2020 (and the stated date of publication on
> ZooBank is 01.01.2020 or 04.01.2020), but the publication didn't actually
> go online until 10.01.2020 and there is nothing on the publisher website to
> indicate the date that it actually went online. I'm not sure how the actual
> publication date could be determined down the track?? Anyone? We can call
> this a "backdating problem".
>
>
>
> Stephen
>
>
>
> On Friday, 20 December 2019, 07:40:19 pm UTC, Carlos Alberto Martínez
> Muñoz via Taxacom <taxacom at mailman.nhm.ku.edu> wrote:
>
>
>
>
>
> Hi Rich,
>
> Sorry if my writing confused you, English is not my mother tongue. Please,
>
> note that my example is not based on versions "of an unpublished work prior
>
> to the first edition of the work that fulfills the requirement for
>
> publication under the Code". My example is based on two formally published
>
> online versions, which in the opinion of the publishers and authors
>
> fulfilled the requirements of the Code until Stephen Thorpe highlighted
>
> that it was not so. The first pdf version that I am mentioning is an
>
> official one and it was online for a few days until it was reissued.
>
> It is clear to me that ZooBank LSIDs are not required for different
>
> unpublished versions but just when a final working version becomes a
>
> publishable work and is indeed published. What I am discussing is the fact
>
> that there were two published and supposedly Code-compliant versions that
>
> were not labeled as such, one being eliminated and disappearing leaving no
>
> other trace than the few pdfs that were quickly downloaded after
>
> publication by DEZ, and that those two published versions did need ZooBank
>
> LSIDs.
>
> Again, the online version not being clearly labeled as v2 is also contrary
>
> to *Recommendation 8D. Content immutable*. I will copy that here, since I
>
> didn't do it in my last email:
>
> Recommendation 8D. Content immutable. The content of a work is immutable
>
> once it is published. Corrections should be made through notices of errata
>
> or other separate publications. Second or other additional printings of a
>
> work should be clearly labeled as such, with date of publication stated in
>
> the work, even if no changes have been introduced.
>
> I have compared the two versions. The second version contains fixes to
>
> ZooBank links that were broken, figures 10 and 19 changed slightly,
>
> pagination on page headers was fixed from 119-146 (incorrect) to 119-145
>
> (correct). The tree on page 145 also changed slightly.
>
> In my opinion, that accounts for a different version, a scientific paper
>
> that was reissued instead of publishing a corrigenda to broken links, page
>
> headers, etc. It should have had another DOI and another ZooBank number.
>
> This is a very serious issue. We have walked a long way trying to make
>
> online publishing Code-compliant and more than that, as trustable as
>
> immutable paper print. But if post-publication, post-compliance changes are
>
> made and original versions vanish, that is a threat to Code compliance and
>
> trustability of the electronic publishing system as a whole.
>
> What happens, for example, in the following case? An original online
>
> version is published on 01.01.2020 without being registered in ZooBank. On
>
> 04.01.2020, the publisher realizes the mistake, registers the publication
>
> in ZooBank, directly edits version 1, adds the ZooBank LSID, and reissues
>
> the paper but keeps the same date of 01.01.2020. Our community is nearly
>
> defenseless against something like this. In my previous email and above I
>
> showed that original published versions can be wiped off. If we add that it
>
> is not possible to see who recorded what on which date in ZooBank (users
>
> and entry dates are not public), we have virtually no means to
>
> independently check for original compliance. In my example, everyone would
>
> believe that the version actually dates from 01.01.2020 and that the
>
> ZooBank registration was made anytime before that date.
>
> This also brings back the old question on how much change is acceptable
>
> change. I thought that we settled for zero change years ago. Maybe I'm
>
> wrong. If so, someone please explain to me and to the community how much
>
> change can occur before a version 1 is considered a version 2. One dot? One
>
> comma? One repaired link? One adjective? One full sentence? A forgotten
>
> ZooBank LSID?
>
> Anyway, as Stephen wrote long ago and as I confirmed, the pdf version(s) of
>
> that paper is not Code-compliant. I would very much like to know if there
>
> are printed versions already out, how many and in which public library I
>
> could access one. I have copied here Dominique Zimmermann, DEZ
>
> Editor-in-Chief. Maybe she could let us know if the names are already
>
> available from the printed edition or if still there are no printed copies
>
> out. We shouldn't be having discussions over unpublished names.
>
>
>
> A separate problem. I would also like to mention that the online version of
>
> DEZ seems to be issued under an incorrectly registered ISSN (
>
> https://portal.issn.org/resource/ISSN/1860-1324). It gives the key title
>
> "Mitteilungen aus dem Museum für Naturkunde in Berlin. Deutsche
>
> entomologische Zeitschrift". However, the last time I looked, the successor
>
> of the "Mitteilungen aus dem Museum für Naturkunde in Berlin" was not the
>
> DEZ but Zoosystematics and Evolution, now also edited by Pensoft. The ISSN
>
> of Zoosystematics and Evolution (
>
> https://portal.issn.org/resource/ISSN/1860-0743) does not show that
> journal
>
> as the successor of the "Mitteilungen". I hope that someone will correct
>
> those records soon. Otherwise they may end up polluting our bibliographical
>
> databases.
>
>
>
> Cheers,
>
> Charlie
>
>
>
> --
>
> Carlos A. Martínez Muñoz
>
> Zoological Museum, Biodiversity Unit
>
> FI-20014 University of Turku
>
> Finland
>
> ResearchGate profile
>
> <https://www.researchgate.net/profile/Carlos_Martinez-Munoz>
>
> Publons profile
>
> <https://publons.com/author/1324309/carlos-alberto-martinez-munoz#profile>
>
> Myriapod Morphology and Evolution
>
> <https://www.facebook.com/groups/205802113162102/>
>
>
>
>
> ---------------------------------------------------------------------------------------------------
>
>
>
> Message: 3
>
> Date: Fri, 20 Dec 2019 06:48:29 -1000
>
> From: "Richard Pyle" <deepreef at bishopmuseum.org>
>
> To: 'Carlos Alberto Martínez Muñoz' <biotemail at gmail.com>
>
> Cc: <taxacom at mailman.nhm.ku.edu>
>
> Subject: Re: [Taxacom] OMG! DNA only descriptions! - Round Two
>
> Message-ID: <00c301d5b755$4f54d340$edfe79c0$@bishopmuseum.org>
>
> Content-Type: text/plain;      charset="utf-8"
>
>
>
> Art. 8.5.3.3. The following are examples of *inadmissible errors*: (...) A
>
> publisher discovers errors in a work and *reissues it* to correct those
>
> errors, *but* instead of registering the new edition, *uses the original
>
> ZooBank number*; the revised edition is not available because it was not
>
> separately registered.
>
>
>
> This is a bit confusing and misleading. There may be dozens (hundreds?) of
>
> "editions" of an unpublished work prior to the first edition of the work
>
> that
>
> fulfills the requirement for publication under the Code. This is true for
>
> paper
>
> publications as well (draft manuscripts, reviewer copies, galley proofs,
>
> etc.).
>
> The existence of these prior unpublished (in the sense of the Code) works
>
> does
>
> not in any way impact the availability of a work that is eventually
>
> published in
>
> accordance with the Code. From the perspective of the Code, these previous
>
> unpublished editions do not exist, and therefore have no impact whatsoever
>
> on
>
> the existence of a later published work.
>
>
>
> For example, a ZooBank LSID is created for a work intended to be published
>
> electronically. That LSID appears within the galley proofs, which itself is
>
> not
>
> published in the sense of the Code. The work is later issued in a way that
>
> is
>
> Code compliant. The existence of the LSID within the galley proofs (un
>
> unpublished work) does not therefore require that the published edition
>
> must be
>
> registered anew.
>
>
>
> This is a simple example of a very complex problem that will be fixed in
>
> the 5th
>
> Edition; but the point is that the last example under Art. 8.5.3.3 (quoted
>
> above) can be very misleading. In a situation such as the one that has been
>
> described in this thread, we DO NOT WANT people to create a new
> registration
>
> record in ZooBank. That would only apply for a truly different work (like a
>
> corrigendum, which itself must contain all the elements necessary for
>
> conferring
>
> nomenclatural availability), but which itself is a completely different
> work
>
> from a previously "published" (but technically non-Code-compliant) work.
>
>
>
> But the fact that these examples exist underscores that the separation of
>
> requirements in two separate places (i.e., both within the work itself and
>
> within the ZooBank registration record) leads to myriad complexities, which
>
> are
>
> unintended consequences of the Amendment to the Code to allow for
> electronic
>
> publication. I'll stay off my usual soapbox on this point (for now).
>
>
>
> Aloha, Rich
>
> _______________________________________________
>
> Taxacom Mailing List
>
>
>
> Send Taxacom mailing list submissions to: taxacom at mailman.nhm.ku.edu
>
> For list information; to subscribe or unsubscribe, visit:
> http://mailman.nhm.ku.edu/cgi-bin/mailman/listinfo/taxacom
>
> You can reach the person managing the list at:
> taxacom-owner at mailman.nhm.ku.edu
>
> The Taxacom email archive back to 1992 can be searched at:
> http://taxacom.markmail.org
>
>
>
> Nurturing nuance while assaulting ambiguity for 32 some years, 1987-2019.
>
>
>
> --
>
> Carlos A. Martínez Muñoz
>
> Zoological Museum, Biodiversity Unit
>
> FI-20014 University of Turku
>
> Finland
>
> ResearchGate profile
> <https://www.researchgate.net/profile/Carlos_Martinez-Munoz>
>
> Publons profile
> <https://publons.com/author/1324309/carlos-alberto-martinez-munoz#profile>
>
> Myriapod Morphology and Evolution
> <https://www.facebook.com/groups/205802113162102/>
>
>
>
>
>
>
>
> --
>
> Carlos A. Martínez Muñoz
>
> Zoological Museum, Biodiversity Unit
>
> FI-20014 University of Turku
>
> Finland
>
> ResearchGate profile
> <https://www.researchgate.net/profile/Carlos_Martinez-Munoz>
>
> Publons profile
> <https://publons.com/author/1324309/carlos-alberto-martinez-munoz#profile>
>
> Myriapod Morphology and Evolution
> <https://www.facebook.com/groups/205802113162102/>
>
>
>
>
>


-- 
Carlos A. Martínez Muñoz
Zoological Museum, Biodiversity Unit
FI-20014 University of Turku
Finland
ResearchGate profile
<https://www.researchgate.net/profile/Carlos_Martinez-Munoz>
Publons profile
<https://publons.com/author/1324309/carlos-alberto-martinez-munoz#profile>
Myriapod Morphology and Evolution
<https://www.facebook.com/groups/205802113162102/>