EDIT

NoK:

die praktische Arbeit an einem CharacterTree / einer Matrix stößt einen doch auf Manches. So etwa, dass wir seinerzeit die Flora Terms ontology https://terms.tdwg.org/wiki/FloraTerms von Endara & al. (2017, https://doi.org/10.12705/664.9) komplett zum State vocabulary gemacht haben, obwohl die Autoren ihr Vokabular nie als states voc. sondern als "flora terms voc." angesehen haben. Die Subvokabulare "Structures", "Structures in adjectival form", "structure subtypes" und "substances" sind auch in allererster Linie Struktur-Vokabulare.

Zwar gibt es diese Fälle, bei denen structures auch als states benötigt werden, deshalb (und weil ich mir nicht sicher bin, ob daraus nicht schon mal irgendwas als States benutzt wurde (lässt sich das eigentlich abfragemäßig prüfen???, eine insgesamt nicht uninteressante Frage für Änderungen an der Ontologie)), sollte man sie trotzdem dort belassen und nur in das Struktur Vokabular als zunächst separates Subvokabular kopieren, um sie allmählich dort zu integrieren soweit sie Ergänzungen bieten. Dorthin ganz verschieben kann man allerdings "structure subtypes", ein Vokabular, das unter states gar nicht eingesetzt werden kann und unter structures so noch nicht existiert aber benötigt wird, weil sich damit Neuschöpfungen, die ich gerade mache, umgehen lassen: Eine Struktur wie "secondary rib" lässt sich aus " rib" + dem structure subtype "secondary" im Structure tree bauen, statt sie als eigenen Term anzulegen.

Also: Könnten ihr in der ontologie von flora-greece-bupleurum die jetzigen States Subvokabulare "Structures", "Structures in adjectival form" und "substances" in das Structure als Subvokabular kopieren und "structure subtypes" als subvokabular dorthin verschieben??

Ich weiß gar nicht, ob ich derlei im TaxEditor auch selbst könnte, aber wegen der Datenmengen und der gegenwärtigen Performance wäre das sicher ohnehin keine gute Idee.

AM:

... Aber Frage vorab: die „structure subtypes" hören sich für mich mehr so an wie das, was wir mal als „Structural Modifier“ besprochen und auch implementiert haben. „secondary“ ist ja keine Struktur an sich. Das Vokabular würde ich somit dann eher zu einen Structural Modifier Vokabular machen?

Überprüfen kann man natürlich relativ einfach, welche States schonmal verwendet wurden. Wenn also evtl. gewisse Vokabulare doch komplett von States zu Structure verschoben werden sollen, sag nochmal Bescheid. Sie zu Clonen finde ich ja eher nicht so eine schöne Idee (wegen der Redundanz). Vielleicht gibt es ja auch eine Möglichkeit, Hybride Vokabulare zu definieren, die dann sowohl als State als auch als Struktur verwendet werden können. Eventuell macht das dann die semantische Auswertung später leichter.
Aber wäre, wenn benötigt, natürlich mit ein paar Änderungen verbunden. Das muss ich mir genauer anschauen.

NoK:

ja, Du hast völlig recht, "structure subtypes" könnte so komplett ins leere Vokabular "Structural Modifier" verschoben werden. Weil die ja noich nicht funktionieren hatte ich jetzt zunächst an eine Anwendung wie bei "region" (siehe vorherige mail) gedacht.

Ein Verschieben von SubVokabularen fände ich auch besser, zumal wir die States des Umfang wegens von allem reinigen sollten, was nicht gebraucht wird.
Deshalb könnten Structures", "Structures in adjectival form" und "substances" tatsächlich ganz verschoben werden.

Dann gibt es noch folgende Subvokabulare, die unter States definitiv fehlplaziert sind:

• "character" (eine Mischung aus properties und Diversem)
• "geographical terms"
• "taxon name"

und die m.E. komplett gelöscht werden können.

AM:

Ich habe den 1. Änderungsvorschlag (structure subtype von State zu Structure Modifier) schon mal implementiert in allen Produktions-DBs mit Ontology (als greece-bupleurum, caryophyllales_spp und additivity_ontology). Das war relativ einfach.

