[Taxacom] A lost world in Wallacea

[Lynn Raw]

Richard wrote "the spectrum of immutability". Am I wrong in thinking that immutability is a single state rather than having a spectrum of different states? If something can be changed then it is not immutable. Maybe there needs to be a redefinition in the Code relating to electronic publications.
Lynn 

> On 18 Jan 2020, at 22:40, Richard Pyle via Taxacom <taxacom at mailman.nhm.ku.edu> wrote:
> 
> Hi All,
> 
> Denis wrote:
>> OK – the Supplement is a PDF, but NOT PDF/A, and is therefore as easily editable as a Word file. 
>> (Not that PDF/A files are actually not editable at all, but at least they have to be modified to make them so.) 
>> How does that affect its Code compliance?
> 
> I don't think it does. The relevant Code rule is:
> 8.1.3.2. [The work must have been produced by a method that assures] widely accessible electronic copies with fixed content and layout.
> 
> The example given is "PDF/A (Portable Document Format Archive), described by ISO Standard 19005-1:2005, is a file format that allows content and layout to be preserved unchanged."
> 
> So, PDF/A is not a requirement; just an example.  However, all electronic files are potentially alterable (including PDF/A), and the Code doesn't specify where on the spectrum of immutability (in terms of content and layout) a file format must be to comply with Art 8.1.3.2.  I shudder to think of the nomenclatural chaos that would ensue if a strict adherence to PDF/A were enforced, thereby rendering all electronic works that did not conform to this specific PDF/A (ISO 19005-1:2005) standard unavailable.  I have no idea how many exiting and otherwise available works would fail this criterion.  Such chaos is antithetical to the Code's core purpose of promoting nomenclatural stability.
> 
> Of course, that opens a potential Pandora's box of arguments that MS Word files or HTML files are somewhere on the immutability spectrum (in all cases, from PDF/A to raw text files, some sort of software tool is required to alter the files, and the Code is silent on where on this spectrum of available tools the line for assurance of "fixed content and layout" lies).
> 
> Donat wrote:
>> One way around it is to have the PDF in a trusted repository which locks 
>> the deposit and which would allow comparing the checksum of a version 
>> that seems to be modified in comparison to the original, or of course 
>> simply check it visually. For example, in this case the supplement 
>> https://doi.org/10.5281/zenodo.3608758 can not be changed anymore, 
>> so any copy can be checked whether it is the original or not.
> 
> And Brian wrote:
>> I agree with Donat Agosti. I have long felt there should be no problem with
>> the original description in pdf form being lodged with, say, Zoobank, at the
>> time of publication. There it would remain as unalterable but available.
> 
> I agree that having a within-ZooBank repository for PDFs would be wonderful.  Historically, there are three reasons why this hasn't been done (yet):
> 1) It would require more robust server infrastructure (particularly storage space) than ZooBank has historically had access to.
> 
> 2) It would require some careful thought and wording for what the exact rule was, and how it would be enforced. How many digital formats would be allowed for uploading? Only PDFs? A defined set of file formats? Any digital file? What happens in cases where no file is uploaded -- automatically unavailable? Or would there be allowable exceptions? What about if someone uploads a file that is corrupt? What about when someone uploads the wrong file by mistake? What about when someone uploads the wrong file deliberately? What happens in cases where some or all of the purported content is not included within the uploaded file? Would ZooBank (human or algorithm) need to verify the legitimacy of all uploaded files? Or would we just trust people (the way we trust that type specimens and copies of electronic works are deposited in their respective collections & archives)?
> 
> 3) There are potential copyright issues in play.
> 
> The solution to #1 is already in the works, and later this year should be resolved.  The solution to #2 could be incorporated into Code-5, as one of the discussion points.  I'm sure Donat has some thoughts on #3, and perhaps the concern here is not as great as once feared, especially if it's maintained as a "dark" archive.  However, it should be noted that the solutions to #2 and #3 may work against each other, especially if human evaluation of the deposited file is necessary to solve #2.
> 
> But here is my question:  The biggest headaches (by far) in both maintaining relevancy and reducing ambiguity of the Code all seem to revolve around "publication".  Indeed, the biggest change in the Code in recent years (perhaps in its history) has been the accommodation of electronic publications.  This created a lot of the headaches, but it's pretty obvious that it created far fewer headaches than would have been created had the Code not allowed for electronic publication.  Certainly, with the benefit of 20/20 hindsight, we now have some ideas for how to incrementally improve the situation with electronic publication, but the fundamental problems will remain as long as nomenclatural availability is split into two places (i.e., publication and registration), and there are thousands of publication venues with varying standards and practices.
> 
> Sure, creating a mandatory repository/archive within ZooBank would potentially solve a number of problems.  But as with so many previous attempts to improve problems with the Code (e.g., prevailing usage, accommodating "laser disks", accommodating electronic publication), each new "solution" introduces a new set of problems (some anticipated, some not).  In some cases (e.g., electronic publication), the net benefits exceed the net costs.  In others (prevailing usage?) maybe not so much.
> 
> Wouldn't the entire process of establishing nomenclatural availability in a way that is maximally objective and minimally ambiguous be greatly improved if all aspects of nomenclatural availability were consolidated in one system?  We've discussed this many times before, and as of the last ICZN Commissioners' meeting in Singapore last year, the door has been opened for provisions in Code-5 that would at least *allow* for this alternate pathway (i.e., nomenclatural availability encapsulated within the registration process, independent of traditional publication) to exist.  No doubt it will come with its own suite of new problems (some anticipated, some not); but I have a hunch that if done well (i.e., with careful forethought, and an built-in ability to improve the system in real time without requiring Amendments to the Code), the benefits of this approach will vastly exceed the costs.
> 
> Well, look at that! I made it through a full two and a half weeks before my first public rant on "registered=available" in the year 2020!  I must be getting old to have waited so long...
> 
> Aloha,
> Rich
> 
> Richard L. Pyle, PhD
> Database Coordinator | Associate Zoologist | Dive Safety Officer
> Bernice Pauahi Bishop Museum
> 1525 Bernice Street, Honolulu, HI 96817-2704
> Office: (808) 848-4115;  Fax: (808) 847-8252
> eMail: deepreef at bishopmuseum.org
> BishopMuseum.org
> 
> Our Mission: Bishop Museum inspires our community and visitors through the exploration and celebration of the extraordinary history, culture, and environment of Hawaiʻi and the Pacific.
> 
> 
> 
> 
> _______________________________________________
> 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.