EDIT

• taxonName: should everything be handled in typedLabel or in own DTO?
  • if we have an own dto, we can add rank and rankorder index, but maybe we only need the rank string if all ordering is done serverside

Is there done any ordering via ranks in the current taxon pages?

• specimen: could we reuse or reorganize the already existing derivedUnit/fieldunit dtos? They are already implemented for the use in dataportal
  • there are already methods implemented to get the specimen subtree for one taxon to get the data for the specimen tree view, they already return dtos

Can you leave a note which methods are used there?

There is a first implementation for the dataportal available, you can have a look if you exchange the taxon with newtaxon in the url, for example https://test.e-taxonomy.eu/dataportal/preview/cichorieae/cdm_dataportal/newtaxon/b335ceee-d6c1-4c93-841d-3b4bd279d855

Andreas Müller wrote in #note-26:

Katja Luther wrote:

• currently the facts are merged into the feature tree (see _mergeFeatureTreeDescriptions in cdm_api.module of the dataportal code), we should handle this similar when creating the dto

The webservice allows passing a parameter "featureTree". This will be used to order and filter the returned factual data accordingly. (implementing soon)

This is implemented now.

The dto for common name dtos are different to the other facts, therefore it is more difficult to handle it in a generic way. It is necessary to know where to find the type of the fact otherwise it is difficult to decide how to render the content.

For example for the common name there is no typedLabel.

I implemented basic error handling. So the message field can be evaluated now and empty results should not happen anymore.

To create the same html code like before it is necessary to provide the feature uuid for the descriptions.

The order of the (homotypic?) synonyms is not correct, for example for Aizoon hispanicum L.(Cyprus) the order of the synonyms should be

• Aizoanthemum hispanicum (L.) H. E. K. Hartmann
• Aizoanthemopsis hispanica (L.) Klak

but is the other way round.

Katja Luther wrote in #note-35:

To create the same html code like before it is necessary to provide the feature uuid for the descriptions.

I do not fully understand what you mean here. What is "the feature uuid for the description"? A description does not have feature. Do you mean fact/description element? Why can't you take this form the factual data tree which is ordered first by feature (including uuid) and then by it's attached factual data. So each facts has a feature uuid attached via it's "parent feature".
If this does not answer your request please add an example html to make clear how the feature uuid is used.

Andreas Müller wrote in #note-37:

Katja Luther wrote in #note-35:

To create the same html code like before it is necessary to provide the feature uuid for the descriptions.

I do not fully understand what you mean here. What is "the feature uuid for the description"? A description does not have feature. Do you mean fact/description element? Why can't you take this form the factual data tree which is ordered first by feature (including uuid) and then by it's attached factual data. So each facts has a feature uuid attached via it's "parent feature".
If this does not answer your request please add an example html to make clear how the feature uuid is used.

Sorry that was the wrong term, I meant the uuid of the feature of the facts. This should be added to the object containing the facts of one feature, actually only the label of the feature is contained.

Katja Luther wrote in #note-36:

The order of the (homotypic?) synonyms is not correct, for example for Aizoon hispanicum L.(Cyprus) the order of the synonyms should be

• Aizoanthemum hispanicum (L.) H. E. K. Hartmann
• Aizoanthemopsis hispanica (L.) Klak

but is the other way round.

Hmm, this is strange. The PortalDtoLoader uses a comparator (eu.etaxonomy.cdm.compare.taxon.TaxonComparator). This comparator results in the "newtaxon" ordering. Which in IMO is correct as the only difference between the 2 synonyms is the alphabetic string which should have Aizoanthemopsis before Aizoanthemum (no difference in date, rank or status). However, I can see that on the old taxon page AND in the taxEditor it is ordered the other way round.
Do you know which comparator is used e.g. in taxEditor or for the old pages? And if it is the TaxonComparator class which configuration it uses (with rank/without rank)? And could you debug the ordering in taxEditor to see why exactly it orderes the names the other way round?

Andreas Müller wrote in #note-26:

Katja Luther wrote:

• currently the facts are merged into the feature tree (see _mergeFeatureTreeDescriptions in cdm_api.module of the dataportal code), we should handle this similar when creating the dto

The webservice allows passing a parameter "featureTree". This will be used to order and filter the returned factual data accordingly. (implementing so

Andreas Müller wrote in #note-27:

Andreas Müller wrote in #note-26:

Katja Luther wrote:

• currently the facts are merged into the feature tree (see _mergeFeatureTreeDescriptions in cdm_api.module of the dataportal code), we should handle this similar when creating the dto

The webservice allows passing a parameter "featureTree". This will be used to order and filter the returned factual data accordingly. (implementing soon)

This is implemented now.

Also on portal side the usage of the feature tree parameter is implemented.

The status preference in condensed distribution string does not seem to work yet. For abies alba it shows cGa(F) while in production it is Ga(F). There is a native and a cultivated record for Ga(F)

Andreas Müller wrote in #note-40:

Katja Luther wrote in #note-36:

The order of the (homotypic?) synonyms is not correct, for example for Aizoon hispanicum L.(Cyprus) the order of the synonyms should be

• Aizoanthemum hispanicum (L.) H. E. K. Hartmann
• Aizoanthemopsis hispanica (L.) Klak

but is the other way round.

Hmm, this is strange. The PortalDtoLoader uses a comparator (eu.etaxonomy.cdm.compare.taxon.TaxonComparator). This comparator results in the "newtaxon" ordering. Which in IMO is correct as the only difference between the 2 synonyms is the alphabetic string which should have Aizoanthemopsis before Aizoanthemum (no difference in date, rank or status). However, I can see that on the old taxon page AND in the taxEditor it is ordered the other way round.
Do you know which comparator is used e.g. in taxEditor or for the old pages? And if it is the TaxonComparator class which configuration it uses (with rank/without rank)? And could you debug the ordering in taxEditor to see why exactly it orderes the names the other way round?

KL: Das scheint behoben zu sein, ich habe zumindest bei dem im Ticket angeführten Fall und noch einem anderen Taxon keine falsche Reihenfolge mehr gesehen.

mail AM:

ich habe dem Service jetzt noch einige wichtige Parameter spendiert, die meisten von distributionInfoFor kopiert. Könntest du versuchen, die entsprechend portalseitig zu übergeben.
Lediglich „hiddenAreaMarkerTypes“ habe ich in „fallbackArea….“ Umgenannt, da das inzwischen besser passt. Ist aber der gleiche Parameter.

Andreas Müller wrote in #note-73:

Name in source is now also shown if it is equal to the accepted name. That differs from the old version. I have not checked if this configurable or always the case.

this should be fixed

Andreas Müller wrote in #note-72:

nom. illeg. is now shown twice:

this should be fixed

Andreas Müller wrote in #note-98:

Looks like the name relationship filter is not yet implemented, neither on portal side when calling the webservice nor on server side

This was partly a mistake. The name relationships filter exists on dataportal side (php). Only the possible prefiltering serverside is not implemented yet. But this is a minor issue.

Andreas Müller wrote in #note-101:

However, taxon annotations are not yet shown but they were in old version. Maybe I was wrong when I was saying recently that they are also not implemented in the old version. So they should still be implemented before closing this ticket.

This is fixed.