Bleibt es dabei, dass “Structures", "Structures in adjectival form" und "substances" von State zu Structure wandern soll?
Und das character, geographical terms und taxon name ganz gelöscht werden können?

NoK:

Bei den States Subvokabulare "Structures", "Structures in adjectival form" und "substances" ging es nicht um ein einfaches Verschieben in das Structure-Vokabular als Subvokabular, da viele Strukturterms sowohl als states als auch structures gebraucht werden, sondern (a) entweder ein Duplizieren, was Du keine so gute Lösung fandest, oder (b) darum hybride Vokabulare zu definieren, die dann sowohl als State als auch als Struktur verwendet werden können.
Wie aufwändig wäre es denn hybride Vokabulare zu definieren?

„Und das character, geographical terms und taxon name ganz gelöscht werden können?“ : JA

AM:

ok, die zu löschenden Vokabulare habe ich gelöscht (aus dem TaxEditor heraus).

Wegen Clonen, Hybrid oder ganz Verschieben: Da hatte ich wohl deine letzte Antwort „Ein Verschieben von SubVokabularen fände ich auch besser, zumal wir die States des Umfang wegens von allem reinigen sollten, was nicht gebraucht wird. Deshalb könnten "Structures", "Structures in adjectival form" und "substances" tatsächlich ganz verschoben werden.“ falsch interpretiert.
Ich habe gerade nochmal über „hybrid“ nachgedacht. Das ist vermutlich irgendwie die beste Lösung für alle die States/Structures die eigentlich beides sein können, modellseitig ist es aber natürlich auch das schwierigste. Derzeit muss klar definiert sein, ob ein Term ein State oder eine Structure ist und das hat auch viele Vorteile, u.a. beim Validieren der Daten.

Erstmal würde ich mir gerne nochmal ins Gedächtnis zurückrufen, inwiefern Terme beide Eigenschaften (State/Struktur) haben können. Kannst du 2-3 Beispiele nennen, bei der ein Character einen State hat der anderweitig auch als Struktur verwendet werden könnte? Geht es da nur um so Characters wie „Stuktur des XY“ oder ist das auch noch komplexer?
Ich frage, weil es davon abhängig sein könnte, inwieweit es Sinn macht beide Terme zu separat zu bewahren oder sie hybrid als ein Term zu behandeln.

Außerdem habe ich mir die Vokabulare nochmal angeschaut. In „structure in adjective form“ scheinen mir eher Adjektive zu stehen. Die kommen in genau der Form als Struktur also eher nicht in Frage. Entweder müssten sie in Substantive überführt werden oder zumindest hier wäre es doch sinnvoller, diese als 2 verschiedene, wenn auch sehr ähnliche Terme zu belassen. Ggf. noch eine Ähnlichkeitsbeziehung einführen (derzeit modellseitig zwar möglich, sonst aber noch nicht unterstützt). Auch „substance“ ist mir nicht so klar. Inwiefern sind z.B. chemische Terme wie „Aldehyde“ oder „Calcium“ Strukturen?

Eine weitere Frage zu den Vokabularen wäre, inwiefern hier die Qualität inzwischen besser gecheckt wurde. Ich erinnere mich, dass es da Anfangs z.B. diverse Rechtschreibfehler gab. Oder in dem „structure subtype“ Vokabular habe ich einen Term „false“ gefunden, der mit da nicht sinnvoll scheint. Soll ich evtl. nochmal einen Gesamtausdruck (z.B. als Excel-Tabelle) machen, damit ihr nochmal drüber gehen könnt, ob keine groberen Fehler mehr drin sind?

Auch stellt sich die Frage nach den Descriptions der Terme. Eigentlich wäre es gut, für alle Terme zumindest kurze Beschreibungen zu haben, um sie eindeutiger zu fassen und gegen ähnliche Terme abzugrenzen (oder um Menschen wie mir, die da nicht so tief drin stecken, eine kurze Erklärung zu geben). Das lässt sich aber natürlich auf die Schnelle nicht so einfach machen, daher werden wir das wohl in den Update-Prozess mit aufnehmen müssen.

