- Table of contents
- EDIT - WP5 Taxonomic Editor Workshop
EDIT - WP5 Taxonomic Editor Workshop¶
February 21-22, 2008¶
Botanic Garden and Botanical Museum Berlin-Dahlem (how to get there)¶
The workshop was held at the BotanicGardenBerlin to discuss how best to design a new generation of TaxonomicEditor software improving the taxonomic work process and in particular the management of taxonomic concepts.
Following is an overview of the topics discussed during the workshop. The results of the workshop can be viewed here
Editor Workshop Topics¶
1 Concept editing¶
The Berlin Model editor offers 64 different pure concept relationship types between taxa (all combinations of the five basic relations and a doubtful flag). However, combinations of concept relations have never been used. Should we offer more simple relationship types by default and let users choose more complex concept relation types in a preference section?
The Berlin Model editor shows for a given taxon the list of directly related concepts. It never shows the next steps of taxon relations so that users would have to follow all the links individually to get an overview of the concepts directly and indirectly linked to the focussed taxon. So should there be a view on the concepts that is less list-oriented and more graph-oriented? Should this view be integrated into the editor for direct editing, or should this be an extra software/window just for display of the graph? Should there be a way of filtering the view on the concept graph (e.g. for specific references)?
Should there be a tool for bundling identical concepts? This could be a kind of box representing a taxonomic concept and users can drag and drop identical concepts into the box. The software would then perform the time consuming setting of the individual relations automatically.
Should it be possible to edit â€œforeignâ€ concepts, which do not belong to the userâ€™s treatment? Probably not, because this could change the concept and invalidate existing relations to this concept. But should it be possible to add information (may be as an annotation), which does not change the concept? In this case a notification could be sent to all â€œusersâ€ of the annotated concept. Which modifications or additions do change a taxonomic concept?
How are objects in general and concepts in particular delimited? For example: If the authorship of a name has been corrected, does this change all concepts using this name? Do we have to send a notification for each of them? If so, an import of an author-list could probably cause tens of thousands of notifications.
2 Hierarchies and synonymies¶
Changing a taxon status from synonym to accepted usually involves an operation which changes the former accepted taxon into a synonym of the new accepted taxon. This operation could probably be automated by default and users can choose to switch off the default operation.
Changing a status from accepted to synonym is probably more complex as accepted taxa may have synonyms, included taxa (and their synonyms) as well as linked factual data. With the present Berlin Model editor this operation involves many steps of moving synonyms, facts, and included taxa individually. Can we automate this procedure at least partly? For example should synonyms of the formerly accepted taxon be linked as synonyms to the new accepted taxon by default? Could synonyms of sub-taxa be moved to sub-taxa of the new accepted taxa by default? Could we then move the factual information automatically? Should the editor suggest a list of possible automated actions so that users can accept or reject them individually or collectively?
Moving taxa is even worse, because this operation can involve name changes of the given taxon and its sub-taxa (for species and below). Automatically generated taxon names may be incomplete because of missing authors and nomenclatural citations. Automatically generated sub-taxa may also conflict with already existing taxa. Again, full automation does not seem to be very promising but a suggestion list could be of help.
Grouping of synonyms could be user-friendlier. Synonyms having the same type could be represented in a box showing the basionym within this group bold in the first line for example. Re-arranging synonyms within a box and moving synonyms from one box to the other could be done with drag and drop operations. Setting the required and often complex name and taxon relations would be done by the software and not by users anymore.
3 Rights and roles¶
Which levels of rights are required from a user perspective? Hierarchically referring to the taxonomic hierarchy of a given project? Rights for specific object types (e.g. editing names, references, specific fact types, authors, etc.?). Rights might also depend on content (e.g. local experts having access rights to taxa occurring in a specific region).
Should the system support different taxonomic views within a single treatment? This could be useful if regional advisors want to modify taxonomic data for example. Alternatively, such modifications would be submitted as an annotation.
The Berlin Model as well as the CDM supports the use and linking â€œforeignâ€ concepts for example for the creation of concept relations or misapplied names. This requires a certain stability of the used concepts and the willingness to provide frozen versions of a taxonomic treatment even if it is not yet completed and contains errors. How can we implement versioning in a way that motivates taxonomists to provide versions even if they are not yet perfect?
Should there be a mechanism for adding content to taxa (e.g. images) for "external persons"? Is there an authority evaluating this content before publication?
4 Implicit behaviour¶
Should the system perform certain "implicit operations" automatically?
Example 1: Automatic synchronizing of relationship type with homotypic group - when a synonym is dragged into the same homotypic group, the synonym type is changed to HOMOTYPIC_SYNONYM and the homotypic group is updated to the taxon's homotypic group; when a synonym is removed from the taxon's homotypic group, it becomes a HETEROTYPIC_SYNONYM and assumes the homotypic group into which it is placed. In the CDM, these steps are kept separate, because synonym type is a property of a taxon or synonym, while homotypic group is a property of a name.
Example 2: Basionym authors - the user adds a name "Aaa bbb (Xxx) Yyy". Should the system eventually overwrite the author of the basionym name automatically, thus changing that name and taxa using it?
Example 3: Nomenclatural reference year. When adding a zoological name, the year of publication is part of the name. Changing the year of the namestring will therefore change the year of the publication, i.e. a separate reference object that might be used elsewhere.
Example 4: Basionym name relationship adds homotypic synonym relationship between the respective taxa too?
Presently, tools to display taxonomic data under revision are rather limited. The Berlin Model editor provides two different views: the usual single-taxon-oriented view displaying one taxon and all data directly associated with it. Secondly, the group view displays a hierarchical view on all taxa under revision but not information related to them. More reporting and display options would certainly be of great help for the taxonomic work process.
Possible views could be:
Display of an entire taxonomic group at a user-defined level of detail (e.g. including synonyms and specific facts).
Display all changes between two specific points in time.
Display all objects having a specific marker set (e.g. all references having a marker â€œnot ye checkedâ€).
Display differences between to versions or views of the same taxonomic group.
Display a list of â€œsuspiciousâ€ objects.
6 Linking factual data¶
The Berlin Model as well as the CDM tries to link factual data (e.g. distributional data) to the concepts, which are the sources of the original data. With this the source of information is always transparently documented. In practice this principle has never been fully implemented and users have linked facts to their own concept giving the reference of the source rather than creating a potential taxon with this reference and linking the fact there. How could the editor software support the creation of potential taxa and linking facts to them? How could the editor summarize the facts and display them together with the userâ€™s taxon? This would probably require a transmission engine, which works on the fly. How can factual data be aggregated if the data standards used in the sources are not compliant (e.g. different distribution formats used in different floras)?
If objects have duplicates (e.g. multiple instances of the same name which were not detected during the import), how can users decide, which object is the right one? How much information do we have to show to support this decision?
Are there integrity checks which should be offered to the user? Such checks could be used to identify problems not or not yet "absorbed" by the model itself.
Should there be a technique for performing recurring sequences of actions (a kind of simplified macro programming)?