[Taxacom] Electronic publication

Richard Pyle deepreef at bishopmuseum.org
Tue Jan 10 14:09:21 CST 2017

Hi John,

> I have always held that the date of publication should include the day month
> and year. 

Do you mean this specifically in the context of Art 8.5.2 (electronic publications), or more generally for all published works?

> 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"

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!!!  :-)


More information about the Taxacom mailing list