SQL for moving "structure subtypes" to Structure Modifier:

UPDATE TermCollection tc
SET tc.termType = 'STMO'
WHERE tc.termType = 'STA' AND tc.uuid = 'ca9803d5-1ed7-47ec-99e1-9ff2054991c1';

UPDATE DefinedTermBase dtb INNER JOIN TermCollection tc ON tc.id = dtb.vocabulary_id
SET dtb.termType = 'STMO'
WHERE dtb.termType = 'STA' AND tc.uuid =  'ca9803d5-1ed7-47ec-99e1-9ff2054991c1';


UPDATE TermCollection_AUD tc
SET tc.termType = 'STMO'
WHERE tc.termType = 'STA' AND tc.uuid = 'ca9803d5-1ed7-47ec-99e1-9ff2054991c1';

UPDATE DefinedTermBase_AUD dtb 
SET dtb.termType = 'STMO'
WHERE dtb.termType = 'STA' AND dtb.vocabulary_id = 128xxx;

TODO: check for completeness before using again, e.g. DTYPE, orderIndex, vocabulary_id, partOf_id ...

Analyzing the structure tree "structures 1.0" and the structure vocabularies shows that many of the structures in the structure vocabularies are not used. It is even unclear if they are structures at all. E.g. the character "entire plant-habit" is realized with structure "entire plant" and property "habit" while it is unclear what the structure habit in the "01 Entire plant" vocabulary stands for as a structure.
This needs further investigation.

Maybe a structure always needs to be a physical top level structure and all other structure need to be relatable via "is part of" or "is kind of". If this is not possible there seems to be something wrong.

NoK:

• 00 Temporal Modifiers“: Die stehen nur unter structures, weil die modifiers nicht implementiert waren, können also verschoben werden.

AM:

I moved this vocabulary to "modifiers". Still need to update label.

AM:

Ich habe mir gerade mal angeschaut, wieviele Strukturen in dem Strukturbaum „structures 1.0“ verwendet werden (zu sehen z.B. im Character-Editor). Das sind 132 der 900 Strukturen, die grundsätzlich in den Strukturvokabularen existieren (Termvokabular Editor für Strukturen). Ähnlich, wenn auch nicht ganz so, sieht es bei den Properties aus 32/82.

Gleichzeitig scheinen mir insbesondere die noch nicht verwendeten Terme noch viele sehr fraglich zu sein. Z.B. in „01 Entire Plant“ scheinen mir viele Terme zu sein, die eigentlich keine Strukturen sondern Properties oder States sind.
Es scheint mir ein bisschen gefährlich, dennoch alle 900 Strukturen zu importieren in die Term-DB und anschließend in die Clients (z.B: Flora Greece), da das Synchronisieren bei einem möglichen größeren Umbau dieser Vokabulare aufwendig/technisch schwierig sein könnte, da es eben nicht nur um Hinzufügen sondern auch um Löschen, Verschieben und sogar Typänderung gehen wird, was bekanntlich schwierig ist.
Daher bin ich gerade am Überlegen, erstmal nur die Terme zur Ontologie hinzuzufügen, die auch in „structures 1.0“ und „properties 1.0“ verwendet werden. Bei diesen Termen gehe ich davon aus, dass die im Zuge der bisherigen Arbeiten weitestgehend gut geprüft wurden und somit in Zukunft wenig Veränderung unterliegen. Teilst du diese Einschätzung?

Allerdings sollten die anderen Terme natürlich nicht verloren gehen, da viele von ihnen in irgendeiner Form in Zukunft noch Verwendung finden dürften. Daher würde ich sie auch auf den Term-DB Server migrieren, aber in separate Vokabulare, die erstmal nicht zur offiziellen Ontologie gehören. Oder alternativ würde ich sie im jeweiligen Vokabular belassen, aber entsprechend taggen, dass sie nicht mit der Ontologie zu den Clients exportiert werden. Technische Details muss ich da noch durchdenken.
Könntest du diesem Vorgehen zustimmen?

