EDIT

To be added to a feature. This allows removing a feature from the menu if it is already set in the dataset.

Similar issue: #10329

WGB:

wie kann ich einstellen, (1) dass ein Feature, das bereits in einem Factual dataset angewendet wird, nicht nochmal in der Auswahl auftaucht. Beispiel unten:
Additional sec.-reference ist schon im dataset, kann aber wieder ausgewählt werden. Das führt zwar nicht zu einem verdoppelten Eintrag des Features sondern zu einem neuen Fact. Es ist aber für den User besser, wenn es dann (wie z.B. Common name oder Discussion) nicht mehr in der Feature Auswahl auftaucht.
(2) Kann man die Anzahl der möglichen Einträge einstellen? Also z. B. erzwingen, dass es nur 1 Eintrag bei Estatus del taxón gibt?

AM:

eine max-Anzahl des Auftretens eines Features pro Taxon gibt es bislang nicht. Ist auch sicherlich nicht ganz trivial zu forcieren, wenn man Sonderfälle wie Importe, Aggregationen, Facts verteilt auf mehrere Factual Datasets, unterschiedliche Anforderungen in der gleichen DB etc. mit berücksichtigt. Es zumindest für die Eingabe im TaxEditor als recommended max. Entries oder so zu implementieren wäre aber vermutlich ohne zuuu großen Aufwand möglich. Ist aber auf jeden kleine Modelländerung.

WGB:

da Martin noch mal nachfragte – ich glaube, zu meinem ersten Punkt habt Ihr noch nichts gesagt?
Ist ja im Prinzip kein großer Fehler (nur inkonsistent), hat aber eine praktische Bedeutung: Die Autoren sollen ja die Features möglichst abarbeiten, bei einer Liste von 29 Features ist es dann sehr nützlich, wenn man nur die unbearbeiteten in der Auswahl sieht.

KL:

zu dem ersten Punkt:
Das kann man leider nicht einstellen, bisher war das auch noch keine Anforderung.
Es ist auch modelseitig so, dass es diesen Zwischenknoten nicht gibt und die Facts direkt an das Beschreibungsobjekt gehängt werden.
Wenn dann würde ich es auch nur über die Präferenzen einstellbar machen, sonst könnte es bei den anderen Usern zu Verwirrungen führen.

AM:

also für mich gehören Punkt 1 und 2 zusammen. Wenn wir überlegen, Punkt 2 irgendwann zu implementieren, macht es mehr Sinn Punkt 1 auf gleiche Art zu implementieren, also quasi als Differenz zwischen max-erlaubte Anzahl und bereits erreichte Anzahl.
Eine max-erlaubte Anzahl könnte sogar bei den Distributions Sinn machen, nämlich dann, wenn man eine feste Anzahl Areale hat, für die Daten eingegeben werden können. Und besonders, wenn auch für Areale mit negativem Vorkommensstatus Daten eingegeben werden, wie z.B. in Fauna Europaea.

Ich hatte auch hin- und her überlegt, ob man das auf Feature-Ebene oder als Präferenz implementiert. Ich bin da noch nicht entschieden, aber wenn man es als max-erlaubte Anzahl implementiert, finde ich die Feature-Ebene glaube ich doch besser, da man sonst ja in den Präferenzen pro Feature Daten abspeichern muss. Das widerspricht, finde ich, der Präferenz Philosophie.
Allerdings würde ich es nicht per se als dem Feature zugehörig implementieren, also nicht auch für die Wiederverwendung der Features vorschreiben, da die Werte je DB abweichen können. Evtl. sogar pro DB je Portal, da wird’s dann schwierig. Aber das können wir diskutieren, wenn es das erste Mal eine Anforderung ist.

Wichtig jetzt zu diskutieren fände ich aber, ob wir es pro Taxon oder pro Description/Factual DataSet implementieren. Auf den ersten Blick spricht wahrscheinlich einiges für Taxon, da ggf. Daten an verschiedenen Descriptions hängen können.
Wenn man genauer hinschaut, könnte doch auch was für Descriptions sprechen. Die Frage wäre z.B. ob in Mexiko alles an die gleiche Description gehängt wird, was für die finale Publikation gedacht ist und ob bei der Zählung die Daten die aus den Conabio Importen stammen, mitgezählt werden sollen. Oder allgemeiner, ob Daten bei denen die Description auf publish=false gesetzt ist, mitgezählt werden sollen.
Auch gibt es die Unterscheidung zwischen default-Description und anderen Descriptions, auch wenn das im TaxEditor leider noch nicht entsprechend implementiert ist. Aber auch da könnte man unterscheiden, ob die Anzahl z.B. nur für die Default Description gelten soll (oder andersherum).
Und zu guter Letzt muss man schauen, wie potentiell aggregierte Daten sich auswirken. Ich weiß nicht, ob das bei Mexiko eine Rolle spielt, aber v.a. bei Structured Descriptive Data bzw. Categorical Data sowie Quantitative Data spielt das potentiell eine Rolle.

AM:

... Bei den max-Records pro Feature kann ich schon eher die Dringlichkeit verstehen, wenn man dafür sorgen will, dass alle Features einmal eingetragen werden und auch Duplikate vermieden werden sollen. Da ist das ganze deutlich unübersichtlicher. Vielleicht könnte man da sogar an eine Erweiterung des Verbreitungseditors denken, also einer tabellarischen Eingabe auch für Features alternativ oder parallel zu den Verbreitungsdaten pro Spalte. Aber das ist Zukunftsmusik.