feature request #5697
closedShow name conserved against as [non xxx]
100%
Description
Currently only later homonyms, treated as later homonyms and is blocking name for are shown as [non xxx] in the dataportal.
[non xxx] may also be required for name relationship xxx conserved against yyy. The relationship should be shown if xxx is part of the synonymy. So it is the same direction as for later homonyms and the opposite direction as for "is blocking name for".
Maybe it is even better to implement it in both directions as the other way round it has more or less the meaning of "is blocked by".
As an example check Cuba Checklist:
Bulbostylis pauciflora (Liebm.) C. B. Clarke, nom. cons. [ non Bulbostylis pauciflora (Kunth) DC., nom. rej.]
This implementation should be optional (administratable by the admin) as other portals may want other solutions, e.g. annotations as described in #4177).
This solution requires that the related names (or at least one of the names) have/has the status nom. cons. or nom. rej. attached. Otherwise it can be misunderstood as "is blocked by" relation with opposite meaning
Related issues
Updated by Andreas Kohlbecker over 8 years ago
part one implemented: 6421984 r27714 display of nameRelationShipTypes configurable
the display of Oncostylis pauciflora now is like:
Oncostylis pauciflora Liebm. sec. Flora of Cuba [non Bulbostylis pauciflora (Liebm.) C. B. Clarke]
the nomenclatural status of both names are missing. Either this is a probelm with the web service or missing data.
Updated by Andreas Kohlbecker over 8 years ago
- Target version changed from Unassigned CDM tickets to Release 4.0
Updated by Andreas Kohlbecker over 8 years ago
- Priority changed from New to Priority14
Updated by Andreas Kohlbecker over 8 years ago
- Assignee changed from Andreas Kohlbecker to Andreas Müller
The status actually seems to be missing in the data http://api.cybertaxonomy.org/flora_cuba/portal/name/6b7cef15-1e9c-45ca-bc44-207b166231c2/status.json
Updated by Andreas Kohlbecker over 8 years ago
bugfix for the commit (6421984 [r27714|) : 6aa5dc6 r27715]
Updated by Andreas Kohlbecker over 8 years ago
- Status changed from New to Resolved
last bug fix : 72e0e4a r27721
Updated by Andreas Müller over 8 years ago
The nomenclatural status itself for both names is not shown, but is available in the data. Maybe duplicate #5720
This is a copy from TaxEditor: Bulbostylis pauciflora (Liebm.) C. B. Clarke, nom. cons.
Updated by Andreas Kohlbecker over 8 years ago
this was due to a fixing bug in render path management : cdm-dataportal 71acbd6 r27752
Updated by Andreas Müller over 8 years ago
- Assignee changed from Andreas Müller to Andreas Kohlbecker
The status is still missing in the portal, though it exists in the data: http://api.cybertaxonomy.org/flora_cuba/portal/name/69ef933d-70ff-48b9-a86e-3d9391669838/status.json
http://api.cybertaxonomy.org/flora_cuba/portal/name/7e50e9c4-1626-483e-b163-b52e691e7abd/status.json
But the status type is missing in the web services as it looks like. Maybe this is the reason.
Updated by Andreas Müller over 8 years ago
Also in the new user interface for choosing name relationships a hint is missing that these will be shown as "non xxx" which is an abbreviation that may count for certain relationships but not all. E.g. if relationship is "is Alternative name for" one may want to show this but not with a "non".
Also it is not yet possible to choose the direction of the relationship. Most "non" relationships should be shown only in one direction (e.g. the earlier homonym should be shown but not the later homonym).
Updated by Andreas Kohlbecker about 8 years ago
- Assignee changed from Andreas Kohlbecker to Andreas Müller
now that the dataportal installation problems on edit-production are solved the "non xxx" are no longer missing:
http://portal.cybertaxonomy.org/flora-cuba/cdm_dataportal/taxon/3368d326-afe7-414f-841a-4f182010fd1e
The "non" relationships are shown only in one direction ( later homonyms, treated as later homonyms and is blocking name ), this is currently hardcoded. Please open a new ticket if this should be completely flexible and configurable.
Updated by Andreas Müller about 8 years ago
- Assignee changed from Andreas Müller to Andreas Kohlbecker
Generally this ticket is fixed, but there are a few related open issues:
the related name (name behind "non" does not yet show a status if a status exists). This is probably because it only shows the title cache, not the full title cache. The status is part of the full title cache. Maybe we also need discussion with users, if the status is wanted, before we spend time for implementation
the current implementation is only for "non" names. At the same time many of the available name relationship types will never be displayed by "non". E.g. alternative names, orthographic variants, basionyms, replaced synonyms, validated by, later validated by, etc.. If this section is meant ONLY for "non" names we should remove these from the list as they are misleading.
the data portal admin section should give some short explanation that it handles the "non" name relationships, not name relationships in general. E.g "Name relationships shown as "Aus bus (non Aus cus)" or some better name parts.
if we keep the hard coded version with only one direction we should rename "is blocking name for" to "is blocked by". This is consistent with the other relationships where the right part ("to part") of the relationship is shown behind the "non" while the left part ("from part") is shown in front
as mentioned above we could allow selecting directions, but maybe we should wait with it until there is an explicit requirement for this
generally we may want to implement additional name relationships. E.g. "has original spelling" is usually displayed like "Aus bus 'buus'". Maybe we need a cache strategy for this. Ask users if there are other rules like this for other relationships.
Please feel free to decide which of the above issues should go into a separate ticket and what can be done on the fly within this ticket.
Updated by Andreas Müller about 8 years ago
Many of the above issues are more related to #4177 then to this ticket.
Updated by Andreas Kohlbecker about 8 years ago
- Status changed from Resolved to Closed
- Resolution set to fixed
- % Done set to 100
Updated by Andreas Kohlbecker over 5 years ago
- Description updated (diff)
- Private changed from Yes to No
Updated by Andreas Müller about 5 years ago
- Copied to task #5856: [DISCUSS] Consider implemeting additional name relationships added