NoK (inline):

Das Separieren der noch nicht benutzen Terme scheint mir eine in jeder Hinsicht sehr gute Idee, da mir die ungeprüfte Menge doch Bauchschmerzen bereitet und ohnehin das Arbeiten erschwert. Die noch unbenutzten in separaten Vokabularen (gleichlautend aber besonders geflaggt) wäre mir recht, wenn ich sie dann ins akzeptierte Vokabular verschieben kann; falls das nicht einfach machbar ist, wäre im Vokabular belasse und flaggen auch OK (wenn ich das flag dann mühelos entfernen kann).

AM:

Bei den States ist das ein bisschen schwieriger, da deren bisherige Verwendung ja von den Character Trees abhängt, die Use-Case bezogen sind, also bei Centaurea und Lactucinae unterschiedlich sind. Dennoch würde ich auch da in einem ersten Schritt versuchen, lediglich die bisher verwendeten State-Vokabulare offiziell zur Ontologie hinzuzufügen um auf der sicheren Seite zu sein und die anderen Vokabulare zwar auch auf Terms-DB umzuziehen, aber nicht als offizielle „Ontologie“-Terme.

Grund für dieses Vorgehen wäre wie gesagt, dass ein späteres Hinzufügen leicht, ein Löschen, Ändern, … aber schwer wäre.

NoK (inline):

Bei den States wäre das noch wichtiger, schon wegen der bloßen Menge. Nur die bisher benutzten State-Vokabulare OK. Aber wäre es auch möglich, nur die bisher in einer Matrix benutzten States zu identifizieren und nur diese Vokabulare mit diesen States zu übernehmen?? Wenn ich es recht sehe, sind das die Matrices von Cactaceae, Bupleurum und Cichorieae; Centaurea wohl noch nicht, da Matrix bisher nicht befüllt.

AM:

Falls wir so vorgehen sollten wir aber vereinbaren, dass wir durch die verbleibenden Terme möglichst zeitnah nochmal durchgehen, und diejenigen identifizieren, die sicherlich und in eindeutiger Art gebraucht werden in Zukunft, wenn auch bislang nicht in Verwendung, da z.B. für die beiden bisherigen Gruppen nicht relevant.

NoK (inline): Hm, wie die Zeit es zulässt... bzw. vorher würde Konstantina mir eine Liste mit States rüberreichen, die ich dann ins autorisierte Vokabular schiebe.

Das Vorgehen würde v.a. auch die Notwendigkeit, bislang ungeklärte Fragen zeitnah klären zu müssen, deutlich reduzieren.

Würdest du da zustimmen?

NoK (inline): Ja!!

====

AM:

schön, dann wäre das auch weitgehend geklärt. Nur bei der Einengung der States nicht nur auf die verwendeten Vokabulare sondern auch auf die bisher verwendeten States bin ich mir nicht ganz sicher, ob das nicht zu eng ist und zu schnell jeder Menge Anpassung bedarf. Aber ich schau mir das mal an und dann können wir sehen.

NoK:

ausgehend davon, dass Ergänzungen einfach aber Löschungen aus dem Vokabular sehr problematisch sind, wäre das genau aber nur konsequent; gerade auch weil die State Vokabulare ziemlich unsauber sind. Solange keine klaren Definitionen existieren, ist die große Fülle auch eher störend. Eine Kompromissvariante wäre noch, überdies alle State Terme drin zu lassen, die Definitionen oder Abbildungen haben.

AM:

das stimmt grundsätzlich, insofern fangen wir erstmal so an und überlegen dann, wie es weitergeht.

AM:

als nächstes sollten wir uns mal die Duplikate anschauen.

Ich habe mal 2 Excel-Tabelle erstellt mit Duplikaten (Anhang). Die eine enthält Terme aus den „Structure“-States, die auch bei den eigentlichen Structures vorkommen, die andere sonstige.
In der ersten Tabelle scheinen die ersten 6 Datensätze zusätzlich innerhalb der Structures auch doppelt vorzukommen. Da sollten wir auf jeden Fall auch aufräumen. Bei capitulum sogar mit unterschiedlicher Beschreibung, oder ist das gewollt?

