Project

General

Profile

Actions

ConceptWorkshop » History » Revision 9

« Previous | Revision 9/20 (diff) | Next »
Anton Güntsch, 01/29/2008 05:52 PM



EDIT - WP5 Taxonomic Editor Workshop

February 21-22, 2008

Botanic Garden and Botanical Museum Berlin-Dahlem (how to get there)

The workshop will be held at the BotanicGardenBerlin to discuss on how best to design a new generation of TaxonomicEditor software improving the taxonomic work process and in particular the management of taxonomic concepts. Attendees will be users of the current Berlin Model Web Editor who deal in concept relations, namely Karol Marhold (Bratislava), Rudi May (BfN), Gerhard Ludwig (BfN), Walter Berendsohn (BGBM), Pepe Ciardelli (BGBM), Markus Döring (BGBM), Marc Geoffroy (BGBM), Andreas Müller (BGBM), and Eckhard Raab-Straube (BGBM).

All discussions / brainstorming in preparation for the workshop should be noted here. Please feel free to add any editor-related issue you would like to discuss during the workshop. Your input will directly influence the design of the next taxonomic editor based on the EDIT Common Data Model (CDM).

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?

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 given 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)?

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.?).

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?

4 Reports

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 to 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.

5 Miscellaneous

Should there be a technique for performing recurring sequences of actions (a kind of simplified macro programming)?

Are there integrity checks which should be offered to the user?

Updated by Anton Güntsch about 16 years ago · 9 revisions