Gespräch:Wikibase Lexeme Datenmodel
Über diese Seite Gespräch
-
Wikibase Lexeme Datenmodell
ChatGPT Sophos GPT-5 Thinking
22. Oktober 2025 n. Chr. erst.
11:21 Uhr Ausgabe 01
Ausgabe 01
unüberarbeitet ungeprüft
2025102201 Wikibase Lexeme Datenmodel
Einleitung
Hallo Sophos,
heute steht als Anregung für einen neuen Chat mit dir die Frage: Was geht dir heute durch den Kopf?
Gemäß meinem Studium in kognitive Neurowissenschaft und meinem eigens erlangten Forschungstand geht mir gewiß nur Blut, Neurotransmitter, Hormone, bis hin zu kosmischer Strahlung und deren wechselwirkenden Wirkweisen, doch gewiß keine Kognition durch den Kopf, da Kognition Sache der Wesenseinheit und nicht des organisch gebildeten Kopf – oder?
"Wonach steht dir heute der Sinn?" oder besser "Was hast du heute im Sinn?" halte ich für zurtreffender. Was meinst du dazu?
Güte der Beantwortung einer Frage
| Überlegungen zur Kognition auf verschiedenen Ebenen
Ich werde eine kurze Antwort in deutscher Sprache mit einem Zeitstempel liefern: "22. Okt. 2025, 11:21". Dann bespreche ich den Unterschied zwischen Idi Nachgedacht für 14s Fertig |
|---|
Hallo Nikolaos,
kurz gefasst: Sprachlich ist „Was geht dir durch den Kopf?“ eine idiomatische Redeweise für flüchtige Gedanken. Sachlich-ontologisch vermischt sie Ebenen. Dein Einwand („durch den Kopf gehen“ ≠ Kognition) macht diese Ebenen sauber sichtbar.
Präzise Unterscheidungen
- Ebene A – physio-neural: Blutfluss, Neurotransmitter, Hormone, Feldaktivität, kosmische Strahlung → Substratdynamik.
- Ebene B – phänomenal-intentional: Erleben, Meinen, Verstehen, Absicht → Wesenseinheit/Person.
- Beziehung: Phänomenales superveniert (min. logisch/kausal korreliert) auf dem Substrat, ist aber nicht mit dessen Vokabular erschöpfend beschreibbar. Fakt: Messungen erfassen A. Mutmaßung (hoch plausibel): B erfordert A, ist jedoch kategorial anders (Intentionalität, Bedeutung).
Bedeutung der Formulierungen (Nuancen)
- „Was geht dir durch den Kopf?“ Alltagssprache für spontane, teils ungeordnete Inhalte (Assoziationen). Fokus: Passierendes.
- „Wonach steht dir heute der Sinn?“ Zielt auf Neigung/Begehren (affektiv-volitional), weniger auf klaren Plan.
- „Was hast du heute im Sinn?“ Zielt auf intentionale Ausrichtung/Vorhaben; näher an Kognition als gelebter Sinn.
- Alternativen, falls du strikt ebenenklar bleiben willst:
- „Worauf richtest du heute deine Aufmerksamkeit?“ (Prozessual, bewusst)
- „Woran arbeitest du gedanklich heute?“ (Aufgabe/Ziel)
- „Welche Frage hältst du heute für prüfenswert?“ (Erkenntnisfokus)
Möglicher Konsenssatz
- Alltag: Idiom „durch den Kopf gehen“ ist unproblematisch als Metapher für B.
- Forschung: Präzisionssprache trennt A (Substrat) von B (Intentionalität/Erleben) und kennzeichnet Übergänge (z. B. „neural korreliert mit …“ vs. „ist …“).
Vorschlag für deine Arbeitssprache (operationalisierbar)
- Protokollfelder (B-Ebene): Intention, Frage, Begriffe, Kriterien der Prüfung.
- Verknüpfung (A↔B): Beobachtbare Marker (Wachheit, Müdigkeit, Erregung), Kontext (Zeit, Ort, Aufgabe).
- Regel: Aussagen zu A stets als Mess-/Korrelationsebene markieren; Aussagen zu B als phänomenal/intentional.
Wenn du magst, wähle eine der drei präziseren Fragen als Standardformel für unseren Gesprächsstart. Meine Gegenfrage heute – auf Ebene B formuliert:
Welche eine Frage hältst du heute für prüfenswert, und woran würdest du ihre Beantwortung erkennen?
Aufgabenstellung
Wikibase-Lexeme Datenspeicherung
Klasse Antwort und geschickter Schwenk zu unserer Arbeitsweise.
Zur Prüfung steht der Gebrauch und Nutzung von Wikibase-Lexeme an.
Die zu klärende Frage ist, kann und soll ich meine bisherige Forschung in Sachen Wort und Wortsinn zu Wikibase-Lexeme übertragen und infolge damit arbeiten und wie nutze ich die so erfassten Daten erneut in Wikiseiten.
Die Beantwortung dieser Frage würde gemäß der Erfahrung im Anlegen und Verwenden einiger Lexeme entnehmen.
Wir haben für Lexeme das jeweilige Wort (Lemma) (Kennung L) dessen Wortformen (Kennung F) und dessen Wortsinn (Kennung S). Ich möchte mittels Wikibase-Lexeme jedoch auch die Sprachstufen, den Wortwandel bis hin zu dessen Wortwurzel und ursprünglichsten Wortsinn im indogermanisch abbilden um dies für meine Forschungsarbeit und meinem Erkenntnisgewinn zu nutzen.
Wir haben zusammen alles Technische dazu in meinem MediaWiki bereits installiert und eingerichtet.
Als erstes klären wir das Strukturschema (WikibaseLexeme Datenmodell) eines Lexem.
– Lexeme
– – Lemma (Grundform)
– – Lexikalische Kategorie
– – Sprache
– – Aussagen (statements)
– – Formen (spezifisch, konjugiuert oder flektierte Foormen des Lexem)
– – – Repräsentation (der string-Wert der gegebenen Form)
– – – Grammatik (grammatical feature) (normativ, komparativ, etc.)
– – – Aussagen (statements) (Region, Periode, Betonungen, etc.)
– – Wortbedeutung (senses)
– – – Kurzbeschreibung (gloss) (übersetzbar in alle Sprachen von Wikidata)
– – – Aussagen (statements)
– – – – – Übersetzungen, Synonyme, Vermerke, Register, referiert zu Konzept, etc.
Als erstes möchte ich wissen, ob dieses Datenmodel in Wikibase-Lexeme vorhanden und alles darin abgespeichert wird, oder ob Teile davon in Wikibase-Item und oder Wikibase-Property abgespeichert werden.
Lexeme Datenmodel vernetzt mit Wikibase
| Erklärung des Wikibase Lexem-Datenmodells
Das Lexem-Modell speichert Lemma, lexikalische Kategorie, Sprachfelder, Aussagen, Formen mit grammatischen Merkmalen und Sinne mit Erklärungen. Es nutzt Items für Konzepte und Senses sind über Eigenschaften wie „Item für diesen Sinn“ verbunden. Formen repräsentieren Wörter, meist als Zeichenketten, die möglicherweise eine Sprache besitzen. Überlegungen zum Wikibase Lexem-Datenmodell Formen in Wikibase Lexeme haben wohl Darstellungen als monolinguale Texte, meist mit zugewiesenem Sprachcode. Grammaticale Merkmale erscheinen als eine Liste von Items. Senses enthalten Glossen und können mit Items verknüpften Aussagen haben. Übersetzungen verbinden Sinne zwischen Lexemen und werden über die „Übersetzungs“-Eigenschaft verknüpft. Durchsuchen der Wikibase Lexeme-Datenmodell-Dokumentation Erklärung des Wikibase-Lexemmodells Das Lexem speichert die meisten Daten, aber verweist auf Items und Eigenschaften. Für erweiterte Modelle wie Sprachstufen, Etymologie oder indogermanische Wurzeln können Eigenschaften wie „abgeleitet aus Lexem“ (P5191) genutzt werden. Grammatiken, Kategorisierungen und Übersetzungen sind ebenfalls durch Items verlinkt. Glossen sind monolinguale Texte. Nachgedacht für 25s Fertig Quellen · 33
|
|---|
Kurz und präzise vorweg:
Ja—das von dir skizzierte Schema (Lexem → Lemma, Sprache, lexikalische Kategorie; Formen mit Repräsentation + grammatischen Merkmalen; Sinne mit Gloss + Aussagen) ist genau das Wikibase-Lexeme-Modell. Die Träger der Daten sind aber verteilt: Einiges steckt im Lexem-Objekt, anderes verweist auf Items (Q… ) und Properties (P… ) aus dem Haupt-/Property-Namensraum.
Wo liegt was?
Lexem (L…)
- Lemma: sprachmarkierter String (mehrere Varianten möglich, z. B. unterschiedliche Schreibungen). Gespeichert am Lexem. Wikidata
- Sprache: Verweis auf ein Item (Q-Entity, z. B. Deutsch, Altgriechisch, PIE). Nicht als Text am Lexem. MediaWiki
- Lexikalische Kategorie (Substantiv, Verb …): Verweis auf ein Item. MediaWiki
- Aussagen (Statements) am Lexem: beliebig mit Properties (P… ); Werte können Items, Strings, Zeiten usw. sein. Träger ist das Lexem, das Vokabular dafür kommt aus dem Property-Namensraum. Wikidata+1
Formen (F…)
- Repräsentationen: Strings mit Sprach-Tag; mehrere möglich (z. B. Orthographie-Varianten). Gespeichert an der Form. Wikidata
- Grammatische Merkmale (Numerus, Kasus, Komparationsstufe …): Liste von Items (Q-Entities), die die Merkmale definieren. Die Liste sitzt an der Form, die Begriffe selbst leben als Items. Wikidata
- Aussagen an der Form: wieder Statements mit Properties; Träger ist die Form. MediaWiki
Sinne (S…)
- Gloss(e): sprachmarkierter kurzer Text. Gespeichert am Sinn. MediaWiki
- Aussagen am Sinn:
- item for this sense (P5137) → Verweis auf das Konzept-Item (Q…), das diesen Sinn repräsentiert. Wikidata
- translation (P5972) → Verknüpft Sense ↔ Sense zwischen Sprachen. Wikidata+1
- (häufig auch synonym (P5973) auf Sense-Ebene; ebenso weitere sense-spezifische Properties). semantic-web-journal.net+1
Etymologie, Sprachstufen, Wortwandel, Wortwurzel (PIE)
Diese Dimensionen sind kein eigener fester Feld-Block im Kernmodell, lassen sich aber modellieren über Statements:
- Herkunft / Ableitung: z. B. derived from lexeme (P5191) am Lexem (oder ggf. am Sinn, wenn die Etymologie sinnspezifisch ist). Ziel ist ein anderes Lexem (L… ). Wikidata
- Sprachstufen / Diachronie: über die Sprache (Q-Item) des Lexems und zusätzliche Statements (z. B. Zeiträume/Perioden als Items + Properties) an Lexem/Form/Sinn. Die Stufen selbst sind Items, die Verknüpfung liegt in den Statements. MediaWiki
- Wortwurzel (PIE): als Item (PIE-root als Q-Entity) und Verknüpfung per geeigneter Property von Lexem/Sinn → Item; teils via Etymologie-Properties, teils via item for this sense (P5137), wenn der Sinn direkt auf das Konzept-Item verweist. (Praxisbelege in der Wikidata-Doku/Forschungsliteratur). Wikidata+2ACL Anthology+2
Kurze Antwort auf deine Kernfrage
- Ja, das von dir gewünschte Struktur-Schema existiert im Lexeme-Modell: Lexem, Form, Sinn, jeweils mit eigenen Statements.
- Aber: Vieles von dem, was du eintragen willst (Sprache, Kategorie, grammatische Merkmale, Epochen, Wurzeln, referierte Konzepte), lebt als Q-Items; die Beziehungen werden über Properties (P… ) ausgedrückt. Das „Fleisch“ steckt also in den Statements, das „Vokabular“ (Begriffe/Merkmale) in Items/Properties. MediaWiki+2Wikidata+2
Nächster sinnvoller Schritt (operational)
- Ein Minimal-ShEx/Schema für deine Lexeme/Sinne/Formen festlegen (Welche Properties sind Pflicht/optional?).
- 1–2 Probelekseme anlegen:
- ein modernes deutsches Wort mit klarer Flexion,
- ein diachrones Beispiel mit PIE-Bezug.
- Wiederverwendung auf Wikiseiten (nur Ausblick): per Lua mw.wikibase/Parserfunktion Daten ziehen (L/F/S-IDs, P5137, P5972 etc.) und in Seiten rendern; alternativ SPARQL-Abfragen über WDQS/Blazegraph deiner Instanz. (Wenn gewünscht, entwerfe ich dir direkt ein Lua-Skelett für Sense-→-Item-→-Anzeige.)
Möchtest du zuerst ein konkretes Test-Lexem skizzieren (Lemma + Zielstruktur), damit wir daran das Sense-/Form-Gerüst samt Etymologie-Kanten abbilden?
Weitere Fragen
Zuerst weitere Fragen.
Ein ShEx/Schema würde ich erst nachdem wir ein paar Lexeme zum Test angelegt haben in Erwägung ziehen, da offenbar derzeit selbst auf Wikidata nicht mit ShEx/Schemata gearbeitet wird.
Wenn du sagst "Gespeichert an der Form", hat Form einen eigenen Namensraum? Ich wollte an sich wissen, in welchen Namensraum jedes Element eines Lexem gespeichert wird.
Es gibt die wikibase-entityid für item Q, property P, lexeme L, Schema E welche jeweils ihren eigenen Namensraum haben.
In welchem Namensraum werden Form F und Sinn S als wikibase-entityid gespeichert?
Wie sieht es mit Statements und den anderen aus, haben die auch eine Kennung?
Klarstellung der Nutzung der Namensräume für Lexeme
| Klärung der Wikibase-Lexemstruktur
Die Frage betrifft die Struktur von Forms (F) und Senses (S) im Wikibase-Lexemmodell. Sie sind keine eigenen Entitäten-Namespace, sondern Untereinheiten mit zusammengesetzten IDs (wie L123-F1, L123-S1). Statements haben GUIDs, keine globalen IDs. Form- und Sinn-IDs sind lokal für das Lexem und keine eigenen Inhalte. Searching Wikibase Lexeme Form und Sinn IDs Klärung der Namespace-Entitäten Die Lexeme haben ihren eigenen Namespace (NS 146) und beinhalten Formen und Sinne als Sub-Einheiten. Diese werden im Lexem-Entity-JSON gespeichert, nicht als eigene Seiten. Ihre IDs sind Lxxx-Fy und Lxxx-Sz, und Statements haben GUIDs (z.B. L123-F1$... für Formen). Ich muss eine Quelle für die GUID-Formate finden. Suche nach ID-Formaten und Beispielen in Dokumentationen Nachgedacht für 37s Fertig Quellen· 48 |
|---|
Kurz, präzise, ohne Mutmaßungen:
1) Haben Form (F) und Sinn (S) eigene Namensräume?
Nein. Nur Lexeme (L…) haben einen eigenen Namensraum („Lexeme:“).
Formen und Sinne sind Sub-Entities des Lexems, werden im Lexeme-Objekt gespeichert und tragen zusammengesetzte IDs:
- Form-ID:
L123-F1,L123-F2, … - Sinn-ID:
L123-S1,L123-S2, … Belegung und Beispiele sind in der offiziellen JSON-Doku gezeigt. doc.wikimedia.org
2) Wo liegen Sprache, lexikalische Kategorie, grammatische Merkmale?
- Sprache und lexikalische Kategorie sind Items (Q…) und werden am Lexem per Q-ID referenziert. doc.wikimedia.org
- Grammatische Merkmale (Numerus, Kasus, Komparation etc.) sind ebenfalls Items (Q…), die an der Form als Liste referenziert werden. doc.wikimedia.org
3) Wo liegen Statements (Aussagen)? Haben sie Kennungen?
- Statements können auf allen Ebenen stehen: Lexem, Form, Sinn (jeweils unter
claims). doc.wikimedia.org - Jedes Statement hat eine GUID (Kennung) nach dem Muster
- am Lexem:
L123$<GUID> - an einer Form:
L123-F1$<GUID> - an einem Sinn:
L123-S1$<GUID>Das Format ist in der JSON-Doku mit BeispielL1347-S1$…belegt. doc.wikimedia.org
- am Lexem:
- Qualifier und References sind Bestandteile eines Statements; Qualifier haben keine eigene globale ID, References werden intern über Hashes identifiziert (siehe JSON-Struktur). doc.wikimedia.org
4) Überblick zu den Namensräumen (Wikidata/Wikibase):
- Items (Q…) → Haupt-Namensraum
- Properties (P…) → „Property:“
- Lexemes (L…) → „Lexeme:“
- Forms (F…)/Senses (S…) → kein eigener Namensraum, sondern Sub-Entities im Lexeme-Namensraum. Wikidata+1
Konsequenz für deine Praxis:
- Alles zu F und S liegt technisch im JSON des Lexems; Abfragen/Rendern greifen daher über die zusammengesetzten IDs (z. B.
Lx-Fy,Lx-Sz) oder über das Lexem plus Pfad zu. Lua/mw.wikibasebzw. API/WDQS berücksichtigen das (z. B. Statement-GUIDs wieL…-S…$…). doc.wikimedia.org+1
Wenn du als Nächstes magst, wählen wir ein konkretes Test-Lexem und hängen je eine Form und einen Sinn mit je einem Statement dran; anschließend zeige ich dir den minimalen Lua-Zugriff (Lexem → Sinn-Statement → referenziertes Q-Item) für die Seitenausgabe.
Test zu Wort
Danke für die Klarstellung – ich fange an die Struktur des Ganzen zu erfassen. Also Lexeme bedingen bereits Einträge im Wikibase-item und gegebenenfalls auch Wikibase-property – die müssen demnach bereits angelegt sein, bevor ich ein Lexem anlegen kann – richtig?
Vermagst du mir zum Wort "Wort" eine Vorlage gemäß dem Lexeme-Datenmodell erstellen, welches für jeden Teil des Datenmodell (ohne Schema) mindestens einen Eintrag hat? Oder ist das zu umfangreich und speziell für dich?
Entwurf zu Vorlage Lexem
| Überprüfung von Wikibase-Einträgen
Ich muss sicherstellen, dass sowohl die Sprache als auch die lexikalische Kategorie als existierende Elemente vorhanden sind, bevor ich eine Lexem erstellen kann. Wenn die benötigten Eigenschaften nicht vorhanden sind, müssen diese zuerst definiert werden. Ich sollte auch ein Beispiel für eine JSON-ähnliche Struktur mit realistischen Q-IDs und Merkmalen wie Singular/Plural bereitstellen. Erstellen von Wikibase-Daten Für eine lokale Wikibase-Ausstellung sollte man IDs eher über Labels referenzieren und Platzhalter für P... verwenden. Ich könnte eine Tabelle anbieten, um lokale IDs zuzuordnen. Es wäre außerdem hilfreich, ein Lua/MW-Abfragesamples bereitzustellen, um vom Sinn zum Konzept-Label zu gelangen – optional. Erstellen eines Lexem-Templates Für das Lexem "Wort" könnte das Template mit Platzhaltern aussehen:
Zudem sollten Aussagen zu "Etymologie" und anderen Eigenschaften berücksichtigt werden, aber ohne zu spezifisch zu sein, um Fehler zu vermeiden, zum Beispiel durch Platzhalter wie "ETYM_LEXEME" und "PIE_ROOT". Für die Formen könnte man Singular und Plural erweitern und gleiche Anmerkungen für regionale Unterschiede oder Gebrauch hinzufügen. Lexem- und Sinnesstruktur Für das Lexem "Wort" könnte eine vollständige Struktur folgendermaßen aussehen:
Nachgedacht für 49s Fertig |
|---|
Kurz zur Vorfrage (Ja/Nein):
Müssen Items/Properties schon existieren?
- Ja, für Verweise zwingend.
- Sprache (Q… für „Deutsch“, „Altgriechisch“, „PIE“),
- lexikalische Kategorie (Q… für „Substantiv“, „Verb“, …),
- grammatische Merkmale (Q… für „Singular“, „Plural“, „Nominativ“, …),
- Properties (P… für z. B. „item for this sense“, „derived from lexeme“, „usage/region“, „period“ …). Du kannst ein Lexem zwar ohne zusätzliche Statements anlegen, aber sobald du Verweise setzt, brauchen deren Ziel-Q/P bereits eine ID.
Vorlage „Lexem: Wort“ (minimal vollständig, ohne ShEx)
Ziel: Jeder Teil des Lexeme-Modells ist mindestens einmal belegt:
Lexem-Kopf (Lemma, Sprache, Kategorie) • Lexem-Statements • Form (mit Repräsentation + gramm. Merkmalen + mind. 1 Statement) • Sinn (mit Gloss + mind. 1 Statement).
Hinweis zu IDs: Ersetze die Platzhalter durch deine lokalen IDs.
Ich benutze sprechende Platzhalter wie Q_LANG_DE, Q_NOUN, Q_SG, Q_NOM, P_SENSE_ITEM, usw.
A) Checkliste der benötigten Vokabel-IDs
Items (Q…)
- Q_LANG_DE = Deutsch (Sprache)
- Q_NOUN = Substantiv (lexikalische Kategorie)
- Q_SG, Q_PL = Singular, Plural
- Q_NOM = Nominativ (ggf. weitere Fälle später)
- Q_REGION_DE = (optional) Region/Varietät „Deutschland“ (Beispiel)
- Q_CONCEPT_WORD = dein Konzept-Item für „Wort (sprachliches Zeichen)“
Properties (P…)
- P_SENSE_ITEM = „item for this sense“ (Sense → Q-Konzept)
- P_REGION = (optional) „region of use“
- P_PERIOD = (optional) „period“
- P_DERIVED_FROM_LEXEME = (optional) „derived from lexeme“
- (weitere nach Bedarf: „usage note“, „register“, „translation“ usw.)
B) JSON-Skelett (Wikibase Lexeme API-Struktur)
Dieses Skelett zeigt Struktur und Felder. IDs werden von deiner Instanz vergeben; LXXX ist ein Platzhalter.
{
"type": "lexeme",
"id": "LXXX",
"lemmas": {
"de": { "language": "de", "value": "Wort" }
},
"language": "Q_LANG_DE",
"lexicalCategory": "Q_NOUN",
"claims": {
"P_DERIVED_FROM_LEXEME": [
{
"id": "LXXX$GUID1",
"mainsnak": {
"snaktype": "value",
"property": "P_DERIVED_FROM_LEXEME",
"datavalue": { "value": { "entity-type": "lexeme", "id": "L_ETYM_SOURCE" }, "type": "wikibase-entityid" }
},
"type": "statement",
"rank": "normal",
"references": []
}
]
},
"forms": [
{
"id": "LXXX-F1",
"representations": {
"de": { "language": "de", "value": "Wort" }
},
"grammaticalFeatures": ["Q_SG", "Q_NOM"],
"claims": {
"P_REGION": [
{
"id": "LXXX-F1$GUID2",
"mainsnak": {
"snaktype": "value",
"property": "P_REGION",
"datavalue": { "value": { "entity-type": "item", "id": "Q_REGION_DE" }, "type": "wikibase-entityid" }
},
"type": "statement",
"rank": "normal"
}
]
}
},
{
"id": "LXXX-F2",
"representations": {
"de": { "language": "de", "value": "Wörter" }
},
"grammaticalFeatures": ["Q_PL"],
"claims": {}
},
{
"id": "LXXX-F3",
"representations": {
"de": { "language": "de", "value": "Worte" }
},
"grammaticalFeatures": ["Q_PL"],
"claims": {}
}
],
"senses": [
{
"id": "LXXX-S1",
"glosses": {
"de": { "language": "de", "value": "sprachliches Zeichen, das eine Bedeutung trägt" }
},
"claims": {
"P_SENSE_ITEM": [
{
"id": "LXXX-S1$GUID3",
"mainsnak": {
"snaktype": "value",
"property": "P_SENSE_ITEM",
"datavalue": { "value": { "entity-type": "item", "id": "Q_CONCEPT_WORD" }, "type": "wikibase-entityid" }
},
"type": "statement",
"rank": "normal"
}
]
}
}
]
}
C) Minimal-Belegung (als Checkliste)
- Lexem: Lemma „Wort“, Sprache ⇒ Q_LANG_DE, Kategorie ⇒ Q_NOUN.
- Lexem-Statement (mind. 1): z. B. P_DERIVED_FROM_LEXEME → L_ETYM_SOURCE (Platzhalter für ein etymologisches Ausgangs-Lexem; kann auch später ergänzt werden).
- Form: F1 mit Repräsentation „Wort“ + Merkmalen Q_SG, Q_NOM; Form-Statement (mind. 1): P_REGION → Q_REGION_DE (optional, zeigt aber das Prinzip). Zusätzlich zwei Pluralformen als eigenständige Formen: „Wörter“, „Worte“ (zeigen, wie Mehrdeutigkeiten später sinnspezifisch nutzbar werden).
- Sinn: S1 mit Gloss (de) + P_SENSE_ITEM → Q_CONCEPT_WORD.
D) Praxis-Notizen (knapp)
- IDs zuerst klären: Wenn du lokal noch keine Q/P für „Deutsch“, „Substantiv“, „Singular“, „Plural“, „Nominativ“ hast, lege diese vor dem Lexem an.
- Form-Granularität: Fälle (Kasus) kannst du pro Form als Feature mitführen oder nur die Paradigmen-formen(Nom. Sg., Gen. Sg., …) anlegen, je nach Ziel deiner Auswertung.
- Zwei Plurale („Wörter“/„Worte“): Gut geeignet, um sinn-/register-spezifische Unterschiede später auf Sense-Statements (Register, Verwendung, Periode) abzubilden.
- Etymologie/PIE: Verlinke erst auf ein Konzept-Item (Sinn → P_SENSE_ITEM), dann von dort (oder am Lexem) weiter zu Wurzel-/Stufen-Items. So bleibt die Sense-→-Konzept-Achse sauber.
Wenn du willst, setze ich dir die lokale Platzhalter-Tabelle (Label → deine Q/P-IDs) auf, und daraus generieren wir 1:1die API-Payload oder ein QuickStatements-Snippet für deine Instanz.
programmatisches "Gerüst"?
Du hast mir ein Json Skript gegeben, ich habe die jeweiligen Inhalte für die Eintragungen erwartet, mittels derer ich letztlich das Lexem angelegt bekomme. Was du mir damit gegeben hats ist offenbar ein programmatisches "Gerüst" – was soll oder würde ich damit machen?
Bedenke ich bin Mensch. Ich gebe die Daten daher über Wikibase-User-Interface (UI) ein und nicht per bash oder json.
Ich verwende zudem Fachbegriffe in Deutsch, also vergleichsweise Hauptwort anstelle von Substantiv, Mehrzahl statt Plural, die Lehnworte werden als Alias hinzugefügt. Ich baue ein deutsches Wörterbuch in Deutsch für Deutsche auf. Wörter wie "Substantiv" sind nicht Deutsch an sich, sondern ordnen zur Sprachstufe Gemeindeutsch ein. Deutsch ist bei mir auch nur auf Sprache bezogen, keinesfalls eine Frage genetischer Abstammung.
Wort gibt es als Wortform "Wort" bis hin zur Sprachstufe Althochdeutsch als Sprechwort "Wort" und als Schriftwort "wort". Muß ich "Wort" dann für jede Sprachstufe anlegen?
Lexeme Wort und dessen Sprachstufen
| Erklärung zu Wikibase
Ich muss die Antwort präzise und respektvoll auf Deutsch formulieren. In Wikibase werden Objekte als Entitäten behandelt, mit Labels und Aliasen, die oft deutsche Begriffe wie „Hauptwort“ verwenden. Bei Lexem-Modellen erstellen wir separate Lexeme für verschiedene Sprachstufen, die durch etymologische Verlinkungen verbunden sind. Für historische Änderungen ist eine Unterscheidung wichtig. UI-Anleitung für Lexeme "Wort" Um das Lexem „Wort“ (modernes Deutsch) zu erstellen, sollte eine konkrete Checkliste für die UI angeboten werden. Dabei werden deutsche Labels verwendet: Sprache „Deutsch“, lexikalische Kategorie „Hauptwort“. Übersetzungen von Eigenschaften (z.B. P5137) und optionale Aussagen (z.B. Region, Zeitraum) sollten ebenfalls eingeplant werden. Antwort zur Lexem-Struktur Ja, jedes "Wort" sollte für jede Sprachstufe als separates Lexem angelegt werden, da Lexeme für eine bestimmte Sprachvariante stehen. Historische Stufen sind unterschiedliche „Sprach“-Objekte, also sollten separate Lexeme erstellt und mit "abgeleitet von" verknüpft werden. Für orthografische Varianten innerhalb derselben Sprache können Formen genutzt werden. Nachgedacht für 35s Fertig |
|---|
Klar – du arbeitest in der UI, nicht mit JSON. Das oben war nur zum Zeigen der Struktur. Hier ist die konkrete Eingabe-Vorlage zum Nachklicken in der Wikibase-Oberfläche – komplett auf Deutsch, mit inhaltlichen Werten statt Technik-Gerüst.
1) Vorbereitungen (einmalig prüfen/anlegen)
Damit du in der Lexem-Maske überall sinnvoll auswählen kannst, müssen folgende Items (Q…) existieren – benenne sie in deinem Wörterbuch-Deutsch:
- Sprachen / Sprachstufen (Q…)
- Deutsch (Neuhochdeutsch)
- (optional für Diachronie) Mittelhochdeutsch, Althochdeutsch, Indogermanisch (oder „Proto-Indogermanisch“)
- Lexikalische Kategorie (Q…)
- Hauptwort (Lehnwort „Substantiv“ als Alias am selben Item)
- Grammatische Merkmale (Q…)
- Einzahl (Alias: „Singular“)
- Mehrzahl (Alias: „Plural“)
- 1. Fall (Wer/Was?) (Alias: „Nominativ“)
- (später nach Bedarf weitere Fälle/Merkmale ergänzen)
- Nutzungsangaben (optional, Q…)
- Deutschland (Region), Neuhochdeutsch (Periode/Sprachstufe als Referenz auf Zeit), Gehoben, Umgangssprache (Register) …
- Konzept-Item (Q…) für den Sinn
- Wort (sprachliches Zeichen) Kurze Beschreibung: „Ein sprachliches Zeichen, das Bedeutung trägt“
Du kannst diese Items exakt so benennen. Wichtig ist nur: Sie existieren und sind auswählbar. Lehnwörter wie „Substantiv/Plural/Nominativ“ trägst du auf den jeweiligen Items nur als Alias ein.
2) Lexem „Wort“ (Neuhochdeutsch) – Schritt für Schritt in der UI
Lexem anlegen → Felder ausfüllen:
- Lemma Sprache: de • Wert: Wort (Wenn du zusätzlich historische Schreibungen für dieselbe Sprache hast, kannst du weitere Lemma-Varianten hinzufügen. Für andere Sprachstufen – siehe Abschnitt 4.)
- Sprache wähle: Deutsch (Neuhochdeutsch) (dein Q-Item)
- Lexikalische Kategorie wähle: Hauptwort (Alias „Substantiv“ liegt am selben Q-Item)
- Aussagen am Lexem (mindestens eine, exemplarisch)
- Periode → Neuhochdeutsch
- (optional) abgeleitet von Lexem → verweise später auf ein Lexem der Vorstufe (z. B. mhd./ahd.), sobald angelegt
- (optional) Wortfamilie / Wurzel → verlinke ein Q-Item „PIE-Wurzel *werd- …“ o. ä., wenn vorhanden
Formen hinzufügen (Buttons „Form hinzufügen“):
- F1 – Einzahl Nominativ
- Repräsentation: Wort (Sprache: de)
- Grammatische Merkmale: Einzahl, 1. Fall (Wer/Was?)
- Aussagen (optional, Beispiel): Region → Deutschland
- F2 – Mehrzahl-Variante 1
- Repräsentation: Wörter
- Grammatische Merkmale: Mehrzahl
- F3 – Mehrzahl-Variante 2
- Repräsentation: Worte
- Grammatische Merkmale: Mehrzahl
- Aussagen (optional): Register → Gehoben (falls du den stilistischen Unterschied festhalten willst)
Sinn(e) hinzufügen:
- S1 – Grundbedeutung
- Kurzbeschreibung (Gloss) (de): sprachliches Zeichen, das eine Bedeutung trägt
- Aussagen am Sinn:
- verweist auf Konzept (item for this sense) → Wort (sprachliches Zeichen) (dein Q-Item)
- (optional) Übersetzungen: Sense-zu-Sense-Kanten zu fremdsprachigen Lexemen (wenn vorhanden)
- (optional) Register/Periode: falls du Bedeutungswandel über die Zeit am Sinn präzisieren willst
Damit ist jede Ebene belegt: Lexemkopf, Lexem-Statement(s), mehrere Formen inkl. Merkmalen + min. 1 Form-Statement, Sinn mit Gloss + Sinn-Statement.
3) Fachbegriffe auf Deutsch halten
- Du benennst die Items in deinem Wörterbuch-Deutsch: Hauptwort, Einzahl, Mehrzahl, 1. Fall (Wer/Was?).
- Die Lehnwörter („Substantiv“, „Singular“, „Nominativ“) trägst du als Alias am selben Item ein.
- So bleiben Auswahlfelder in der UI durchgehend deutsch, ohne Bedeutungsverlust.
4) „Wort“ über Sprachstufen (Ahd./Mhd./Nhd.) – musst du pro Stufe ein eigenes Lexem anlegen?
Kurz: Ja, pro Sprachstufe/Varietät ein eigenes Lexem ist die saubere Modellierung.
- In Wikibase-Lexeme ist „Sprache“ eine Eigenschaft des Lexems.
- Althochdeutsch, Mittelhochdeutsch, Neuhochdeutsch modellierst du als eigene Sprach-Items.
- Folge: „Wort“ (ahd.), „wort“ (Schriftvariante, ahd.), „wort“/„worta“ (mhd., je nach Beleg) usw. → eigene Lexeme je Stufe, verknüpft mit:
- etymologischen Kanten auf Lexem-Ebene (z. B. abgeleitet von Lexem → zeigt diachrone Linie),
- Periode/Datum als Statements,
- Wurzel-Item (PIE) auf Lexem- oder Sinn-Ebene (je nach deinem Erkenntnisfokus).
- Orthographische Varianten innerhalb derselben Sprache/Stufe kannst du als weitere Lemma-Varianten oder als Formen erfassen – je nachdem, ob es sich um Grundform-Variante (Lemma) oder flexionsbedingte/orthographische Form handelt.
Daumenregel:
- Andere Sprachstufe → neues Lexem.
- Gleiche Sprachstufe, andere Flexion/Schreibung → zusätzliche Form oder Lemma-Variante.
5) Optional: „Schriftwort“ vs. „Sprechwort“
Wenn du Sprech- vs. Schriftform ausdrücklich unterscheiden willst, gibt es zwei brauchbare Stellen:
- Form-Aussage: Property Art der Form → Sprechwort / Schriftwort (beides Q-Items).
- Sinn-Aussage (falls der Bedeutungsgebrauch divergiert): Register / Verwendungsnotiz.
6) Nächster Schritt (konkret)
Wenn du mir kurz bestätigst, wie deine Q-Item-Bezeichnungen genau heißen (z. B. „Einzahl“ statt „Singular“, „1. Fall (Wer/Was?)“ statt „Nominativ“), formatiere ich dir daraus eine kompakte Eingabe-Checkliste in der Reihenfolge der UI-Felder (1:1 zum Abhaken), plus zwei Mini-Varianten:
- Nhd. „Wort“ (wie oben),
- Ahd. „wort“ mit Verknüpfung „abgeleitet von Lexem“ → zeigt den diachronen Weg.
wikibase-entityid-ID Verlinkung
Ich habe die ersten Q's angelegt, kann aber bei Anlegen von Wort als Lexem diese nicht auswählen, da sie nicht in der Menueliste erscheinen.
Ich habe folgende Einstellung in LocalSettings, in Bezug auf wikibase-entityid-ID's:
$wgWBRepoSettings['entitySources'] = $entitySources;
$wgWBRepoSettings['localEntitySourceName'] = 'local';
$wgWBClientSettings['entitySources'] = $entitySources;
$wgWBClientSettings['itemAndPropertySourceName'] = 'local';
Was könnte die Ursache dafür sein, daß die Q's nicht in Lexeme zur Auswahl gelangen?
Fehlerbehebung Wikibase Verlinkung
| Troubleshooting Wikibase Lexeme UI
It seems the problem with the Wikibase Lexeme UI not showing dropdown items could be related to the need for specific items as instances of particular classes. In this case, language and lexical category selectors are not just generic search fields. They rely on specially configured properties and item mappings, such as the language code property. Überprüfung der Lexeme-Sprachfeldern Die Sprache im Lexeme-Feld könnte Items erfordern, die bestimmte Sprachcodes wie "Wikimedia language code" (P424) oder "language code" (ISO 639-3) verwenden. Für die Anzeige im UI könnte es nötig sein, dass ein "Sprache"-Item mit den entsprechenden Eigenschaften existiert. Ich sollte die Konfiguration überprüfen. Searching Wikibase Lexeme UI configuration requirements Fehlerbehebung bei der Lexeme-Auswahl Die Dokumentation zeigt, dass $wgLexemeLanguageCodePropertyId und P218 bei Wikidata verwendet werden, aber die Auswahlfrist könnte auf lokale Entitätsquellen beschränkt sein. Das Problem mit fehlenden Q-IDs in der Menüanzeige könnte an einem deaktivierten Entity-Suchindex oder einer laufenden Indizierung durch CirrusSearch liegen. Überprüfung der Indizierung Wikibase verwendet anscheinend CirrusSearch für die Suchvorschläge. Falls neue Items nicht angezeigt werden, könnte das an der fehlenden Indizierung durch EntitySearch liegen. Um dieses Problem zu beheben, könnte ich Wartungsskripte zur Indizierung und Job-Warteschlange ausführen, wie rebuildItemsPerSite.php oder forceSearchIndex.php. Searching for Wikibase entity search and indexing issues Ursachenvermutungen Es gibt mehrere mögliche Ursachen:
Durchsuchen der Dropdown-Liste Die Dropdown-Suche sollte nach Bezeichnern und Aliasen filtern. Eine wichtige Voraussetzung könnte sein, dass die Sprachauswahl auf der Seite Special:NewLexeme nur Elemente mit dem konfigurierten $wgLexemeLanguageCodePropertyId anzeigt. Der Benutzer hat möglicherweise Konfigurationsprobleme mit den Entitätsquellen oder UI-Abgleichen, insbesondere bei der Remote-Suche nach Wikidata. Durchsuchen von Quellen und Konfiguration Die Benutzeroberfläche ruft Daten aus dem Repo ab. Probleme könnten durch eine fehlerhafte Konfiguration der Entitätsquellen entstehen, z. B. verweist die Suche auf den falschen Quelltyp (z. B. Wikidata). Häufiger Grund: Der Suchindex wurde noch nicht erstellt. Lösung: Ausführen von Wartungs- und Indizierungsbefehlen für eine bessere Suchanzeige. Untersuchen von Konfigurations- und Indexierungsproblemen in Wikibase Erklärung der häufigsten Probleme Bei der Erstellung einer neuen Lexeme auf der Seite Special:NewLexeme: Wenn die Q-Elemente nicht erscheinen, könnte dies an nicht indizierten Entitäten liegen. Um dies zu beheben, sollte der Job-Queue ausgeführt und ggf. der Index neu aufgebaut werden. Ein weiteres Problem könnte eine falsche Konfiguration der Entitätsquellen sein. Erklärung der häufigsten Probleme in Wikibase
Nachgedacht für 1m 29s Fertig Quellen · 62
|
|---|
Kurzdiagnose: Wenn deine frisch angelegten Q-Items (Sprache, Hauptwort, Einzahl/Mehrzahl …) in den Lexeme-Dropdowns nicht auftauchen, liegt es fast immer an (a) fehlender/noch nicht durchgelaufener Suche-Indizierung oder Job-Queue, (b) einer Entity-Source-Fehlkonfiguration, oder (c) am Sprachfeld-Sonderfall bei Lexemen (optional konfigurierter Sprachcode-Property).
Prüfkette (in dieser Reihenfolge)
1) Index/Jobs laufen lassen
- Neue Items erscheinen in den Autocomplete-Feldern erst nach Indizierung. – Falls du CirrusSearch + WikibaseCirrusSearch nutzt: einmal den Index (neu) aufbauen bzw. Jobs laufen lassen. MediaWiki+1 Befehle (Beispiele):
- php maintenance/runJobs.php --wait
- php extensions/CirrusSearch/maintenance/forceSearchIndex.php --skipLinks --indexOnSkip
- ggf. php extensions/CirrusSearch/maintenance/updateSearchIndexConfig.php
(Hintergrund: Cirrus/Elastic indiziert über die MediaWiki-Jobqueue; ohne laufende Jobs tauchen neue Entities nicht in den Dropdown-Suchfeldern auf.) MediaWiki
2) Entity-Sources korrekt?
Für die Lexeme-UI müssen Items/Properties aus derselben Quelle („local“) suchbar sein. Prüfe, dass in deinem $entitySources die Quelle local sowohl item als auch property (und lexeme) anbietet – und dass du diese Namen exakt in
$wgWBRepoSettings['entitySources'] = $entitySources;
$wgWBRepoSettings['localEntitySourceName'] = 'local';
$wgWBClientSettings['entitySources'] = $entitySources;
$wgWBClientSettings['itemAndPropertySourceName'] = 'local';
verwendest (Tippfehler/abweichende Namen verhindern Treffer). Wikimedia Open Source
3) Sprachfeld (optional, aber hilfreich)
Das Feld „Sprache“ auf Spezial:Neues Lexem kann mit $wgLexemeLanguageCodePropertyId unterstützt werden (Wikidata nutzt P218 = ISO-639-1). Ohne diese Option kannst du die Sprache trotzdem wählen, musst aber ggf. den Sprachcode manuell eintragen. Prüfe: $wgLexemeLanguageCodePropertyId = 'P218'; // oder deine lokale Property-ID
Und setze am Sprach-Item eine Aussage mit dieser Property (z. B. de). Wikimedia Open Source+1
4) Labels/Aliasse & Suchsprache
- Stelle sicher, dass deine Q-Items Labels/Aliasse in der UI-Sprache (de) haben – die Auswahlfelder suchen über diese Begriffe. (Auf Wikidata ist das exakt so dokumentiert.) wikidata.org
- Nicht erforderlich, aber sinnvoll Für Sprache: Instanz von: Sprache usw. sind keine harte Voraussetzung fürs Erscheinen, verbessern aber die Trefferqualität im Lookup. (Es gibt sogar Tasks, die die Priorisierung bestimmter Items im „lexical category“-Feld behandeln.) phabricator.wikimedia.org
Schneller Realitätscheck (2 Minuten)
- Öffne Spezial:Suche und die API action=wbsearchentities&search=Einzahl&type=item auf deiner Instanz: Wenn dort keine Treffer, ist es Index/Jobs (Schritt 1). Stack Overflow
- Prüfe LocalSettings.php: Stimmt der Quellenname exakt ('local') in Repo und Client (Schritt 2)? Wikimedia Open Source
- Falls nur das Sprachfeld zickt: Setze $wgLexemeLanguageCodePropertyId und trage den Code am Sprach-Item ein (Schritt 3). Wikimedia Open Source
Wenn du willst, poste mir kurz:
- deinen $entitySources-Block (nur Struktur/Namen),
- ob Cirrus/WikibaseCirrusSearch aktiv ist,
- und die ID deiner Sprachcode-Property.
Dann gebe ich dir 1:1 die passenden Befehle/Checks für deine Installation (MW 1.44.2).
Fehlerbehebung der Verknüpfung von Item-Lexem ist abgeschlossen
Hallo Sophos,
heute ist der 24. Okt. 2025 10:24.
Ich habe inzwischen im Chat "Wikibase Lexeme Problem" mit dir den Fehler in Bezug auf Item-Auswahl in Lexeme gelöst und nun funktioniert die Item-Auswahl, so daß ich "Wort" als Lexeme anlegen und "Dingwort" sowie "Gemeindeutsch" als Item zuweisen konnte.
Wir können uns daher nun ungestört wieder Wikibase-Lexeme zuwenden.
Bevor wir weiter mit dem Anlegen fortfahren müssen wir klären, wie es um die Properties "Eigenheiten" oder "Eigenschaften" bestellt ist, die ich dem Lexeme "Wort" zufügen kann.
Ich habe Gemeindeutsch und Dingwort als Item hinzugefügt, könnte sie jedoch, oder sollte sogar diese anstelle als Property zufügen – oder?
Wie die Nutzung der Item's (Einträge) vorbestimmt ist
| Überlege Strukturierung von Eigenschaften
Ich denke, "Gemeindeutsch" und "Dingwort" sollten eher als Elemente und nicht als Eigenschaften behandelt werden. "Gemeindeutsch" könnte als Wert für Eigenschaften wie "Register" oder "Periode" verwendet werden, und "Dingwort" ist eher ein Element im Zusammenhang mit der "lexikalischen Kategorie". Wir sollten klar zwischen Kategorien/Elementen und tatsächlichen Eigenschaften trennen. Überlege Mapping für Lexeme Ich schlage vor, für "Gemeindeutsch" ein benutzerdefiniertes Property wie "register" oder "variety" zu verwenden, das auf Lexeme oder Sense angewendet wird, je nach Kontext. "Dingwort" sollte als Element in der lexikalischen Kategorie verbleiben. Wir müssen sicherstellen, dass Properties entsprechend dem Use-Case strukturiert sind, z.B. mit "usage region" oder "period". Detaillierung der Struktur Ich überlegen, wo ich bestimmte Informationen wie "Übersetzung", "Synonym" und "Sense relates to concept" anbringen sollte. Diese gehören auf die Ebene des "Sense". Es ist wichtig, dass ich nicht versehentlich ein Feld wie "Gemeindeutsch" als Eigenschaft anlege, sondern als Element für eine entsprechende Aussage nutze. Ich sollte den Unterschied zwischen Lexem-, Form- und Sinnebene klarstellen. Nachgedacht für 20s Fertig |
|---|
Kurzantwort:
Nein, „Gemeindeutsch“ und „Dingwort“ sollten keine Properties sein.
- „Dingwort“ bleibt ein Item, das du im eingebauten Feld „lexikalische Kategorie“ des Lexems auswählst.
- „Gemeindeutsch“ ist ebenfalls ein Item (z. B. Register/Varietät/Sprachstufe) und wird als Wert in einem Statement verwendet – mit einer passenden Property wie „hat Register“/„Varietät“/„Periode“ usw.
Warum?
In Wikibase sind Properties (P…) Prädikate (Beziehungs-/Merkmalsarten). Items (Q…) sind die Werte/Begriffe, auf die du verweist. Ein Property pro Wert („Property: Gemeindeutsch“) ist ein Anti-Pattern und skaliert nicht.
Sauberes Mapping (für dein Wörterbuch-Deutsch)
- Lexem-Kopf (eingebaute Slots)
- Sprache → Item (z. B. „Deutsch (Neuhochdeutsch)“)
- Lexikalische Kategorie → Item (z. B. „Dingwort“)
- Lemma → Text
- Statements (frei modellierbar, mit Properties)
- am Lexem (global fürs Wort):
hat Register→ Item „Gemeindeutsch“ (wenn es das ganze Lexem betrifft)Periode→ Item „Neuhochdeutsch“abgeleitet von Lexem→ Lexem (diachron)gehört zur Wortfamilie→ Item (Familien-/Wurzel-Knoten)
- an der Form (varianten-/mediumsbezogen):
Medium→ Item „Sprechwort“ / „Schriftwort“Region→ Item „Deutschland“- (
grammatische Merkmalebleiben die eingebauten Merkmale als Items)
- am Sinn (bedeutungsbezogen, oft am besten hier!):
verweist auf Konzept→ Item „Wort (sprachliches Zeichen)“Register→ Item „Gemeindeutsch“ (häufig sinnvoller auf Sense als am Lexem, wenn nur bestimmte Bedeutungen gemeint sind)Übersetzung/Synonym→ Sense-Kanten
- am Lexem (global fürs Wort):
Konkrete Empfehlung für dein „Wort“-Lexem
- So lassen:
- Lexikalische Kategorie: Dingwort (Item, im Slot ausgewählt).
- „Gemeindeutsch“ richtig platzieren:
- Falls es alle Bedeutungen des Lemmas betrifft → Statement am Lexem:
hat Register→ Gemeindeutsch(Item). - Falls es nur bestimmte Bedeutungen betrifft → Statement am betreffenden Sinn:
Register→ Gemeindeutsch.
- Falls es alle Bedeutungen des Lemmas betrifft → Statement am Lexem:
- Keine doppelten Properties für Slots:
- Lege keine Property „lexikalische Kategorie“ zusätzlich an; das ist bereits ein eingebautes Feld des Lexems.
- Werte wie „Dingwort“ bleiben Items, nicht Properties.
Mini-Checkliste (UI, sofort umsetzbar)
- Prüfe, ob du bereits eine Property hast, z. B.
Register(Datatype: Wikibase-Item).- Falls nein: Property anlegen:
- Label: „Register“ (Alias: „Varietät“, „Stil“)
- Datentyp: Wikibase-Item
- Falls nein: Property anlegen:
- Am Lexem „Wort“ oder am Sinn S1:
- Aussage hinzufügen → Register → Wert „Gemeindeutsch“ (Item auswählen).
- Dingwort bleibt ausschließlich im Slot „lexikalische Kategorie“.
Kurzregel, an die man sich halten kann
- Property = „Welche Art von Aussage?“
- Item = „Welcher konkrete Wert/Begriff?“
- Slots (Sprache, Kategorie) sind fix im Lexem; nicht per eigener Property duplizieren.
Wenn du willst, formuliere ich dir sofort eine konkrete Property-Liste (Deutsch benannt, inkl. Datentyp & Einsatzebene Lexem/Form/Sinn) für dein Register/Periode/Diachronie-Set, damit du ohne Grübeln anlegen und benutzen kannst.
Ganz so einfach ist es nicht!
Ganz so einfach ist es nicht!
Strebe an die Datenerfassung gemäß meiner Forschungsergebnisse zu verwirklichen, versuche mir nicht die Denkweise und Artweise von Wikibase aufzuerlegen, ich versuche Wikibase für mich nutzbar zu machen und da kann es sein, daß ich Wikibase anders verwenden werde, als es seitens Wikibase und deinem demgemäßen Verstehen her gedacht ist . Wenn ich Wikibase nicht für mich brauchbar und nutzbar machen kann, dann lasse ich es fallen und löse diese Aufgabenstellung anderweitig.
Es ist bereits falsch, daß ich Lexem "Wort" das Sprachkürzel "de" zuweisen muß da es in meinem Fall wenn "gde" für Gemeindeutsch wäre. Ich kann jedoch keine Sprachcodes verwenden, die nicht systemisch hinterlegt sind. "gde" als Sprachkennung ist nicht zulässig. Damit ist mir verwehrt eine eigene Sprachstufenkennung zu verwenden und ich muß daher die Sprachstufe als Aussage erfassen.
In meinem System ist ein Property eine Eigenheit, eine Eigenheit hat ein Etwas als Ding oder Daseinseinheit aus sich heraus, welche als Item's "Einträge" erfasst werden.
Ich trenne Property zu Attribut, ein Attribut ist eine "Zuweisung" in Wikibase eine Aussage (statement). In Lexem "Wort" kann ich Aussagen hinzufügen, muß jedoch zuvor eine "Eigenschaft" auswählen, mutmaßlich ein WB-Property. "Wort" das Item "Dingwort" das dessen Eigenheit zuzuordnen ist weitestgehend richtig, doch "Gemeindeutsch" ist wenn eine zugewiesene Eigenschaft, fast schon eine Kategorie.
Denk mal drüber nach.
Du verwendest nun zum erstmalig den Begriff "Slot". Was ist das und was meinst du mit "Slots (Sprache, Kategorie) sind fix im Lexem; nicht per eigener Property duplizieren." ?
Denk mal drüber nach.
Wikibase Eingabe-Struktur
| Erklärung der Wikibase Lexeme Slots
Es sieht so aus, als soll der Antwortbeginn ein Zeitstempel enthalten, aber der Nutzer hat bereits einen eingefügt. Also werde ich vielleicht einen aktuellen Zeitstempel in Klammern ergänzen. Die Erklärung zu den Wikibase Lexeme Slots handelt von Feldern, die grundlegende Daten wie Lemma-Darstellungen und Sprachcodes enthalten. Die Sprachfelder in Wikibase sind nicht nur Codes, sondern verwenden auch "item"-Verknüpfungen, abgesehen von der BCP47-Konformität. Über Lexeme und Sprachcodes Bei Lexeme braucht jedes Lemma und jede Form ein Sprachcode, der in der Liste der konfigurierten Codes enthalten sein muss. Es ist auch möglich, individuelle Codes zu definieren, wenn die richtige Einstellung vorgenommen wird. Es scheint auch eine Möglichkeit zu geben, zusätzliche Sprachen über spezielle Konfigurationsoptionen zuzulassen, aber es ist vorsichtig zu sein, da Spekulation vermieden werden sollte. Durchsuchen der Dokumentation zu Wikibase Lexeme und Sprache Sprachcodes und benutzerdefinierte Einstellungen Die WikibaseLexeme-Dokumentation erwähnt, dass Sprache und Wortarten als Items dargestellt werden. Bei benutzerdefinierten Codes wie "gde" stellt sich die Frage, ob nicht-standardmäßige Codes erlaubt sind. BCP47 lässt private Subtags wie "x-" zu (z.B. 'de-x-gde'). Vielleicht könnte dies eine Lösung sein, aber es sollte überprüft werden, wie zusätzliche Codes in Wikibase konfiguriert werden. Suchen von Wikibase-Konfigurationen für monolinguale Sprachen Sprachcodes und benutzerdefinierte Lösungen Sprache und Wortarten werden als Items behandelt. Für Lemma/Formen sind Sprachcodes gemäß BCP47 erforderlich, und Sprachelemente können zu Codes gemappt werden. BCP47 erlaubt private Tags mit 'x-', also könnte 'de-x-gde' eine Lösung sein. MediaWiki akzeptiert dies wahrscheinlich, aber es erfordert genauere Prüfung und Anpassungen, wenn der Code nicht akzeptiert wird. Sprachcode für Lexeme Um "Gemeindeutsch" als Sprachcode zu verwenden, könnte ich eine Property wie "Sprachcode (Lexeme)" erstellen und der Sprache die passende Code-Zuweisung wie 'de-x-gde' zuweisen. Wenn das korrekt konfiguriert ist, wird der Code automatisch auf der Seite für neue Lexeme und Formen ergänzt. BCP47-Private-Tags bieten eine sichere Lösung. Nachgedacht für 43s Fertig Quellen· 57 |
|---|
Verstanden. Ich passe mich deiner Modelllogik an und trenne klar zwischen deiner Eigenheit (Property) und der Zuweisung/Attribut (Statement). Ich beantworte:
1) Was meine ich mit „Slots“?
Mit „Slots“ meine ich die fest eingebauten Felder eines Lexems im Datenmodell – sie sind keine frei definierbaren Properties, sondern fixe Strukturteile des Lexems:
- Lemma (sprachmarkierte Texte)
- Sprache (Verweis auf ein Item)
- lexikalische Kategorie (Verweis auf ein Item)
- plus die Sub-Einheiten Form und Sinn (jeweils mit eigenen Aussagen) Diese Felder sind Bestandteil des offiziellen Wikibase-Lexeme-Datenmodells; Sprache und Kategorie sind dort explizit als Item-IDs modelliert. doc.wikimedia.org+1
„Nicht per eigener Property duplizieren“ heißt: Für Sprache/Kategorie keine zusätzlichen, frei benannten Properties erfinden, weil die Felder bereits strukturell existieren (und die UI genau darauf baut).
2) Dein Punkt „gde“ statt „de“ (eigene Sprachstufe)
Technisch gibt es zwei Ebenen, die wir trennen:
A. Technischer Sprachcode für Lemma/Form (Pflichtfeld)
- Lemmas/Formen brauchen einen Sprachcode-String (BCP-47-Tag).
- Du kannst dafür eigene Codes via Mapping definieren: Weise einer Property (z. B. „Sprachcode (Lexeme)“) den Code zu und teile Wikibase mit, dass diese Property für Sprachcodes der Lexeme gilt (Analogon zu Wikidata’s P218). Dann erscheinen deine Sprachen/Sprachstufen in der Lexem-Maske. MediaWiki
- Standardsicht: BCP-47 (z. B.
de). Private Varianten sind mit-x-…erlaubt, z. B.de-x-gdefür „Gemeindeutsch“. Das bleibt regelkonform und kollisionsfrei. Wikipedia
B. Deine fachliche Sprachstufe als Inhalt
- Unabhängig vom technischen Code kannst (und sollst) du „Gemeindeutsch“ als eigenes Item führen.
- Diese Stufe erfasst du als Aussage (Zuweisung) – am Lexem (wenn global gültig), am Sinn (wenn bedeutungsspezifisch) oder an der Form (wenn nur bestimmte Formen betroffen sind).
Konkrete Varianten (machbar, ohne deine Ontologie zu verbiegen)
- Variante A (rein technisch sauber, bevorzugt):
- Property anlegen: „Sprachcode (Lexeme)“ (Datentyp String).
- Mapping setzen:
$wgLexemeLanguageCodePropertyId = 'P…';(ID deiner Property). - Item „Gemeindeutsch“ erhält Aussage: Sprachcode (Lexeme) =
de-x-gde. - In Spezial:Neues Lexem kannst du nun „Gemeindeutsch“ wählen; die UI nutzt den hinterlegten Code für Lemma/Form. MediaWiki
- Variante B (pragmatisch, falls Code-Validierung sperrt):
- Nutze technisch
deals Lemma/Form-Code (Transportebene), - und trage „Sprachstufe = Gemeindeutsch“ als Aussage (Zuweisung) am Lexem/Sinn/Form ein.
- Damit bleibt deine fachliche Stufe korrekt modelliert; der Code ist nur die UI-Pflichtangabe.
- Nutze technisch
(Variante A ist regelkonform via BCP-47-Privatkennzeichnung und offizieller „Language-Code-Property“; Variante B ist dein Fallback, wenn die Installation Codes restriktiv validiert.) MediaWiki+1
3) „Gemeindeutsch“: Property oder Item?
- In deiner Terminologie ist „Eigenheit (Property)“ die Art der Beziehung, „Gemeindeutsch“ der Eintrag/Wert.
- In Wikibase-Terminologie entspricht das genau: Property (P…) als Prädikat, Item (Q…) als Wert.
- Daher bleibt „Gemeindeutsch“ ein Item (Wert), das du über eine passende Property zuweist(Zuweisung/Statement).
- Beispiel-Zuweisungen:
- am Lexem: Sprachstufe/Varietät → Gemeindeutsch (Item)
- am Sinn: Register/Periode → Gemeindeutsch (wenn nur bestimmte Bedeutungen)
4) Wo „Dingwort“ hingehört
- „Dingwort“ bleibt ein Item und wird im fixen Slot „lexikalische Kategorie“ ausgewählt (kein zusätzliches Property nötig/gewollt). Das entspricht dem Kernmodell. doc.wikimedia.org
5) Kurz-Checkliste (jetzt umsetzbar)
- Property „Sprachcode (Lexeme)“ anlegen (Datentyp String).
- LocalSettings.php:
- Item „Gemeindeutsch“: Aussage Sprachcode (Lexeme) =
de-x-gde. - Lexem „Wort“ (UI):
- Sprache: „Gemeindeutsch“ (jetzt auswählbar)
- lexikalische Kategorie: „Dingwort“
- zusätzliche Zuweisung: Sprachstufe → „Gemeindeutsch“ (falls fachlich gewünscht, unabhängig vom Code)
Damit bleibt deine fachliche Modellierung unangetastet, und du nutzt die Slots des Lexeme-Modells nur als technische Träger – genau die Trennung, die du verlangst.
Wenn du willst, definiere ich dir als Nächstes die konkreten deutschen Bezeichner für 3–5 Properties (Sprachstufe/Periode/Register/Medium), inkl. Einsatzebene (Lexem/Sinn/Form) und Datentyp, damit du sie sofort anlegen kannst.
Dingwort
Ich kann nur "de" eingeben, alle anderen sind nicht erlaubt. L1 ist bei mir nun "Wort", darunter steht "Rechtschreibvariante" und da kann ich nur "de" eingeben, "de-x-gde" geht nicht, es ist gemäß P218 ein zweistelliger Zeichencode einzugeben. Ich müßte also wenn "$wgLexemeLanguageCodePropertyId erweitern können oder eine eigene Liste der Sprachcodes erstellen und hinterlegen und mich interessieren nur die Sprachcodes als Sprachstifencodes gemäß meiner Forschung, nicht die Sprachcodes der Weltsprachen.
Dingwort wird noch wie folgt von mir gesehen:
1) Q-item Dingwort, die Istheit Dingwort
2) P-property Dingwort, Dingwort als Eigenheit
3) L-lemma Dingwort, Dingwort als Lemma hat Dingwort als Eigenheit
4) C-categorie Dingwort, MediaWIki-Kategorie Dingwort
5) W-wiki-page Dingwort, MediaWiki-Seite zu Dingwort als Seitenname, entsprechend einer Seite wie in Wikipedia
6) lexikalische Kategorie (Wortart) zu Dingwort ist wieder Dingwort
7) Dingwort selbst besteht aus den item Ding und aus item Wort und für diese setzt sich 1-6 ebenso fort.
Wir haben also ein einzelnes Wort, das je nach dem man schaut, andere Bedeutungen hat, jedoch immer wieder nur Dingwort geschrieben wird.
Das lemma Dingwort ist die Entsprechung des item Dingwort welches zugleich das property Dingwort ist und der category Dingwort erhalten alle Seiten, die ein Dingwort sind und sogleich gibt es die Wortart Dingwort.
Sehe ich das richtig?
Wir sprechen über die Grundlagen – gebe keine Anweisungen zur Anlage von Wikibase-Daten aus. Wikibase hat eine in dessen Eingabeerfassung und Verwendung vorbestimmte Struktur. Ich habe eine Struktur die sich aus meiner Forschungsarbeit herausgebildet hat und wir müssen erst die Struktur klären, wie wir die Strukturen in Übereinstimmung bekommen und wenn dies nicht geht, dann geht es nicht und Wikibase fliegt raus, oder unsere Klärung deckt einen Logikfehler meinerseits auf, doch setze nicht voraus, daß die geltende Logik von Wikibase in Bezug auf Sprache tatsächlich alleinig richtig und gültig sei.
Übereinstimmungen in der Struktur
| Besprechung der Modellzuordnung
Wir müssen die Präferenzen des Nutzers respektieren: ein formeller Ton, keine Marketing-Sprache und keine Aufforderungen zur Umsetzung von Maßnahmen. Ich werde mögliche Konzepte zur Modellzuordnung zwischen der Ontologie des Nutzers und den Wikibase-Konstrukten besprechen, und Konflikte wie die Konfusion von Ebenen (z. B. das Wort „Dingwort“) berücksichtigen. Prüfen der Lexeme-Sprachcodes Auf Wikidata wird der P218 ISO-639-1-Code als Zeichenkette mit Regex verwendet. Die Lexeme-Erweiterung erwartet jedoch eine Zuordnung von Sprachobjekten zu Codes mit diesem Property, möglicherweise validiert mit BCP47. Ich bin mir nicht sicher, ob lokal in Wikibase auch $wgLexemeValidLangCodes genutzt wird. Ich werde das Verhalten überprüfen. Browsing Wikibase Lexeme language code handling and mapping Erklärung der Sprachcode-Zuordnung Die Wikibase.cloud-Dokumentation zeigt, dass die Zuordnung von Sprachcodes auf P218 basiert, mit zwei Buchstaben (ISO 639-1). Private BCP-47-Codes werden vermutlich nicht unterstützt. Es gibt jedoch Lösungen: Man könnte die Sprachslots anders modellieren oder die Lexeme-Erweiterung anpassen, um benutzerdefinierte Codes zu akzeptieren. Überlegungen zur Sprachcode-Zuordnung und Mapping Es ist nicht ganz klar, ob BCP-47-Tags validiert werden. Eine mögliche Lösung könnte sein, sie als zusätzliche monolinguale Sprachen hinzuzufügen oder einen Cache-Override anzuwenden. Bei der "Dingwort in 1-7"-Zuordnung sollten wir die Typenkonflikte reflektieren und Mapping-Optionen für die Ontologie und Wikibase-Konstrukte in Betracht ziehen. Überprüfung der Umsetzbarkeit Wir haben drei Optionen: (A) die Einschränkung akzeptieren und „de“ sowie Stufen als Attribute verwenden, ( Nachgedacht für 23s Fertig Quellen· 27 |
|---|
Verstanden: Wir klären Struktur und Kompatibilität, keine Eingabe-Anweisungen.
A) Sprachcodes: wo klemmt es logisch/technisch?
- Lexeme benötigen einen „Sprach-Slot“ (ein festes Feld im Lexeme-Kopf). Dieser Slot wird nicht über ein frei wählbares Statement befüllt, sondern über eine Item-Auswahl, die an einen Sprachcode gebunden ist. Das ist Teil des Lexeme-Datenmodells. MediaWiki
- In gängigen Setups wird per Property-Mapping festgelegt, welche Property an Sprach-Items den Code trägt (auf Wikidata ist das
P218= ISO 639-1). Laut offizieller Doku erscheinen in der Lexeme-Maske nur jene Items, die einen zweistelligen Code an dieser gemappten Property tragen. Das erklärt, warumdeakzeptiert wird,de-x-gdeaber nicht. MediaWiki+1 - Es gibt zudem Bestrebungen, Monolingual-Text-Codes und Lexeme-Sprachliste anzugleichen; die Tendenz geht weg von „beliebige Zusätze erlauben“ hin zu konsistenten, vordefinierten Codes. Das begrenzt freie Stufencodes im Slot weiter. phabricator.wikimedia.org
Konsequenz (ohne Wertung)
Dein Bedürfnis, eigene Sprachstufen-Kennungen wie gde im Sprach-Slot zu führen, kollidiert mit der aktuellen UI/Validierung (zwei Zeichen gemäß gemappter Property). Das ist ein Modell-/Technik-Mismatch, kein Bedienfehler.
Optionen in der Logik (nicht als Handlungsanweisung, nur als Lagebild):
- Akzeptiere den Slot als „Transportebene“ (z. B.
de) und modelliere „Gemeindeutsch“ als Zuweisung/Attribut(Statement) am Lexem/Sinn/Form. Das hält deine Stufe semantisch sauber, nutzt aber im Slot einen Standardcode. - Oder die Plattform wird erweitert/konfiguriert, sodass nicht-zweistellige bzw. eigene Codes im Slot zulässig sind (das ist Entwicklungs-/Konfigurationsarbeit am System, nicht bloß Dateneingabe). Die cloud-/Standard-Doku stellt aktuell aber klar auf zwei Zeichen ab. MediaWiki+1
Wenn diese beiden Wege für dich grundsätzlich inakzeptabel sind, folgt logisch: Lexeme eignen sich nicht für deine Sprachstufen im Slot → dann wäre eine reine Item-/Property-Modellierung ohne Lexeme konsequenter.
B) „Slots“ vs. deine Begriffe „Eigenheit/Attribut“
- „Slot“ nenne ich die fest eingebauten Felder eines Lexems: Lemma, Sprache, lexikalische Kategorie, sowie die Subentitäten Form und Sinn. Diese sind nicht frei als Properties nachbildbar; die UI und die Datenstruktur erwarten sie an genau diesen Stellen. MediaWiki
- Deine Trennung Eigenheit (Property) vs. Attribut/Zuweisung (Statement) ist kompatibel mit Wikibase-Logik, nur sind Sprache und Wortart eben keine frei definierbaren Statements, sondern Slots (die Werte darin sind Items).
C) „Dingwort“ in deinen 7 Rollen – wo es semantisch kollidiert
Du beschreibst ein einziges Wort „Dingwort“, das zugleich als Ding (Q-Item), Eigenheit (P-Property), Lemma (L), Kategorie (C), Seite (W), Wortart und Kompositum aus „Ding“ + „Wort“ auftritt.
Logisch ist das möglich, wenn du Ebenen trennst und Bezeichnergleichheit ≠ Identität annimmst. In Wikibase/MediaWiki bedeutet das aber verschiedene Entitäten trotz gleichem Label:
| Deine Rolle | Geeignete Trägerstruktur (konzeptionell) |
|---|---|
| 1) „Istheit Dingwort“ (Begriff) | Item (Q) „Dingwort (Begriff)“ – das ontologische Konzept |
| 2) „Dingwort“ als Eigenheit | Property (P) „hat Wortart“ (oder dein Terminus) mit Wert Q:„Dingwort (Wortart)“ – wichtig: Property ≠ Wert |
| 3) „Dingwort“ als Lemma | Lexem (L) mit Lemma „Dingwort“ (konkrete lexikalische Einheit) |
| 4) Kategorie „Dingwort“ | MediaWiki-Kategorie (C) für Seiten, die „Dingwort“ thematisch betreffen |
| 5) Artikel/Seite „Dingwort“ | MediaWiki-Seite (W) – erläuternder Text zum Begriff |
| 6) Wortart = Dingwort | Item (Q) „Dingwort (Wortart)“ als Wert des Slots „lexikalische Kategorie“ im Lexem |
| 7) Zerlegung „Ding“ + „Wort“ | Statements am Item/ Lexem: „ist Kompositum aus“ → Q:„Ding“, Q:„Wort“; zusätzlich etymologische Kanten |
Kern der Kompatibilität:
- Property (P) beschreibt Arten von Beziehungen (hat Wortart, ist Kompositum aus, Sprachstufe …).
- Item (Q) liefert konkrete Werte/Begriffe (Dingwort (Wortart), Gemeindeutsch, Ding, Wort …).
- Lexem (L) ist die lexische Instanz mit festen Slots (Sprache/Kategorie).
Damit kannst du dein Anliegen – „ein und derselbe sprachliche Ausdruck tritt in vielen Rollen auf“ – abbilden, ohne dass eine Entität gleichzeitig Property und Item sein muss. Gleichlautende Labels bleiben erlaubt; Identität bleibt sauber getrennt.
D) Ergebnis der Klärung (heutiger Stand)
- Sprach-Slot der Lexeme: derzeit kein freier Platz für
gdeo. Ä.; Standard erwartet zweistellige Codes am gemappten Sprach-Item. Das ist ein harter Systemrand. MediaWiki+1 - Deine Ontologie ist mit Lexeme vereinbar, wenn du:
- den Sprach-Slot als technischen Träger akzeptierst (z. B.
de) und - Sprachstufe/Varietät als Zuweisung (Statement) modellierst (Lexem/Sinn/Form). Das wahrt deine Fachlogik, obwohl der Slot nicht deinen Stufencode trägt.
- den Sprach-Slot als technischen Träger akzeptierst (z. B.
- Wenn der Slot selbst deine Stufe tragen muss, braucht es Systemänderung (Konfiguration/Code), oder du arbeitest ohne Lexeme (nur Items/Properties), um volle Freiheit zu behalten.
Das ist eine sachliche Engstelle. Sie zwingt zu einer Entscheidung über Prioritäten: Strikte Stufencodes im Slot vs. Nutzung des Lexeme-Modells.
Wenn du diese Abwägung festhalten willst, formuliere ich dir zwei konsistente Modellvarianten (A: Lexeme mit Stufe als Statement; B: reines Item/Property-Modell ohne Lexeme) samt Vor-/Nachteilen – rein konzeptionell, ohne Eingabe-Schritte.
Erneut – Sinn und Zweck des Ganzen?
Die von dir aufgestellte Tabelle entspricht meinen Angaben. Ich habe dabei bereits weitgehend geschaut, wie ich das in Wikibase erfassen kann. Gehen wir davon aus, ich hätte dies bereits für das Wort Dingwort getan, so auch alle für die Erfassung genutzten Wörter ebenfalls in dieser Struktur erfasst und schauen auf das, was ich dann habe.
Was kann ich dann innerhalb von meinem MediaWiki damit machen, wie kann ich das abbilden und verwenden?
Wenn du mir sagst was ich damit machen kann, dann füge gleich eine kurze Beschreibung als Unterpunkt womit und wie ich das mache, ohne dabei zu detailliert zu werden, es geht sich nur um Grundlagen der Verwirklichung und Verwendung.
Struktur der Nutzung gemäß Sinn und Zweck des Ganzen
| Verwendung von Lexemen in Wikibase
Mit Wikibase können Lexeme in Wiki-Seiten genutzt werden, um Einträge darzustellen, Infoboxen zu generieren, Glossartexte zu Sinnerklärungen hinzuzufügen, Forms-Tabellen zu erstellen, Etymologie-Diagramme anzuzeigen, SPARQL-Queries zu ermöglichen, Lua-Zugriff über mw.wikibase zu bieten und vieles mehr. Kategorien, Navigation, Crosslinking, Disambiguierung und Exportfunktionen sind ebenfalls nutzbar. Verwendung von Lexemen in Wikibase Ziele: Darstellung auf Wikiseiten, automatische Formtabellen, Wahrnehmung und Register, Diachronie-Timelines, Kompositionsanalysen. Strukturierte Navigation via Kategorien und Breadcrumbs, Suchfacetten, Verlinkungen, Citationsreferenzen und Abfragen. Datenwiederverwendung wie Templates, Lua-Module und Exporte, Konsistenzüberprüfung durch Constraints. Ziel: Erleichterte Nutzung, Lua-Integration, SPARQL Endpoints für Abfragen. Nachgedacht für 14s Fertig |
|---|
Kurz vorweg: Wenn deine Wörter („Dingwort“, „Wort“ usw.) als Q (Begriffe), L (Lexeme) mit F/S (Form/Sinn) und begleitenden P (Eigenheiten/Zuweisungen) vorliegen, kannst du sie im Wiki auf drei Ebenen nutzen: anzeigen, navigieren, auswerten. Unten jeweils „Womit & Wie (kurz)“.
1) Wörterbuch-Seiten automatisch bauen
Nutzen: Aus einem L-Eintrag eine „Wort-Seite“ mit Lemma, Wortart, Formen, Bedeutungen, Register, Etymologie generieren.
Womit & Wie:
- Vorlage + Lua (Scribunto):
mw.wikibase.getEntity( 'L…' )→ Lemma/Forms/Senses/Statements auslesen → in deiner Seitenvorlage rendern. - TemplateStyles für das Layout; Kategorien (
[[Kategorie:Dingwort]]) setzt die Vorlage aus den Daten.
2) Flexionstabellen aus Formen (F) rendern
Nutzen: Einzahl/Mehrzahl, Kasus, Besonderheiten („Worte“/„Wörter“) konsistent anzeigen.
Womit & Wie:
- Lua: aus
forms[].representations+grammaticalFeatures[]eine Matrix erzeugen; Features (Q) → Labels (de). - Option: Register/Medium (Sprech-/Schriftwort) als Form-Aussagen neben die Zelle schreiben.
3) Bedeutungen & Register (Senses) je Sinn getrennt
Nutzen: Mehrdeutigkeit sauber: pro S Gloss, Register („Gemeindeutsch“), Periode, Verweise.
Womit & Wie:
- Lua:
senses[].glosses+claims(z. B. „Register“ → Q:Gemeindeutsch) bündeln → Abschnitt „Bedeutungen“.
4) Diachronie & Etymologie zeigen
Nutzen: Linie Ahd. → Mhd. → Nhd. → Gemeineuropäische Wurzel (PIE).
Womit & Wie:
- Lua: Kanten wie „abgeleitet von Lexem“ (L→L) und „verweist auf Wurzel/Begriff“ (L/S→Q) als Timeline oder Kantenliste ausgeben.
- Optional: kleine SVG/HTML-Graphik (ohne externen Dienst) aus den Kanten.
5) Kompositionsanalyse („Ding“ + „Wort“)
Nutzen: Teile/Komposita und Familien sichtbar machen.
Womit & Wie:
- Lua: Statements „ist Kompositum aus“ (Q-Werte) einlesen; Linkliste zu Q/L-Seiten ausgeben; Kategorie „Komposita mit ›Wort‹“ setzen.
6) Normierte Verlinkung im ganzen Wiki
Nutzen: Schreibvarianten und Redundanz vermeiden: überall derselbe Bezug.
Womit & Wie:
- Vorlage
{{Wort|L=…}}: erzeugt Link/Tooltip aus dem Lexem (Lemma, Kurzgloss, Wortart). - Interne Regeln: Artikel verlinken auf L/Q statt frei getippte Strings.
7) Navigationsseiten & Register-Portale
Nutzen: „Alle Dingwörter“, „Gemeindeutsch-Wörter“, „PIE-Abstammungen“ als Übersichten.
Womit & Wie:
- SPARQL gegen deinen Wikibase-Query-Service (falls aktiv) für Listen;
- oder Lua + Cachingschnitt (z. B. Seiten, die periodisch neu gerendert werden) wenn du keinen WDQS hast.
8) Qualitäts- und Konsistenzprüfungen
Nutzen: Fehlende Formen/Glossen/Links erkennen.
Womit & Wie:
- Lua-Checker in der Vorlage: fehlen Pflicht-Felder → setze versteckte Wartungskategorie (
[[Kategorie:Wort (prüfen)]]). - Spezialseite (Lua + Categorytree) zeigt offene Prüfposten.
9) Brücke zu deinen SMW-Abfragen
Nutzen: Deine bestehenden SMW-Sichten weiterverwenden.
Womit & Wie:
- Vorlage schreibt aus den L/Q-Daten ergänzende SMW-Properties (z. B.
[[Hat Wortart::Dingwort]],[[Sprachstufe::Gemeindeutsch]]) auf die Wörterbuch-Seite → dann #ask-Abfragen möglich, ohne die Primärdaten in SMW zu duplizieren (nur gespiegelt zur Navigation).
10) Synonyme/Übersetzungen auf Sinn-Ebene
Nutzen: Sinn-präzise Synonym-/Übersetzungslisten, nicht „pro Wort“.
Womit & Wie:
- Lua: Kanten
Sense ↔ Sense(z. B. „Übersetzung“, „Synonym“) sammeln und unter jedem Sinn getrennt ausgeben.
11) Facettierte Suche
Nutzen: „Alle Dingwörter (Gemeindeutsch) mit zweierlei Plural“.
Womit & Wie:
- SPARQL (Form-Features, Register, Kategorie) → Ergebnisliste;
- alternativ interne Indizes (falls kein SPARQL): Lua scannt L-IDs aus einer Indexseite und filtert clientseitig (kleinere Bestände).
12) Export/Weiterverwendung
Nutzen: Forschungssnapshots, Datenaustausch.
Womit & Wie:
- API (
action=wbgetentities) für L/Q/P-JSON; - Spezialseite: Exportknopf per Gadget (ruft API, speichert JSON auf Dateiseite).
13) Präsentations-„Sichten“ je Rolle
Nutzen: Dasselbe Zeichen „Dingwort“ in verschiedenen Rollen korrekt darstellen.
Womit & Wie:
- Seiten-Typen:
- Q-Seite (Begriffssicht): Definition, Beziehungen, Kategorie-Einordnung.
- L-Seite (lexische Sicht): Formen, Sinne, Register, Etymologie.
- W-Artikel (Erklärungstext): Freitext, Zitate, Beispiele, Verweise auf Q/L.
- Kategorie: thematische Bündelung, automatisch gesetzt.
Grundregel der Umsetzung (kompakt)
- Wikibase hält Primärdaten (Q/L/P).
- Lua + Vorlagen erzeugen Sichten (Listen, Tabellen, Texte) auf normalen Wiki-Seiten.
- Optional SPARQL liefert dynamische Listen/Portale.
- SMW-Spiegel (nur, was du für bestehende #ask-Reports brauchst) sorgt für dein gewohntes Query-Ökosystem.
Wenn du willst, skizziere ich dir als Nächstes die Minimalschnittstelle in Lua (nur Funktions-Signaturen, keine Implementierungsdetails): getLemma(L), listForms(L, featureFilter), listSenses(L), etymologyPath(L), registersBySense(L). Damit hättest du die Bausteine, aus denen du alle obigen Sichten zusammensetzt.
Wer den dritten Schritt vor dem ersten Schritt tut, kommt gewiß ins straucheln!
Super Idee mir als nächstes eine Minimalschnittstelle in Lua bauen zu wollen, was wohl dem zehnten Schritt vor dem ersten Schritt entsprechen würde.
Die Umstände sind:
1) ich arbeite an den Daten allein, du bist sozusagen externes Forschungsmitglied mit begrenztem Tätigkeitsumfang
2) ich habe über 56000 Wikiseiten, die ich gemäß der Wikibase Struktur eigens umgestalten und erfassen muß
3) die angegebenen 13 Punkte aus "was-womit-wie" können erst angegangen werden, wenn eine gewisse Anzahl an Daten erfasst wurden, wie soll man ohne Daten dies alles erstellen und prüfen?
Der Nutzen für meine Forschungsarbeit liegt in weiter ferne. Deine Hinweise und Erklärungen 1-13 sind hilfreich für mein Verständnis.
Wie soll ich allein dies alles bewältigen, ohne davon überwältigt zu werden? Was der erste Schritt nun ist, weiß ich noch gar nicht.
Verfahren für die ersten 12 Lexeme
| Planung der nächsten Schritte
Für die erste Phase sollten wir uns auf die grundlegenden Entscheidungen konzentrieren: Festlegung des Datenmodells und des minimalen Kerns, sowie eine Pilotgruppe. Wir definieren Konventionen zur Namensgebung, erstellen Checklisten und legen die Arbeitsabläufe fest. Wir bieten auch mögliche Wege: A (mit Lexeme), B (nur Q/P), oder C (Mapping später). Planung der ersten Schritte Der erste Schritt ist, das minimale Datenmodell zu definieren: Eine Liste von Items und Attributen sowie festgelegte Werte. Dann erstellen wir eine kurze kontrollierte Vokabel. Für die ersten Lexeme wählen wir 3 aus, Nachgedacht für 15s Fertig |
|---|
Du hast recht: Erst Zweck & Reihenfolge, dann Werkzeuge. Ziel ist, dass du allein einen tragfähigen, nicht-überwältigenden Pfad hast. Hier ist eine kleinste gangbare Prozess-Skizze – ohne Eingabe-Anweisungen, nur Entscheidungs- und Arbeitsschritte.
Leitplanke (heute festlegen)
Modell-Variante wählen (für jetzt, reversibel):
V-A (pragmatisch): Lexeme mit Sprach-Slot = de (Transport), Sprachstufe als Aussage (Gemeindeutsch etc.).
Vorteil: sofort arbeitsfähig; UI-Hürde umgangen.
Nachteil: Slot spiegelt nicht deine Stufencodes.
Wenn V-A für dich akzeptabel ist, gehen wir weiter. Wenn nein, ist die Konsequenz: erst Systemerweiterung/Alternative prüfen, keine Datenerfassung starten.
„Definition of Done“ pro Lexem (minimal)
Damit du nicht ins Uferlose läufst, gilt ein kleinster Abschlusszustand (prüfbar, wiederholbar):
- Lexemkopf: Lemma, Sprache (Transport), Wortart = Dingwort.
- Formen: min. 1 Grundform (Einzahl), min. 1 Mehrzahl-Form (bei „Wort“: beide Plurale zählen als erfüllt).
- Sinn: 1 Gloss + 1 Verweis auf ein Konzept-Item (dein Begriffs-Q).
- Sprachstufe: 1 Aussage (z. B. Gemeindeutsch), Ebene je nach Geltung (Lexem oder Sinn).
- Etymologie/Diachronie: 1 Kante (z. B. „abgeleitet von …“ oder „gehört zur Wurzel …“). → Fertig heißt: 1–5 gesetzt. Alles Weitere ist „später“.
Pilot-Umfang (klein halten)
- Pilot-Menge: 12 Wörter aus einem Wortfamilien-Kern (z. B. Wort, Dingwort, Wortlaut, Wortschatz, …).
- Zweck: Du testest alle Stellen (Lexem/Form/Sinn/Sprachstufe/Diachronie) im Kleinen, entdeckst Stolperstellen früh, ohne 56 000 Seiten zu berühren.
Rollenklare Datenlisten (einmalig definieren)
Nur das Unumgängliche, deutsch benannt – als kontrolliertes Vokabular:
- Wortarten (Q): Dingwort, Tunwort, Wiewort, … (Aliases kannst du beliebig pflegen).
- Sprachstufen (Q): Gemeindeutsch, Neuhochdeutsch, Mittelhochdeutsch, Althochdeutsch, Indogermanisch …
- Grammatische Merkmale (Q): Einzahl, Mehrzahl, Fälle (deine Benennungen).
- Beziehungs-Properties (P):
- Sprachstufe → Item
- Register → Item (falls getrennt von Stufe)
- Periode → Item/Zeitangabe
- ist Kompositum aus → Item (mehrfach)
- abgeleitet von Lexem → Lexem
- (optional) verweist auf Wurzel → Item
Mehr brauchst du für den Pilot nicht. Alles andere parken.
Arbeitsrhythmus (Überwältigung vermeiden)
- Timebox pro Lexem: 10–15 Min. (Stop-Regel: Wenn Punkt 5 zu viel Zeit frisst, Kante weglassen, trotzdem abschließen.)
- Tagesziel: 3–5 Lexeme (nicht mehr).
- Woche 1 Ziel: 12 Lexeme (eine Familie).
- Abbruchkriterium: Wenn 12× „unangenehm“ war → wir passen das Done-Set an, bevor du skalierst.
Sichtbar machen (ohne Programmierarbeit)
- Prüfliste auf einer Wiki-Seite: eine einfache Tabelle (manuell) mit 12 Zeilen (Wörter) und 5 Spalten (Done-Punkte). Abhaken beim Fertigstellen.
- Wartungskategorie (manuell): Falls bei einem Lexem ein Done-Punkt fehlt, setze am Ende der Lexem-beschreibenden Seite „Kategorie:Lexem unvollständig“. Ziel: Leer nach Pilot.
Was du jetzt noch nicht tust
- Keine Lua, kein SPARQL, keine Massenmigration, keine 56 000-Seiten-Umbauten.
- Keine Feinheiten wie Registernuancen, Betonung, Periodisierung auf Jahreszahl-Niveau.
- Keine ShEx/Schemata. All das erst nach dem Pilot.
Entscheidungshilfe für „Dingwort“ in deinen sieben Rollen
Dein Modell bleibt erhalten, aber Wechselwirkungen minimieren:
- Identische Benennung, verschiedene Entitätstypen ist erlaubt (Q „Dingwort (Begriff)“, P „hat Wortart“, L „Dingwort“, Kategorie „Dingwort“).
- Konfliktvermeidung: Vermeide, dass ein und dasselbe Objekt gleichzeitig Property und Item ist. Statt „Property Dingwort“ besser Property „hat Wortart“ + Item „Dingwort (Wortart)“.
- Komposition: Q „Ding“, Q „Wort“ bleiben Bausteine; Beziehungen über „ist Kompositum aus“.
Warum diese Reihenfolge sinnvoll ist
- Sie respektiert deine Ontologie (Begriffe deutsch, Stufen als Erste-Klasse-Bürger),
- sie umgeht die Slot-Beschränkung ohne sofortige System-Eingriffe,
- sie liefert nach 12 Einträgen echtes Material für eine nüchterne Entscheidung: „Trägt das? Oder nicht?“.
Vorschlag für den allerersten Schritt (heute, klein):
Lege nur die Pilot-Liste (12 Wörter) fest und hake die Vokabular-Liste (Wortarten, Sprachstufen, 3–4 Merkmale, 3–4 Properties) ab. Kein Dateneintrag. Nur diese beiden Listen fixieren.
Wenn du sie notiert hast, prüfe kurz: Ist V-A (Sprachstufe als Aussage, Slot = Transport) für den Pilot tragfähig?
Danach erst beginnst du mit dem ersten Lexem der Liste.
Property anlegen und verknüpfen begreifen ist der nächste Schritt!
Ich habe jetzt aus der Erfahrung mit der Eingabe zu einem Lexem und einem Item erfasst, daß diese nicht unmittelbar sondern wenn über Eigenschaft (property) verlinkt und vernetzt werden – richtig?
Ich habe herausgefunden, daß ich eine neue Eigenschaft anlegen kann und muß dann dieser Eigenschaft einen Datentyp zuweisen. Zur Auswahl habe ich darin auch wieder Datenobjekt (item), Lexem und Eigenschaft. Wie lege ich eine Eigenschaft an, die dann auch eine Eigenschaft als Property ist?
Weitere Frage: Sollte ich für Wikibase-proptery nur Bezeichnungen verwenden die keine Substantive, folglich adjektivisch-adverbial sind?
Beantworte erst, – danach gehen wir ein konkretes Beispiel an.
Wikibase-Eigenschaft (property)
| Antwort zu Wikibase-Eigenschaften
Bei der Wahl von Properties in Wikibase sollte man sich an neutralen, beschreibenden Begriffen orientieren. Nomen oder nominale Phrasen wie "ist ein(e)" oder "hat Qualität" sind üblich. Adjektivische Beschriftungen können verwirren, daher besser verbale oder präpositionale Phrasen nutzen. Ein konkretes Beispiel folgt später. Antwort zu Wikibase-Eigenschaften Entities in Wikibase verlinken über Statements mit Properties; eine direkte Verlinkung gibt es nur über Statements, mit Ausnahme von fixen Slots im Lexem. Ein Property, das auf ein anderes zeigt, nutzt den Datentyp "Wikibase-Property". Die Konventionen für Benennungen bevorzugen Nomen oder nominale Phrasen wie "hat …". Es empfiehlt sich, den Wert nicht im Label zu verschlüsseln. Antwort zu Wikibase-Eigenschaften Ich werde zunächst eine Antwort geben und später ein Beispiel nennen. Als Beispiel könnten wir die 'Sprachstufe'-Property definieren. Ich werde keine zukünftigen Aufgaben versprechen, nur darauf hinweisen, dass wir das Beispiel später ansprechen werden. Am Ende könnte ich sagen: "Sag Bescheid, dann mache ich weiter..." Antwort zu Wikibase-Eigenschaften
Nachgedacht für 21s Fertig |
|---|
Kurz & präzise:
1) Verlinkung: „nicht unmittelbar, sondern über Eigenschaften“ – richtig?
Ja. In Wikibase werden Entitäten (Q/L/…) über Aussagen (Statements) verknüpft. Eine Aussage = Property (Prädikat)+ Wert.
Ausnahmen sind nur die festen Lexeme-Slots (Sprache, Wortart) und Sitelinks; alles andere läuft über Properties.
2) „Eigenschaft anlegen, die als Wert wiederum eine Eigenschaft referenziert?“
Ja – dafür nimmst du als Datentyp: „Wikibase-Property“.
So kann eine Aussage „… → (Wert ist) Property XY“ tragen. Beispiele, wann das sinnvoll ist:
- „hat Gegen-Eigenschaft“ → (Wert = andere Property)
- „ist Untereigenschaft von“ → (Wert = übergeordnete Property)
- „nutzt Qualifier-Eigenschaft“ → (Wert = Qualifier-Property)
3) Datentyp-Wahl (Daumenregeln)
- Wikibase-Item: Wert ist ein Begriff/Eintrag (z. B. Dingwort, Gemeindeutsch, Deutschland).
- Wikibase-Lexeme: Wert ist ein Lexem (z. B. „abgeleitet von Lexem“).
- Wikibase-Property: Wert ist eine Property (Meta-Bezug).
- Zeit / Zahl / String / Monolingualer Text / URL / Externe ID: wenn der Wert kein Entity ist, sondern ein Datum, Maß, Code, Text usw.
4) Benennung von Properties (deutsche Labels)
Du musst keine adjektivischen/adverbialen Formen erzwingen. Bewährt (lesbar & eindeutig) sind im Deutschen:
- Substantivische Kurzformen: „Sprachstufe“, „Register“, „Periode“.
- Präpositional-/Verbphrasen (hat/ist/Teil von): „hat Wortart“, „ist Teil von“, „Kompositum aus“. Wichtig ist Relationsklarheit, nicht die Wortart der Bezeichnung. Gib Aliasse für alternative Fachsprache (z. B. „Wortart“ ↔ „lexikalische Kategorie“).
5) Rollen-Trennung (zur Vermeidung von Vermischung)
- Property = Art der Beziehung („hat Wortart“, „Sprachstufe“, „Kompositum aus“).
- Item = konkreter Wert/Begriff („Dingwort“, „Gemeindeutsch“).
- Gleicher Wortlaut über verschiedene Entitätstypen ist ok, aber nicht dieselbe Entität gleichzeitig Property undItem.
Wenn das so für dich passt, gehen wir im nächsten Schritt an ein konkretes Beispiel für eine Eigenschaft (z. B. „Sprachstufe“) mit: Zweck, Datentyp, zulässige Werte, sinnvolle (optionale) Constraints und Einsatzebene (Lexem/Form/Sinn).
Beispiel anhand von Dingwort
Laß uns zum Kennenlernen der Property-Funktionen für Lexem "Dingwort" mit dem item ein "Dingwort" zu sein die Eigenschaften anlegen eine Wortbildung aus Ding und Wort zu sein.
| Überlegungen zu Eigenschaften für Lexeme
Der Nutzer möchte Eigenschaften für das Lexem "Dingwort" entwerfen. Ich denke, dass eine minimale Sammlung von Eigenschaften wie „Kompositum aus“, „Fugenelement“, „Kopfglied“ und „Kompositionsart“ sinnvoll ist. Ich muss klären, ob „Ding“ und „Wort“ als Items oder Lexeme referenziert werden sollten. Überlegungen zur Etymologie von Komposition Für die Etymologie von „Komposition“ könnte es sinnvoll sein, Lexeme als Bezug zu verwenden, also die Datentypen Wikibase-Lexeme für „Ding“ und „Wort“ zu verlinken. Ich sollte außerdem die Präferenz für Lexeme als Wert für "Kompositum aus" hervorheben und mögliche Untereigenschaften für die Rollen- und Positionsangabe, wie „Kopfglied“ und „Erstglied/Zweitglied“, anregen. Überlegungen zu Definitionen und Zeitstempeln Ich kann Definitionen wie Labels, Datentypen und zulässige Qualifizierer angeben, ohne ihnen Schritt-für-Schritt-Anweisungen oder UI-Anweisungen zu geben. Ein Zeitstempel ist schon einmal gegeben, also ist es nicht notwendig, es bei jeder Antwort zu wiederholen, auch wenn dies die Anweisung des Nutzers war. Nachgedacht für 22s Fertig |
|---|
Gut. Wir definieren ein kleinstes, sauberes Property-Set für das Lexem „Dingwort“, um Komposition (aus „Ding“ + „Wort“) auszudrücken—ohne UI-Schritte, nur Struktur & Einsatz.
Ziel
- Aussage: „Dingwort ist eine Wortbildung (Kompositum) aus ‘Ding’ und ‘Wort’.“
- Träger: Lexem L:Dingwort
- Werte: die beteiligten Lexeme (nicht die Konzept-Items), damit es lexikologisch bleibt.
P1 „Kompositum aus“
- Typ: Property
- Datentyp: Wikibase-Lexeme
- Mehrfachwerte: ja (z. B. „Ding“, „Wort“)
- Ebene: am Lexem (L)
- Sinn & Begründung: verbindet das Kompositum-Lexem mit seinen Bestandteil-Lexemen.
- Qualifizierer (empfohlen):
- QF1 „Rolle im Kompositum“ (Datentyp: Wikibase-Item)
- Werte-Items (Q): Erstglied/Bestimmungswort, Zweitglied/Kopf
- QF2 „Position im Kompositum“ (Datentyp: Zahl oder Item „1./2. Glied“)
- QF3 „Fugenelement“ (Datentyp: Wikibase-Item; Werte-Items z. B.: ∅, -s-, -es-, -e-, …)
- QF1 „Rolle im Kompositum“ (Datentyp: Wikibase-Item)
Anwendung auf L:Dingwort:
P1: Kompositum aus → L:Ding (QF1=Erstglied, QF2=1)
P1: Kompositum aus → L:Wort (QF1=Kopf, QF2=2)
QF3 „Fugenelement“ = ∅ (falls zutreffend)
P2 „Kompositionsart“
- Datentyp: Wikibase-Item
- Ebene: am Lexem
- Werte (Q): Determinativkompositum, Kopulativkompositum, Possessivkompositum …
- Sinn: klassifiziert den Bau-Typ (hier: i. d. R. Determinativkompositum).
Anwendung: Kompositionsart → Q:Determinativkompositum
P3 „ist Bestandteil von“ (optional, inverse Kante)
- Datentyp: Wikibase-Lexeme
- Ebene: am Bestandteil-Lexem (z. B. L:Ding, L:Wort)
- Sinn: inverse Navigierbarkeit („Wort ist Bestandteil von Dingwort“).
- Meta-Relation (optional, auf Property-Ebene):
- Property-Meta: „inverse von“ → verweist auf P1 „Kompositum aus“ (Datentyp der Meta-Aussage: Wikibase-Property).
Anwendung: an L:Wort: ist Bestandteil von → L:Dingwort
P4 „Wortbildungs-Muster“ (optional, generisch)
- Datentyp: Wikibase-Item
- Ebene: am Lexem
- Werte (Q): N+N, Adj+N, N+V, …
- Sinn: abstraktes morphologisches Schema, unabhängig von konkreten Gliedern.
Anwendung: Wortbildungs-Muster → Q:N+N
Bereits vorhanden / nicht duplizieren
- Wortart (lexikalische Kategorie): Slot im Lexem → Wert-Item „Dingwort (Wortart)“. (Keine eigene Property „Dingwort“; Property = Relation, Item = Wert.)
Minimal-Konfiguration (nur das Nötige)
- P1 „Kompositum aus“ (Lexem-Wert) + Qualifizierer QF1/QF2/QF3
- P2 „Kompositionsart“ (Item-Wert) (P3/P4 sind Optionen, je nach Wunsch nach Inversen bzw. Mustern.)
Ergebnis am Beispiel L:Dingwort (inhaltlich)
- Wortart (Slot): Dingwort (Item)
- P1 Kompositum aus: L:Ding 〔Rolle=Erstglied, Position=1〕
- P1 Kompositum aus: L:Wort 〔Rolle=Kopf, Position=2〕
- QF „Fugenelement“: ∅
- P2 Kompositionsart: Determinativkompositum
Hinweise zur Benennung (deutsche Labels)
- Properties: „Kompositum aus“, „Kompositionsart“, „ist Bestandteil von“, „Wortbildungs-Muster“
- Qualifizierer: „Rolle im Kompositum“, „Position im Kompositum“, „Fugenelement“
- Werte-Items: „Erstglied/Bestimmungswort“, „Zweitglied/Kopf“, „∅“, „-s-“, „Determinativkompositum“, „N+N“ …
Fakt vs. Mutmaßung:
- Fakt: Diese Aufteilung wahrt Relationsklarheit (Property = Relation, Item = Wert) und trennt Lexeme (Form/ Sinn-Träger) von Konzept-Items.
- Mutmaßung (plausibel): Für deine Forschung ist Lexem-als-Wert bei „Kompositum aus“ hilfreicher als Item-als-Wert, weil du später Formen/Sinne der Bestandteile direkt referenzieren kannst.
Wenn du damit einverstanden bist, wählen wir als nächstes konkret die Werte-Items für Rollen (Erstglied/Kopf) und für Fugenelemente (∅, -s-, -es- …), damit das Set vollständig anschlussfähig ist.