Bei den „Structure“-States würde ich die Duplikate alle löschen, wenn es aus deiner Sicht nicht explizite Gründe gibt, sie zu behalten. Die „Structure“-States sollen ja sowieso in Structures umgewandelt werden und dann ggf. hybrid genutzt werden, wobei die hybride Nutzung genauso gut mit den bereits existierenden Structures möglich wäre.

In der Non_structure Tabelle sind u.a. grow form Terme. Das wirft nochmal die Frage auf, inwiefern die „Strukturen“ in „01 Entire Plant“ alle Strukturen sind. Irgendwo hatten wir das auch schon mal angesprochen, ich finde es aber gerade nicht. Aus meiner Sicht würde ich denken, dass zumindest “habit“ und Kinder keine Strukturen sind sondern habit eine Property (da kommt es auch schon vor und könnte somit ersatzlos gestrichen werden). Die Kinder wiederum scheinen States zu sein, wobei bislang nicht für alle ein Pendant im States Vokabular „growth form“ existiert. Das Kind „growth form“ könnte vermutlich komplett gelöscht werden.
Kannst du auf die habit Kinder mal drauf schauen und sagen, ob du zustimmst und wenn ja, welche komplett gelöscht werden können und welche nach „growth form“ (oder wo anders hin) verschoben werden sollen?

Auch „ecological adaptations“ scheint mir keine Strukturen zu sein sondern eher funktionale Beschreibungen. Wie gehen wir damit vor? Könnte man „ecological adaptations“ auch zu einem Property machen und die Kinder zu States, oder passt das nicht?

Kannst du dir auch noch die anderen Duplikate anschauen in „Non_Structure“. Einige scheinen wirklich unterschiedliche Bedeutung zu haben und insofern berechtigt zu sein.

For moving states to structures I used:

UPDATE DefinedTermBase
SET vocabulary_id = 216, titleCache = REPLACE (titleCache, '$', '')
-- xx
-- SELECT * FROM DefinedTermBase
WHERE vocabulary_id = 133 AND DTYPE = 'State' AND id IN (
6517,6536,6541,...
)

UPDATE Representation 
SET label = REPLACE (label, '$', '')
WHERE id IN (
SELECT r.id 
FROM DefinedTermBase dtb INNER JOIN DefinedTermBase_Representation MN ON MN.DefinedTermBase_id = dtb.id INNER JOIN Representation r ON r.id = MN.representations_id
WHERE vocabulary_id = 216 AND label LIKE '$%'
)

UPDATE DefinedTermBase
SET DTYPE = 'DefinedTerm', termType = 'STRU'
WHERE vocabulary_id = 133

SELECT dtb.DTYPE, dtb.termType, dtb.id  , dtb.updated, dtb.titleCache,  voc.titleCache, voc.id
FROM DefinedTermBase dtb INNER JOIN TermCollection voc ON voc.id = dtb.vocabulary_id
WHERE dtb.vocabulary_id = 133

SELECT *
FROM TermCollection tc
WHERE tc.id = 133

AM:

hier mal die Zusammenfassung, welche Terme in „regions“ bereits verwendet werden.

• abaxial face (1x)
• apex (10x)
• base (8x)
• coloured portion (1x)
• decurrent portion (1x)
• lower face (1x)
• lower half (1x)
• margin (7x)
• middle (1x)
• surface (2x)
• upper face (1x)

Das kann man mit dem referencing objects view ganz gut überprüfen.

