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?