Project

General

Profile

feature request #5697

Show name conserved against as [non xxx]

Added by Andreas Müller over 3 years ago. Updated 5 months ago.

Status:
Closed
Priority:
Priority14
Category:
cdm-dataportal
Target version:
Start date:
04/11/2016
Due date:
06/02/2016
% Done:

100%

Severity:
normal
Tags:

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

Copied to Edit - task #5856: [DISCUSS] Consider implemeting additional name relationships New 06/02/2016

Associated revisions

Revision 1636cc86 (diff)
Added by Andreas Kohlbecker 5 months ago

fixing regression ref #5697: including conserverd against in non ... nec ... , ref #4177 removing dom block from inline name rels

History

#1 Updated by Andreas Müller over 3 years ago

  • Keywords set to Cuba

#2 Updated by Andreas Kohlbecker over 3 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.

#3 Updated by Andreas Kohlbecker over 3 years ago

  • Target version changed from Unassigned CDM tickets to Release 4.0

#4 Updated by Andreas Kohlbecker over 3 years ago

  • Priority changed from New to Priority14

#5 Updated by Andreas Kohlbecker over 3 years ago

  • Assignee changed from Andreas Kohlbecker to Andreas Müller

#6 Updated by Andreas Kohlbecker over 3 years ago

bugfix for the commit (6421984 [r27714|) : 6aa5dc6 r27715]

#7 Updated by Andreas Kohlbecker over 3 years ago

bug fix : e4ccc0a r27719

#8 Updated by Andreas Kohlbecker over 3 years ago

next bug fix: 59b5e2e r27720

#9 Updated by Andreas Kohlbecker over 3 years ago

  • Status changed from New to Resolved

last bug fix : 72e0e4a r27721

#10 Updated by Andreas Müller over 3 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.

#11 Updated by Andreas Kohlbecker over 3 years ago

this was due to a fixing bug in render path management : cdm-dataportal 71acbd6 r27752

#12 Updated by Andreas Müller over 3 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.

#13 Updated by Andreas Müller over 3 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).

#14 Updated by Andreas Kohlbecker over 3 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.

#15 Updated by Andreas Müller over 3 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.

#16 Updated by Andreas Müller over 3 years ago

Many of the above issues are more related to #4177 then to this ticket.

#17 Updated by Andreas Kohlbecker over 3 years ago

  • Status changed from Resolved to Closed
  • Resolution set to fixed
  • % Done set to 100

all the above issues are now in separate tickets: #5857 #5856 #5855

#18 Updated by Andreas Kohlbecker 5 months ago

  • Description updated (diff)
  • Private changed from Yes to No

#19 Updated by Andreas Kohlbecker 5 months ago

  • Description updated (diff)

#20 Updated by Andreas Müller 5 months ago

  • Copied to task #5856: [DISCUSS] Consider implemeting additional name relationships added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)