Dabei ist mir aufgefallen, dass z.B abaxial face im Structure Tree 1.0 in „inflorescence-capitulum-involucre-involucral bract-abaxial face-indumentum” verwendet wird. Das ist evtl. ein kritisches Problem, da die structural modifier ja nur auf Ebene des Characters verwendet werden können, um die beschriebene Struktur näher zu definieren. Da hier am Ende der Kette indumentum steht, funktioniert das aber nicht wirklich. Abaxial face bezieht sich ja auf involucral bract, wenn ich es richtig verstehe. Der Modifier modifiziert also eine Struktur im inneren des Baumes und nicht am Ende. Dafür ist unsere jetzige Datenstruktur nicht unbedingt geeignet.
Ähnlich für base in „inflorescence-capitulum-involucre-middle involucral bracts-appendage-base-cilia”

Ich frage mich, ob unsere structural modifier da wirklich funktionieren, so wie sie bislang angedacht/implementiert sind. Wir können das gerne auch nochmal mündlich diskutieren.

Only open issue: test states used by Lactucinae

added:

• derivation - adventitous

Cleanup for data in use (Lactucinae):

• (Shape) attentuate -> attenuate and include later in ontology
• discoid (06 structures in adjectival form) -> is now in architecture only - add to ontology
• taproot, rhizome, stolon, tuber: structure_duplicates -> 04 vegetative structures

Add to ontology:

Architecture:

• acrodromous? Only for Bupleurum? - NoK: for all
• attenuate semiamplexicaul - keep here or move to shape as "attenuate"? - added - NoK: keep it in architecture
• barbellate - added
• caulescent - added
• hyaline margined - only Bupleurum - NoK: for all
• one veined - only Bupleurum - NoK: for all
• paniculiform - added
• paniculiform corymbiform - added
• paniculo corymbiform - NoK: delete, is duplicate to the above one
• petioloid - added
• rhizomatous - only used for Cicerbita variabilis which is not in matrix/classification anymore - NoK: add!
• taprooted - only used for Lactuca virosa which is not in matrix/classification anymore - NoK: add!

Arrangement:

• uniseriate - added

Coloration:

• creamy - added (is this a color?) ---> NoK: should read "cream"
• purplish red - to add

Growth form:

• caespitose - only Bupleurum (are caespitose and cespitose duplicates?)
• herbacous - orphant StateData
• rosette forming - added
• subscandent - added

Length:

• distinctly longer - used for "corpus apex papillae length ratio to corpus middlle third papillae" - added
• distinctly shorter - "outer involucral bracts length ratio to inner involucral bracts" - added
• much shorter - "outer involucral bracts length ratio to inner involucral bracts" - added

Prominence:

• predominant - added - NoK: ?? = prominent??, do not add - XXX
• prominent - added
• undifferentiated - added (e.g. median main rib prominence ratio to median secondary rib)

Pubescence:

• glandulous - added
• sparsely soft hairy - added
• stiff-hairy - added (all e.g. vegetative above ground structures indumentum)

Shape:

