[Taxacom] Electronic publication

Francisco Welter-Schultes fwelter at gwdg.de
Wed Jan 11 08:22:36 CST 2017


The term "date of publication" is defined in the Glossary:

*date of publication*, /n/. Of a work (and of a contained name and 
nomenclatural act): the date on which copies of the work become 
available by purchase or free distribution. If the actual date is not 
known, the date to be adopted is regulated by the provisions of Article 
21.2-7.

 From this definition I cannot extract a statement "if an electronically
published work does not state "day, month, year" it does
not meet the requirements of the Code".

In Art. 22 the term "date of publication" is clearly restricted to the 
year, as can be seen in all given examples. So the year appears to meet 
fully the requirement of the Code's term "date".

Francisco

Am 11.01.2017 um 15:01 schrieb Paul van Rijckevorsel:
> As to the matter of "date", I cannot agree with Richard Pyle
> about "how the Code is written". However, like he is, I am
> pretty much in agreement with Thomas Pape, but not quite.
>
> It is quite clear that the Code is written to mean that date =
> "day, month, year". Besides Article 21 which is clear on
> this, there is also Article 23 (23.3.4. and 23.9.2.): when it
> comes to establishing priority, a year is a pretty blunt
> instrument.
>
> And Article 8.5.2. does require to "state the date of
> publication in the work itself". So if an electronically
> published work does not state "day, month, year" it does
> not meet the requirements of the Code.
>
> It may have been the intent to operate by analogy of the
> new Article 8.5.3.3. but that is not "how the Code is written".
> And frankly, it seems dubious if it would be a good idea
> to do so. If Article 21.3. would apply here, so would 21.4.
> That would leave the publisher the freedom to put "2017"
> in as date for something published today, or "2020", or
> anything. The requirement would be quite pointless.
>
> It might be a good idea to add a provision allowing for
> a date to be slightly wrong, say a day off, or for a typo
> in the name of the month, but it would have to be carefully
> worded. Also, this is a "might": it is not very much to ask
> of a publisher to get a date right, after all.
>
> Paul
>
> ----- Original Message ----- From: "Richard Pyle" 
> <deepreef at bishopmuseum.org>
> Sent: Tuesday, January 10, 2017 9:09 PM
> [...]
>>> It is the practice of many publishers to include only the year of
>>> publication. To me this is contrary to what the Code states and 
>>> therefore
>>> any
>>> electronic works that include only the year of publication  in the
>>> article itself
>>> are unavailable.
>>
>> That is not how the Code is written, though.
>>
>> Art. 8.5.2:  "state the date of publication in the work itself"
>>
>> Art 21: "Determination of date"
>>
>> Glossary:
>> date of publication, n.
>> Of a work (and of a contained name and nomenclatural act): the date on
>> which copies of the work become available by purchase or free
>> distribution. If the actual date is not known, the date to be adopted is
>> regulated by the provisions of Article 21.2-7.
>>
>> The word "date" here is used consistently.  Therefore, there is no basis
>> within the Code to hold the word "date" in Art. 8.5.2 to a different
>> standard than "date" as used elsewhere in the Code.  Thus, Art. 21.3
>> applies when only the year is stated.
>>
>> Perhaps your contention is that the requirement for electronic works
>> *should* require a higher standard, perhaps a term such as "actual date"
>> (as used in the glossary definition).  We could certainly debate that 
>> for
>> the next edition of the Code, but I don't see how you can apply it to 
>> the
>> existing code, and thereby declare electronic works which only state the
>> year as being unavailable under the existing Code.
>>
>> Also, there is nothing in the existing Code that requires the date 
>> stated
>> within the work itself to be accurate.  As with stated dates in paper
>> works, the date of publication (for purposes of priority) is the date
>> indicated in the glossary definition, and may not agree with the stated
>> date.  In such cases, we have Art. 21.4, and I see nothing in the 
>> Code to
>> suggest that this article doesn't apply equally to electronic works and
>> paper-printed works.
>>
>>> Many have argued against this saying the year is sufficient
>>> and that this is covered by Article 21 in the fourth edition of the 
>>> Code.
>>> I
>>> would argue that Article 21 of the Code implicitly states that the date
>>> must
>>> include the day, month and year for the purposes of nomenclature and
>>> determining priority
>>
>> Can you elaborate on this?  There are two things at play here:
>> 1) The date (day) on which a work is deemed to be available (for 
>> purposes
>> of priority); and
>> 2) The requirement of what information must be included within a 
>> published
>> work itself (Art. 8.5.2)
>>
>> We can certainly debate what *should* be required in the next edition of
>> the Code, but I cannot see anything in the existing Code that suggests
>> that the requirement of Art 8.5.2 implies that a specific day must be
>> indicated within the work itself, nor that the indicated day/date 
>> must be
>> accurate.
>>
>>> Any future edition of the code, where publication date is given this
>>> level of
>>> importance, must explicitly define what is meant by date to prevent
>>> future
>>> ambiguity.
>>
>> One of the big advantages of the "Registered=Available" model that I 
>> have
>> been advocating is that "date" can be objectively and consistently
>> established to the millisecond.  Never again would there be any time or
>> energy spent on trying to determine the correct date (time) for purposes
>> of nomenclatural priority.
>>
>>> 21.8.3. Some works are accessible online in preliminary versions before
>>> the
>>> publication date of the final version. Such advance electronic access
>>> does
>>> not advance the date of publication of a work, as preliminary versions
>>> are
>>> not published (Article 9.9). An advance publication  (e.g. “version of
>>> record”)
>>> of a journal article may be considered available only if the article
>>> itself
>>> contains the volume number of that journal in which the article will be
>>> contained and identical  pagination to the final version.
>>
>> I see this as yet another band-aid on a large glob of band-aids to a
>> problem that is only going to get worse over time.  In the era when
>> substantial financial outlay was required to produce numerous durable
>> identical copies of a paper work, ambiguities were far less common.  
>> Now,
>> with the ability to generate micro-refined versions of any work on the
>> scale of minutes (or seconds?), nailing down the exact "moment" a work
>> (and it's names/acts) became available is increasingly ambiguous.  We 
>> can
>> solve all of this growing mess by divorcing the legalistic action of
>> establishing a name as available from the messy, heterogenous, and 
>> utterly
>> chaotic process that we call "publication".
>>
>>> Apart from differing pagination and lack of volume number many so 
>>> called
>>> versions of record differ quite substantially in layout and content 
>>> from
>>> the
>>> final version. Where do we draw the line . . . .
>>
>> Indeed!  So let's just cut "publication" out of the nomenclatural
>> availability formula.
>>
>> If people are worried about quality control (as am I), then we simply
>> raise the bar for quality control *within* the Registered=Available
>> architecture.  Consider the advantages:
>> - ALL new names publicly visible, with open-access metadata.
>> - UNAMBIGUOUS date (timestamp to the nearest millisecond) for 
>> purposes of
>> nomenclatural priority.
>> - NO MORE arguments about whether (or when) a work conforms to the 
>> Code's
>> definition of "published".
>> - CENTRALIZED access to ALL new names
>> - HOMOGENEOUS application of quality control to ALL new names
>> - PERMANENT end to ALL future Homonymy
>> - CONSISTENT mechanism for designating a type specimen
>> ....and I could list a dozen more examples; but I trust I'm making my
>> point here.
>>
>> These are just some of the reasons why Registered=Available can be
>> unambiguously BETTER than the current publication-based system. So far,
>> the best argument against it is that it doesn't solve ALL of the 
>> EXISTING
>> problems (one of them being minimally-Code-compliant names).  I have yet
>> to see a rational argument for why it might actually be WORSE than the
>> status quo, or what NEW problems (that do not already exist) would be
>> created.
>>
>>> Yes, I have a bee in my bonnet about this, but if we continue to 
>>> publish
>>> nomenclatural acts in the current way, unless something is done soon we
>>> shall be building up problems for the future.
>>
>> I COMPLETELY agree!!!  :-)
>>
>> Aloha,
>> Rich
>>
>> _______________________________________________
>> Taxacom Mailing List
>> Taxacom at mailman.nhm.ku.edu
>> http://mailman.nhm.ku.edu/cgi-bin/mailman/listinfo/taxacom
>> The Taxacom Archive back to 1992 may be searched at:
>> http://taxacom.markmail.org
>>
>>
>> Nurturing Nuance while Assaulting Ambiguity for 30 Years, 1987-2017.
>>
>>
>> -----
>> Geen virus gevonden in dit bericht.
>> Gecontroleerd door AVG - www.avg.com
>> Versie: 2015.0.6201 / Virusdatabase: 4749/13739 - datum van uitgifte:
>> 01/09/17
>>
>
> _______________________________________________
> Taxacom Mailing List
> Taxacom at mailman.nhm.ku.edu
> http://mailman.nhm.ku.edu/cgi-bin/mailman/listinfo/taxacom
> The Taxacom Archive back to 1992 may be searched at: 
> http://taxacom.markmail.org
>
>
> Nurturing Nuance while Assaulting Ambiguity for 30 Years, 1987-2017.



More information about the Taxacom mailing list