task #9940
openHandle type category formatting in compact typification strings
0%
Description
In #6865 a separator was added between collection code and collection number.
For single derived units an according formatting was implemented. As described in #6865#note-11 the formatting strategy used there is not well applicable for compact type strings that include typification information (e.g. "holotype") and duplicates (e.g. holotype + isotype) in 1 line.
Therefore we need a different formatting strategy.
Formatting suggestions were made in the early ticket #461. However, none of these examples includes collection code AND accession number (except for the example by IB in #461#note-13 which uses abbreviated type categories such as ST for syntype which do not require a trailing colon but are not well accepted by others).
Another suggestion (by FdAC) was to put the type category behind collection code/number separated by comma (#461#note-27).
The problem is partly solved if the main typification (e.g. holotype) is put in front as suggested in in #461#note-6. However, this does not solve the problem if >1 types are mentioned in the string as e.g. for the syntypes we still need a separator.
Compact type formatting is done in the TypeDesigantionWorkingsetFormatter class. (#9596)
Related issues
Updated by Andreas Müller 12 months ago
copied from #6865:
AM:
ein kleiner Nachtrag hierzu:
das Ticket ist jetzt gefixt und das Ergebnis kommt mit dem nächsten Release. Allerdings gibt es bei der kondensierten Darstellung von Typen noch Unklarheit.
Also z.B.
Timaviella dunensis Mikhailyuk & O.Vinogr. – Type: Germany, The coast of the Baltic Sea, Usedom Island, vicinity of Zempin, 54°4'17"N, 13°58'4"E, 8 Oct 2013. (holotype: KW KW-A-32531)
Quelle: https://www.phycobank.org/cdm_dataportal/name/71898bd8-1a6c-42e7-9838-3a1600299ab9/null/null/
Wenn wir hier hinter das erste KW auch einen Doppelpunkt setzen, sieht das seltsam aus.
Gibt es dafür Vorschläge, wie man es besser machen kann?
Das wäre auch für die in Zukunft noch zu optimierende Darstellung von Typusbelegen auf den Taxonseiten relevant.
Updated by Andreas Müller 12 months ago
- Has duplicate feature request #9937: Separator for code and accession number in TypeDesignationWorkingsetFormatter added
Updated by Andreas Müller 12 months ago
- Related to feature request #461: Improve / compact display of types added
Updated by Andreas Müller 12 months ago
- Related to feature request #2506: (Type-) Specimens may need status added
Updated by Andreas Müller 12 months ago
- Tags changed from specimen, formatting, type designation to specimen, formatting, type designation, phycobank
Updated by Andreas Müller 12 months ago
- Copied from feature request #6865: [DISCUSS] Separator for Code and Accession Number added
Updated by Andreas Müller 12 months ago
- Copied to bug #6297: [Overview] BGBM User group wishes 2017 added
Updated by Andreas Müller 12 months ago
- Copied to feature request #9596: Open issues for TypeDesignationWorkingSet added
Updated by Andreas Müller 12 months ago
- Related to task #9941: [DISCUSS] Formatting of type designation categories in compact type string added
Updated by Andreas Müller 12 months ago
AM:
Auch wenn wir die spezifische Typuskategorie nach vorne ziehen (#9941) bleibt das Problem für z.B. Syntypen ja bestehen. Welche Lösung könntet ihr euch dafür vorstellen?
Im Appendix IV des Codes (https://naturalhistory2.si.edu/botany/codes-proposals/display_new.cfm) gibt es die Lösung die auch Norbert vorgeschlagen hat, nämlich zur Trennung zwischen Collection Code und Accession Number „barcode“ oder „No.“ Zu verwenden. Wirklich schön ist das m.E. nicht da sehr unruhig, aber zumindest ist es klar. Gibt es andere gängige Lösungen? Wie wäre es mit Bis-Strich als Separator nach der Typuskategorie?
Updated by Andreas Müller 12 months ago
- Subject changed from Handle type category formatting and collection code<->accession number separation in compact typification strings to Handle type category formatting in compact typification strings
Updated by Andreas Müller 12 months ago
- Related to feature request #7081: Deduplicate type information in dataportal if 2 equal types exist added
Updated by Andreas Müller 12 months ago
- Copied to deleted (bug #6297: [Overview] BGBM User group wishes 2017)
Updated by Andreas Müller 12 months ago
- Copied to deleted (feature request #9596: Open issues for TypeDesignationWorkingSet)
Updated by Andreas Müller 12 months ago
- Related to bug #6297: [Overview] BGBM User group wishes 2017 added
- Related to feature request #9596: Open issues for TypeDesignationWorkingSet added
Updated by Andreas Müller 12 months ago
WHK:
eine Doppelung, wie in dem Beispiel ist nicht sehr häufig. Theotisch könnte man den Herbariumcode in Fett ausgeben, wie das in einigen Journals gemacht wird, dazu würde ich aber gerne die Meinung meiner Kolleg:innen hören.
Updated by Andreas Müller 25 days ago
- Assignee changed from Andreas Müller to Belen Escobari
- Target version changed from Release 5.37 to Release 5.36
Updated by Andreas Müller 24 days ago
NoK:
all,
I strongly prefer the style with the main typification put in front because this is the least redundant one. Regarding the separator issues I meanwhile find the solution most agreeable that has been agreed on by the Editors of the Code, consistently used since some years in the Appendages of the Code, and has been taken over lately also by Willdenowia.
I think it would in fact make some sense to follow a style that is used by an authoritative source as the Code.
Here two examples from https://doi.org/10.3372/wi.52.52103
Holotype: Peru, Amazonas, Prov. Bongará, Dist. Yambrasbamba, Inmediaciones de la Estación Biologica Abra Patricia, 05°41′32.91″S, 77°48′41.1″W, 2320 m, 19–20 Feb 2020 (fl., fr.), R. Fernandez-Hilario, R. Villanueva & L. Pillaca 1930 (MOL barcode 000006!; isotypes: CUZ!, HOXA accession no. 077852!, NY barcode 04239398!, UPCB accession no. 99400!).
Holotype: Ecuador, Prov. Tungurahua, Cantón Baños, Parroquia Río Negro, Sector El Topo, Estación Cientifica Río Zuñac, Fundación EcoMinga, 01°22.593′S, 78°09.213′W, 1568 m, 26 May 2018 (fl., fr.), L. Jost, F. Recalde & S. Recalde 10600 (QCNE barcode 243978 [1/2], QCNE barcode 243977 [2/2]; isotype: QCNE barcode 243976)
Applied to a B example this would read:
Holotype: Borneo, Sabah, Sandakan Ramos 1490 (B barcode B 10 0018600 (presumed destroyed); isotypes: L, PNH).
Here an example from the Code Appendage, showing how this style handles more complicated cases (with icons as types and epitypes):
Fucus serra S. G. Gmel., Hist. Fuc.: 150. 1768 (Gelidium serra (S. G. Gmel.) E. Taşkin & M. J. Wynne).
Lectotypus (vide Taşkin & Wynne in Webbia 68: 22. 2013): [icon in] Buxbaum, Pl. Min. Cogn. Cent. 2: t. 8, fig. 3, 1728. Epitypus (vide Taşkin & Wynne in Webbia 68: 22. 2013): France, Pyrenées-Orientales, Banyuls-sur mer, Cap Beár, 29 Aug 1932, Feldmann (MICH).
(cont.):
Link for (stable) URI to digital representation of type specimens:
The specimen URI should be linked through the herbarium code (if no barcode or acc. number etc. available) or the entire expression (exemplified in blue):
Holotype: Peru, Amazonas, Prov. Bongará, Dist. Yambrasbamba, Inmediaciones de la Estación Biologica Abra Patricia, 05°41′32.91″S, 77°48′41.1″W, 2320 m, 19–20 Feb 2020 (fl., fr.), R. Fernandez-Hilario, R. Villanueva & L. Pillaca 1930 (MOL barcode 000006; isotypes: CUZ, HOXA accession no. 077852, NY barcode 04239398, UPCB accession no. 99400).
Updated by Andreas Müller 24 days ago
AM
vielen Dank für die Anmerkungen. Ich habe das auch so in Erinnerung und wir werden versuchen es so zu formatieren.
Wegen den Links: das müsste konfigurierbar werden. Grundsätzlich versuchen wir Links im CDM ja eher hinter die entsprechende Information als Icon zu setzen, statt den Text selber zu verlinken. Da hat man sonst zu viele Links. Zudem ist immer die Frage, ob man direkt auf die externe Quelle verlinken will oder erst auf die CDM Specimen Page. Da gibt es auch unterschiedliche Ansprüche je nach Kontext. Wie gesagt, dass sollte konfigurierbar werden und ist dann sicherlich das Finetuning nach der Gesamtumstellung.
Updated by Andreas Müller 24 days ago
By the way, the above notes from NoK are also handled in #9941 which is partly a duplicate for this ticket.