• abrupt - used by Centaurea cyanus specimen "20000(B: 1000000000)" for corolla shape, only 1 record. Needed? - not yet added - NoK: OK
• abruptly beaked - used for apex shape - added
• acuminate - used by Bupleurum only for apex shape - is this a typo for accuminate? - not yet added - NoK: "acuminate" is correct and important, please add - AM: da hatte ich wohl einen Fehler gemacht beim ursprünglichen Import und das Falsche genommen, habe ich angepasst
• attentuate (see above - should be attenuate) - corrected
• attenuately beaked - used for apex shape - added
• conical - is there a difference to "conic"? - not yet added - NoK: no diff.
• elliptic lanceolate - only used for Bupleurum for shape and lamina shape - added- NoK: do not add - AM: wieder entfernt
• filiform - used for beak shape - added
• flattened - only used for Bupleurum in 2 records for bractlet venation structure (is there a difference to the unused term flatted?) - not yet added
• globular - used for papillae shape - added
• hood shaped - used for papillae shape - added
• keeled - used only for Bupleurum for bractlet venation structure - not yet added - NoK: please add - AM: added
• lanceolate linear - used for lamina shape and hair shape, see also linear lanceoate - not yet added due to possible deduplication - NoK: linear lanceolate is preferred - AM: verschoben zu linear lanceolate
• linear curvate - used only for Bupleurum in 2 records for lamina shape - not yet added
• linear filarious - used only for Bupleurum in 3 records for lamina shape - not yet added
• linear lanceoate - used for hair shape (is this a duplicate for lanceolate linear or for already existing linear lanceloate?) - not yet added due to possible deduplication - NoK: OK
• linear laneolate (is this a typo for already existing linear lanceolate?), used only for Bupleurum atlanticum subsp. ayouense - not yet added - NoK: OK
• linear oblanceolate - used only for Bupleurum for shape and lamina shape - not yet added - NoK: OK
• narrowed - used for hair shape and papillae shape - added - NoK: OK, although I do not know if this is really different to "attenuate"
• obovate elliptic - used only in 1 Bupleurum record for lamina shape - not yet added - NoK: OK
• petioliform - used in some Bupleurum records for shape - not yet added - NoK: OK, we have petioloid in architecture
• segmented - used for carpopodium shape - added
• stout - used for beak shape - added
• subcompressed - used for corpus flattening - added
• subfiliform - used for beak shape - added
• swollen - used for lateral ribs shape - added
• triangulate - used for papillae shape in 1 record, is this a duplicate for triangular which is often used in other records for same character? - not yet added - NoK: yes, OK
• truncated - used for apex shape in 2 records, is there a difference to truncate, which is also used for apex shape but more often? - not yet added - NoK: OK, truncate is preferred
• u shaped - used for carpopodium shape - added
• uncompressed - used for corpus flattening - added
• winglike - used for lateral ribs shape - added

Size:

• subequal - only used for Bupleurum acutifolium for ray size - not yet added - NoK: seems relevant to me, please add
• unequal - only used for Bupleurum for ray size - not yet added - NoK: seems relevant to me, please add

Do we really need the "Size" vocabulary? - NoK: I think so

Texture:

• hyaline membranous - only used for Bupleurum for bractlet texture - not yet added - NoK: OK

Structures: (04 Vegetative Structures)

• rhizome
• stolon
• taproot
• tuber => handled in structure vocabulary

SELECT tmp.state_id, tmp.stateTitle, tmp.uuid, voc_id, vocTitle, termType, COUNT(*) AS n
FROM (
SELECT sd.id, sd.created, sd.createdBy_id, sd.state_id, st.titleCache stateTitle, st.uuid, st.termType, voc.id voc_id, voc.titleCache vocTitle, cd.id cd_id, cd.inDescription_id
FROM StateData sd LEFT JOIN DescriptionElementBase cd ON sd.categoricalData_id = cd.id
LEFT JOIN DefinedTermBase st ON st.id = sd.state_id
LEFT JOIN TermCollection voc ON st.vocabulary_id = voc.id
) AS tmp
GROUP BY tmp.state_id, tmp.stateTitle, tmp.uuid, voc_id, vocTitle
HAVING  tmp.uuid NOT IN (
  SELECT cdmstates.uuid  FROM cdm_production_cdmterms.DefinedTermBase cdmstates JOIN cdm_production_cdmterms.TermRelation cdmtermnodes
  ON cdmstates.id = cdmtermnodes.term_id
)
ORDER BY termType, vocTitle, voc_id, stateTitle;

NoK: Dass Belege beim Taxon stehen, aber nicht in der Matrix sind, kann ich mir nur so erklären, dass sie für die Matrix angelegt wurden, aber dann doch keine Daten in der Matrix dazu erhoben wurden. Warum und wo da aber dann descriptive Daten dran hängen, weiß ich grade nicht. Auf jeden Fall sollten solche Belege nicht übernommen werden, da sie ohnehin nur mit extrem rudimentäre Daten vertreten sind.

scabrid:

AM: Theoretisch wäre es natürlich auch möglich den Term in den StateTree für Architecture 1.0 und für Pubescence 1.0 aufzunehmen, aber erstmal nur im Vokabular Pubescence zu lassen. Damit hat man kein Duplikat, hat ihn aber in beiden Fällen zur Verfügung.

NoK: das finde ich in diesem speziellen fall eine sehr gute Idee