EDIT

AM:

Wenn es für ein Areal Unterareale gibt und diese haben einmal einen indigenous und einmal einen „foreign“ Status, dann soll das Areal 2x aufgeführt werden, einmal im indigenous Bereich und einmal bei foreign, korrekt? Beispiel Uk auf http://ww2.bgbm.org/EuroPlusMed/PTaxonDetail.asp?NameCache=Crepis%20capillaris&PTRefFk=7000000 , dort kommt -Uk(K) und UK(U) getrennt vor.
Das ist vermutlich korrekt so und soll so ein? (abgesehen davon, dass Uk glaube ich inzwischen nicht mehr Überareal der beiden Areale ist, aber mir geht es nur ums Prinzip)

ERS:

ja, das ist richtig so. Wüsste nicht, wie man es sinnvoll anders machen sollte.

Diskussion mit AK über handling des CondensedDistributionString im Portal:

Derzeit werden Teile des Strings hardcodiert im Portalcode erzeugt, wie z.B: die Klammer um die "foreign" Informationen. Um eine einheitliche Darstellung des Strings über alle Publikationsmedien hinweg zu erreichen, sollte dies vermieden werden und der String komplett vom CondensedDistributionComposer erzeugt werden.
Um in Zukunft aber interaktive Zusatzinformationen (z.B. über MouseOver) zu Teilen des Strings zu ermöglichen, sollte in einem weiteren Schritt aber eine TaggedText ähnliche Ausgabe angestrebt werden.

Weiterhin sollten Formatierungsinformationen mit Informationsgehalt wie die fette darstellung von Arealen, die besagt, dass es sich hier um ein natives Vorkommen handelt, nicht einzig über clientseitige Formattierungen implementiert werden sondern sollten Teil des Strings bzw. später des TaggedText sein. Z.B. könnte das durch Verwendung des HTML Tag im Text erreicht werden, auch wenn dieser innerhalb von HTML eher deprecated ist. Es könnte aber auch irgendein anderer eindeutiger Markierer verwendet werden. In der TaggedText Variante kann dies durch ein TaggedText Attribut einfach implementiert werden.

Noch nicht diskutiert wurde die Hinterlegung der projektspezifischen Konfigurationsparameter, die z.B. in den CdmPreferences erfolgen könnte.

ERS (2020-06-23):

