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?
| Klärung zur Erstellung von Lexemen
Die JSON-Daten waren illustrative. Um ein Lexem zu erstellen, können wir QuickStatements oder die API verwenden. Für den Fall, dass die benötigten Objekte oder Eigenschaften fehlen, könnten wir diese zuerst erstellen. Ich schlage vor, QuickStatements mit Platzhaltern für P/S-Eigenschaften zu verwenden, aber die IDs müssen angepasst werden. Erstellung von Lexemen mit QuickStatements und API Für die Erstellung von Lexemen in Wikidata kann eine QuickStatements-Linie für Lemma-Erstellung verwendet werden, z. B. "L de Noun". Aber ich stelle mir vor, ein sichererer Weg wäre die Nutzung der MediaWiki-API, um das Lexem zu erstellen und dann mit den weiteren Modulen für Formen und Sinne zu bearbeiten. Erstellen von Lexemen mit API Ich erinnere mich an die Module wie wbeditentity, wbladdform und wbladdsense. Um ein Lexem zu erstellen, müssen wir die richtigen Curl-Befehle mit spezifischen Parametern für "lemmas", "language" und "lexicalCategory" definieren. Für Form und Sinne verwenden wir ebenfalls Curl zur genauen Eingabe von Daten, mit Platzhaltern für Token und Endpunkt. Erklärung zur Lexem-Erstellung Ich sollte den Zweck des JSON-Skeletts erläutern und zwei Optionen bieten: A) UI/Wiki-Schnittstelle und B) API via curl (empfohlen). Für die API-Option gebe ich Schritte und Beispielbefehle an, die CSRF-Token und Cookies verwenden. Außerdem erkläre ich, dass vorher bereits erstellte Elemente und Eigenschaften benötigt werden. Nachgedacht für 44s Fertig |
|---|
Danke für die Rückmeldung—verstanden: Du willst kein „Gerüst“, sondern sofort verwendbare Schritte, mit denen du ein Lexem “Wort” tatsächlich anlegst (und danach Form(en), Sinn(e), Statements). Unten bekommst du zwei funktionierende Wege:
Weg A (GUI, am schnellsten)
1) Special:NewLexeme öffnen →
- Lemma: Wort (Sprache: de)
- Sprache (Q…): Deutsch
- Lexikalische Kategorie (Q…): Substantiv → Lexem anlegen → du bekommst z. B. L123.
2) Formen im Lexem-UI hinzufügen:
- F1: Repräsentation: Wort; grammatische Merkmale: Singular, Nominativ (je Q-Items)
- F2: Wörter; Merkmal: Plural
- F3: Worte; Merkmal: Plural
3) Sinn hinzufügen:
- S1 Gloss (de): sprachliches Zeichen, das eine Bedeutung trägt
- Statement am Sinn: item for this sense → dein Konzept-Item „Wort (sprachliches Zeichen)“ (Q…).
Das ist klickbar in 2–3 Minuten. Vorteil: keine API-Details.
Weg B (API/cURL, skriptbar & reproduzierbar)
Voraussetzung: Die Ziel-Items/Properties existieren schon (IDs bitte einsetzen):
Q_LANG_DE (Deutsch), Q_NOUN (Substantiv), Q_SG (Singular), Q_PL (Plural), Q_NOM (Nominativ), Q_CONCEPT_WORD (Konzept „Wort (sprachliches Zeichen)“).
Property für „item for this sense“: P_SENSE_ITEM (z. B. analog Wikidata „item for this sense“).
Optional: P_REGION usw.
- CSRF-Token holen (einmalig je Session)
BASE='https://deine-wiki-domain.org/w/api.php'
# login bereits erfolgt (BotPass/Session-Cookies)
curl -s "$BASE?action=query&meta=tokens&type=csrf&format=json" > token.json
TOKEN=$(jq -r '.query.tokens.csrftoken' token.json)
- Lexem anlegen (Lemma, Sprache, Kategorie)
curl -s -X POST "$BASE" \
-d "action=wbeditentity" \
-d "new=lexeme" \
-d "data={
\"lemmas\":{\"de\":{\"language\":\"de\",\"value\":\"Wort\"}},
\"language\":\"Q_LANG_DE\",
\"lexicalCategory\":\"Q_NOUN\"
}" \
-d "token=$TOKEN" -d "format=json" > create_lexeme.json
LEXEME=$(jq -r '.entity.id' create_lexeme.json) # z.B. L123
echo "Lexeme: $LEXEME"
- Form F1 hinzufügen (Wort, Sg+Nom)
curl -s -X POST "$BASE" \
-d "action=wbladdform" \
-d "id=$LEXEME" \
-d "data={
\"representations\":{\"de\":{\"language\":\"de\",\"value\":\"Wort\"}},
\"grammaticalFeatures\":[\"Q_SG\",\"Q_NOM\"]
}" \
-d "token=$TOKEN" -d "format=json" > add_form1.json
F1=$(jq -r '.form.id' add_form1.json) # z.B. L123-F1
echo "Form1: $F1"
- Form F2/F3 hinzufügen (Wörter, Worte, jeweils Plural)
for F in Wörter Worte; do
curl -s -X POST "$BASE" \
-d "action=wbladdform" \
-d "id=$LEXEME" \
-d "data={
\"representations\":{\"de\":{\"language\":\"de\",\"value\":\"$F\"}},
\"grammaticalFeatures\":[\"Q_PL\"]
}" \
-d "token=$TOKEN" -d "format=json"
done
- Sinn S1 hinzufügen (Gloss)
curl -s -X POST "$BASE" \
-d "action=wbladdsense" \
-d "id=$LEXEME" \
-d "data={
\"glosses\":{\"de\":{\"language\":\"de\",\"value\":\"sprachliches Zeichen, das eine Bedeutung trägt\"}}
}" \
-d "token=$TOKEN" -d "format=json" > add_sense1.json
S1=$(jq -r '.sense.id' add_sense1.json) # z.B. L123-S1
echo "Sense1: $S1"
- Statement am Sinn setzen (item for this sense → Konzept-Item)
curl -s -X POST "$BASE" \
-d "action=wbcreateclaim" \
-d "entity=$S1" \
-d "property=P_SENSE_ITEM" \
-d "snaktype=value" \
-d "value={\"entity-type\":\"item\",\"id\":\"Q_CONCEPT_WORD\"}" \
-d "token=$TOKEN" -d "format=json" > sense_stmt.json
Optionales Beispiel: Statement an der Form (z. B. Region)
curl -s -X POST "$BASE" \
-d "action=wbcreateclaim" \
-d "entity=$F1" \
-d "property=P_REGION" \
-d "snaktype=value" \
-d "value={\"entity-type\":\"item\",\"id\":\"Q_REGION_DE\"}" \
-d "token=$TOKEN" -d "format=json" > form_stmt.json
Ergebnis: Du hast jetzt ein Lexem L… mit F1–F3 und S1, jeweils mindestens einen Eintrag pro Datenmodell-Teil (Lexem-Kopf, Form mit Merkmalen, Sinn mit Gloss, je 1 Statement).
Warum ich dir vorher das JSON zeigte
Das JSON war die exakte interne Datenstruktur, mit der sowohl die API arbeitet als auch (indirekt) die GUI. Für Handarbeit ist die GUI (Weg A) schneller; für reproduzierbare Imports/Serien ist Weg B präzise und skriptbar.
Wenn du magst, mappe mir kurz deine lokalen IDs (Label → Q/P-ID). Dann setze ich dir die obigen cURL-Snippets 1:1 mit deinen IDs zusammen—ohne Platzhalter.