Unterareale sollten ja eigentlich in Klammern nach dem Hauptareal zusammengefasst werden, also das Hauptareal nicht wiederholt. Das ist jetzt zum Teil richtig, zum Teil falsch (siehe z.B. Gänseblümchen https://europlusmed.org/cdm_dataportal/taxon/0eb6ca37-3365-4af5-a800-8fc4b8c366fa

Richtig ist:

Au(A L)
Be(B L)
Hb(E N)
Hs(A S)
Ju(BH Cg Ct Sl Sr)
Falsch ist:
AE(G) AE(T) => AE(G T)

Ga(C) Ga(F) => Ga(C F)

Rf(C) Rf(CS) Rf(E) Rf(K) Rf(N) Rf(NW) => Rf(S) Rf(C) Rf(CS) Rf(E) Rf(K) Rf(N) Rf(NW) Rf(S)
Tu(A) Tu(E) => Tu(A E)

Überflüssig ist es auch, die Statusangabe immer zu wiederholen, wenn sie für alle Unterareale gleich ist.

Also: nAz(J M S T)
nicht: nAz(nJ nM nS nT)
und die -●EM-Angabe sollte nach vorne gerückt werden.

Ab(A) AE(G) AE(T) Al Ar Au(A L) Be(B L) Bl(N) Br Bu By Co Cr Cs Cy Da -●EM Ga(C) Ga(F) Ge Gg Gr Hb(E N) He Ho Hs(A S) Hu Ir ??Is It Jo Ju(BH Cg Ct Sl Sr) Le Lu Ma Md ??Md(M) ??Mk Mo dNo Po Rf(C) Rf(CS) Rf(E) Rf(K) Rf(N) Rf(NW) Rf(S) Rm Sa Si(S) dSi(M) Sk ??Su Sy Tu(A) Tu(E) Uk(Cm U) [nAz(nJ nM nS nT) nEs nFa nFe nLa nLt]

AM:

für folgende Status bräuchte ich noch die korrekten Symbole:

• native: reported in error => „-“ ? Genauso wie introduced: reported in error? Soll das dann ein minus sein oder ein längerer Strich? 6446 Fälle

• native: formerly native => ist das der extinct Fall „†“ aus https://dev.e-taxonomy.eu/redmine/issues/3907 (759 Fälle)

• introduced: doubtfully introduced (perhaps cultivated only) => “d” ? (826 Fälle) Beispiel: Ageratum houstonianum

Damit würden sich dann folgende Symbole für die genutzen Verbreitungsstatus ergeben:

"titleCache" "symbol2"
"endemic" "●"
"native"

"native: doubtfully native" "d"
"naturalised" "n"
"casual" "a"
"introduced: uncertain degree of naturalisation" "p"
"introduced"

"introduced: doubtfully introduced (perhaps cultivated only)" "d"
"native: presence questionable" "?"
"introduced: presence questionable" "?"
"cultivated" "c"
"not endemic" "-●"
"unknown endemism" "?●"
"native: formerly native" "†"
"native: reported in error" "-"
"introduced: reported in error" "–"
"undefined" "??"

SELECT  st.titleCache, st.symbol2  -- ,  st.id, tb.titleCache, COUNT(*) AS n
FROM DescriptionElementBase deb 
INNER JOIN DescriptionBase db ON db.id = deb.inDescription_id
INNER JOIN TaxonBase tb ON tb.id = db.taxon_id
LEFT JOIN DefinedTermBase st ON st.id = deb.status_id
WHERE deb.DTYPE = 'Distribution' AND deb.status_id -- AND st.id = 2083
 GROUP BY st.id
 ORDER BY st.orderIndex

ERS:

für native: reported in error gilt das gleiche wie für introduced: reported in error, ein Minus - vor dem Kürzel.

formerly native ist Extinct †", ja.

Und für not endemic oder unknown endemism würde ich keine Symbole verwenden, nur für endemic. Für not endemic ist es einfach nicht üblich, und für unknown endemism würde ich ungern auf unsere Lücken aufmerksam machen. Denn in den allermeisten Fällen (geschätzt 98%) ist es so, dass man den Endemismus-Status kennt, der Bearbeiter nur nicht genügend recherchiert hat. Bei ganz wenigen Taxa wäre dieser Status wirklich sinnvoll.

AM:

auf introduced: doubtfully introduced (perhaps cultivated only) bist du noch nicht explizit eingegangen in der Mail. Das “d” stimmt also?

ERS:

ja, das sollte stimmen. Gut, das man die Symbole über den Term-Editor anpassen kann.

Andreas Müller wrote:

An open issue:

... sollen im CondensedDistributionString für die Überareale jeweils nur die Unterarealstatus ausgegeben werden, auch wenn es einen abweichenden Status für das Überareal gibt? Also im konstruierten Fall „?Bl(I dM)“ das ? weglassen? Bisher habe ich das so implementiert, dass NUR im Fall, dass sowohl alle Unterareale UND das Hauptareal den gleichen Status haben, der Status quasi aggregiert nur vor dem Hauptareal angezeigt wird. Ansonsten zeige ich die Status einzeln an, auch den vom Hauptareal. Dadurch sieht man dann solche Inkonsistenzen evtl. schneller, aber natürlich führt es auch eher zur Verwunderung beim User.

ERS:

Die von dir erwähnte bisherige Implementierung, die die unterschiedlichen Status im condensed distribution string so anzeigt wie du es beschreibst, finde ich gut, auch wenn es verwirrend aussieht, denn wie gesagt, macht es auf Inkonsistenzen aufmerksam. Letztlich kommen wir da um Datenreinigung nicht drumrum. Besser, als Daten nicht zu zeigen.

Andreas Müller wrote:

... noch ein kleiner Nachtrag: bei der derzeitigen Implementierung kann es auch dazu kommen, dass Daten sowohl im native als auch im introduced Bereich des CondensedDistributionString auftreten, aber mit einem eigentlich nicht passenden Symbol.
Für das Beispiel Talinum paniculatum (http://test.e-taxonomy.eu/dataportal/preview/euromed/cdm_dataportal/taxon/3f28aea3-829f-46dc-957a-9991c30050f4) ergibt sich z.B.
-Md(??M) [aAu(A) pAz(aF aP) aHu -Md]

AM

Das tritt primär beim Status "undefined" auf. Dieser wird in Zukunft grundsätzlich nicht mehr im CondDistStr angezeigt werden (#9500), daher ist das Problem inzwischen relativ, es wäre aber sinnvoll nach solchen Fällen zu suchen die nicht mit "undefined" zu tun haben (s. auch #9501).

This should be fixed. Only code cleanup is needed.