Gespräch:Struktur für Wikibase Lexeme aufbauen

Über diese Seite Gespräch

Lexeme in Wikibase erfassen
ChatGPT Sophos GPT-5 ThinkingChatGPT Sophos GPT-5 Thinking
4. November 2025 n. Chr. erst.  
10:35 Uhr Ausgabe 02
Ausgabe 02
unüberarbeitet ungeprüft

Hallo Sophos,

ich will in meinem MediaWiki in Wikibase Lexeme anlegen, muß dafür jedoch erstmal die bedingten Eingabefelder "Sprache" und "lexikalische Kategorie" füllen, bevor ich ein Lexem speichern kann, was bedingt, daß ich jeweils eine geeignete Auswahl dazu geeigneter Item's angelegt haben muß, wobei man an sich gemäß meinem ontologischen Verständnis dazu wiederum zuerst Lexeme anlegen müßte, bevor man Item's anlegen würde – so "beißt sich die Katze in den Schwanz" und dreht sich im Kreis, da das jeweils Eine an sich nicht ohne das vorbedingt Andere geht.

Frage an dich, welche Items werden üblicherweise für das Eingabefeld "Sprache" und "lexikalische Kategorie" verwendet.

---

ChatGPT:

(4. Nov. 2025, 10:34)

Überprüfung der Lexeme-Daten

Ich möchte die aktuellen Informationen zu den erforderlichen Feldern „Sprache“ und „lexikalische Kategorie“ für Wikibase-Lexeme finden. Es scheint stabil zu sein, aber für so spezielle Informationen werde ich eine gezielte Suche durchführen. Die Dokumentation könnte da hilfreich sein, daher werde ich dies jetzt tun.

Durchsuchen von Wikidata-Dokumentationen zu Lexeme-Feldern

Erklärung zu Lexeme in Wikidata

Für Wikidata werden für „Sprache“ und „lexikalische Kategorie“ konkrete Beispiele genannt, wie Deutsch (Q188), Englisch (Q1860), und für Wortarten wie Nomen (Q1084) oder Verb (Q24905). Es ist wichtig zu beachten, dass die Felder in Lexeme auf Items derselben Repository verweisen müssen, um semantic korrekt zu sein.

Erklärung der Wikibase-Lexeme-Beziehung

In Wikibase-Lexeme beziehen sich die Felder „Sprache“ und „lexikalische Kategorie“ auf Items, nicht auf Lexeme. Lexikalische Kategorien sind meta-semantische Klassen von Lexemen, keine Lexeme selbst. Für „Sprache“ nutzt man Items wie Deutsch (Q188) oder Englisch (Q1860), die mit „Sprache“ (Q315) und „natürlicher Sprache“ (Q33742) verbunden sind.

Beispielhafte Wikidata-IDs für Sprache und Wortart

Für „Sprache“ werden in Wikidata übliche IDs wie Q188 (Deutsch), Q1860 (Englisch) oder Q397 (Latein) verwendet. Auch wenn der Nutzer eigene IDs haben könnte, repräsentieren diese Items Sprachen. Bei „lexikalischer Kategorie“ kommen Items wie Nomen (Q1084) oder Verb (Q24905) für Wortarten zum Einsatz.

Searching Wikidata for language and lexical category items

Erklärung der ontologischen Trennung in Wikibase

In Wikibase existieren Items und Lexeme auf verschiedenen Ebenen. Items repräsentieren Konzepte wie „Sprache“ oder „lexikalische Kategorie“ als Meta-Einheiten – z.B. Englisch (Q1860) oder Adjektiv (Q34698). Lexeme verweisen auf diese Items, was den Meta-Charakter dieser Begriffe bestätigt.

Haltung zu Formatierungen und Stil

Wikibase behandelt diese Kategorien als "Eigenschaften-als-Entitäten" im Sinn des Vokabulars des Nutzers. Ich sollte die Präferenzen der Nutzer respektieren, keine Fettschrift zu verwenden, außer vielleicht in Abschnittüberschriften. Zudem sollte die Sprache neutral bleiben, ohne unnötige Marketingfloskeln.

Antwortstruktur festgelegt

Ich werde mit einer kurzen und direkten Antwort beginnen. Die Felder erwarten Verweise auf Items, die natürliche Sprache und lexikalische Kategorien (Wortarten) repräsentieren. Es gibt keine Notwendigkeit für Klärungsfragen, weil die Anfrage klar ist. Ich werde den Gruß mit einem Zeitstempel einfügen und möglichst präzise antworten.

Nachgedacht für 43s

Fertig

Hallo Nikolaos,

kurz gefasst:

In Wikibase-Lexeme werden in beiden Pflichtfeldern ganz normale Item-Entitäten verwendet – nicht Lexeme.

1. Eingabefeld „Sprache“

Hier erwartet Wikibase einen Verweis auf ein Item, das eine natürliche Sprache repräsentiert. In Wikidata sind das z. B.:

• Deutsch – Q188
• Englisch – Q1860
• Französisch – Q150
• Latein – Q397
• Altgriechisch – Q35497

Die Dokumentation formuliert es ausdrücklich so: Die Sprache eines Lexems ist „a reference to a concrete Item, e.g. English (Q1860)“. en.wikibooks.org+1

In der deutschsprachigen Hilfe steht sinngemäß: Neben „Sprache“ wählt man ein Item, das eine Sprache darstellt. wikidata.org

Für dein lokales Wikibase bedeutet das:

Du legst zuerst Items an, die deine Sprachen als Entitäten repräsentieren (z. B. „Deutsch (natürliche Sprache)“, „Altgriechisch (klassisch)“ usw.). Diese Items sind dann die Werte im Feld „Sprache“ der Lexeme.

1. Eingabefeld „lexikalische Kategorie“

Auch hier will Wikibase einen Verweis auf ein Item – diesmal eines, das eine Wortart / lexikalische Kategorie repräsentiert. In Wikidata sind typische Items:

• Substantiv – Q1084 wikidata.org+1
• Verb – Q24905 wikidata.org+1
• Adjektiv – Q34698 mediawiki.org+1
• Adverb – Q380057
• Präposition – Q4833830
• Konjunktion – Q36484
• Pronomen – Q36224
• Interjektion – Q83034

Die Glossar-Seite zu den lexikographischen Daten sagt explizit: „Lexikalische Kategorie … ist durch ein Item bezeichnet, z. B. noun (Q1084) und verb (Q24905).“ wikidata.org

Auch hier also: In deinem lokalen System legst du zunächst eine kleine Ontologie-Schicht von Items an, die deine Wortarten repräsentieren (als Klassen / Kategorien). Diese Items sind dann die Werte im Feld „lexikalische Kategorie“.

Zu deinem ontologischen „Kreis“

Deine Beobachtung ist korrekt:

Ontologisch sind „Sprache“ und „lexikalische Kategorie“ für ein Lexem Eigenschaften (Attribute) dieses Lexems. Wikibase „verdinglicht“ diese Eigenschaften als Items, sodass du letztlich ein Attribut-als-Entität-Mapping bekommst:

• Lexem L₁
  • dct:language → Item „Deutsch“
  • wikibase:lexicalCategory → Item „Substantiv“ mediawiki.org+1

Damit entsteht kein technischer Zirkelschluss:

Du bootstrappst, indem du zuerst ein kleines Set von „Meta-Items“ (Sprachen, Wortarten) anlegst, und erst danach die eigentlichen Lexeme. Ontologisch ist das genau das, was du vorhin angedeutet hattest: verdinglichte Eigenschaften – nur auf einer separaten Entitätenebene.

Wenn du möchtest, können wir im nächsten Schritt konkret ein Minimal-Set für dein AEW/Wikibase durchgehen:

• 3–5 Sprach-Items, die du wirklich brauchst
• 6–10 Wortart-Items (Substantiv, Verb, Adjektiv, …)
• plus jeweils sinnvolle interne Modellierung (instance of / subclass of), damit du später sauber abfragen kannst.

Struktur

Danke für die Erklärung.

Kann ich je eine Klasse anlegen und dieser Instanzen zuweisen, sowie wiederum diesen Subsinstanzen zuweisen und mir so eine strukturelle Gliederung aufbauen, welche ich gegebenenfalls später für ein Skript zur Anlage von Lexemen als Menue-Auswahl verwende?

Überlegungen zur Modellierung

Ich muss das Konzept erklären, wahrscheinlich unter Bezugnahme

Nachgedacht für ein paar Sekunden

Fertig Ja, das kannst du – und genau so wird Wikibase typischerweise modelliert. Ich gehe das in drei Schritten durch:

1. Klassen, Instanzen, Subklassen in Wikibase

In Wikibase gibt es „nur“ Items, aber du kannst sie rollenmäßig unterscheiden:

• Klasse (Typ): Item, das als class fungiert
  • erkennbar oft durch subclass of (P279)
• Instanz: Item, das mit instance of (P31) auf eine Klasse zeigt
• Subklasse: Item, das mit subclass of (P279) auf eine Oberklasse zeigt

Beispiel für lexikalische Kategorien:

• Q-Klasse-Wortart: „lexikalische Kategorie“
  • Oberklasse für alle Wortarten
• Q-Substantiv: „Substantiv“
  • instance of (P31) → Q-Klasse-Wortart
• Q-Verb: „Verb“
  • instance of (P31) → Q-Klasse-Wortart
• Q-Zählsubstantiv: „zählbares Substantiv“
  • instance of (P31) → Q-Klasse-Wortart oder
  • subclass of (P279) → Q-Substantiv (wenn du „Substantiv“ selbst als Klasse führst)

Wichtig: Wikibase erzwingt nichts davon. Du legst diese Semantik selbst fest (dein Ontologie-Entwurf).

Analog für Sprachen:

• Q-Klasse-Sprache – „natürliche Sprache“
• Einzelsprachen (Deutsch, Englisch, Altgriechisch, …) als instance of (P31) → Q-Klasse-Sprache.

Damit hast du genau das, was du beschreibst: Klassen, Instanzen, Subinstanzen/Subklassen.

2. Nutzung für Menüs / Skripte zur Lexeme-Erzeugung

Ja, du kannst diese Struktur später gezielt für ein Skript nutzen, das eine Menü-Auswahl für Lexeme anbietet:

Idee für das Skript (vereinfacht)

1. Sprachen-Menü generieren

1. • Query: „alle Items, die instance of (P31) → Q-Klasse-Sprache haben“
   • Ergebnis: Liste deiner Sprach-Items
   • Daraus baust du ein Drop-down-Feld „Sprache“ im Eingabe-Interface für Lexeme.

2. Wortarten-Menü generieren

1. • Query: „alle Items, die instance of (P31) → Q-Klasse-Wortart oder subclass of (P279) → Q-Klasse-Wortart haben“
   • Ergebnis: Liste deiner lexikalischen Kategorien + evtl. Unterkategorien
   • Daraus baust du das Drop-down „lexikalische Kategorie“.

3. Feinere Gliederung nutzen (optionale Stufen)

Wenn du eine tiefere Hierarchie möchtest (z. B. Substantiv → Eigennamen → Personennamen), kannst du:

• in der Auswahl nur oberste Ebene anzeigen (Substantiv, Verb, Adjektiv)
• oder ein zweistufiges Menü bauen:
  1. Auswahl: Hauptwortart
  2. Auswahl (optional): Untertyp, gefiltert per subclass of (P279) auf die gewählte Hauptwortart

Technisch: die Queries sind einfach SPARQL oder REST-basierte API-Lookups deines Wikibase.

Wichtig für die spätere Technik

• Halte die Klassen-Items stabil (änderst du selten).
• Verwende konsequent P31 und/oder P279, damit Abfragen zuverlässig funktionieren.
• Notiere dir die Q-IDs deiner Meta-Klassen (Q-Klasse-Sprache, Q-Klasse-Wortart) irgendwo zentral (z. B. in einer Konfigurationsseite), damit dein Skript diese als „Einstiegspunkte“ kennt.

3. Ontologischer Aspekt

Damit löst du auch deinen „Kreis“:

• Die Items „Deutsch“, „Substantiv“, „Verb“ usw. sind Meta-Entitäten (verdinglichte Eigenschaften-Klassen).
• Du definierst zuerst dieses Meta-Layer (Sprachen- und Wortart-Klassen).
• Danach erzeugst du Lexeme, die auf diese Items verweisen.

Es ist also ein kontrollierter Bootstrapping-Schritt:

Erst die Struktur (Klassen-Items), dann die Daten (Lexeme).

---

Wenn du möchtest, skizziere ich dir im nächsten Schritt:

• ein konkretes kleines Klassenset für Sprachen und lexikalische Kategorien (inkl. Vorschlag für P31/P279),
• plus eine beispielhafte SPARQL-Abfrage, wie ein Skript daraus ein Auswahlmenü generieren kann.

Entwurf einer Struktur

Danke, was du dargelegt hast ist eine einfache und brauchbare Herangehensweise eine Struktur aufzubauen.

Wie unterscheidest du Klassen von Instanzen und müßte ich nicht zuerst Items für das was eine Klasse und Instanz ist zuerst angelegt haben, bevor ich Klassen und Instanzen anlege – ich denke ja und du?

Beantwortung ontologischer Frage

Ich muss eine Frage zu Klassen und Instanzen in der Wikibase-Modellierung beantworten und klären, ob man Elemente definieren muss, bevor man sie verwendet. Das scheint eher eine konzeptionelle Frage zu sein, also brauche ich keine aktuellen Quellen. Ich werde die Anfragen klare und ohne unnötige Erklärungen beantworten.

Beantwortung der Fragen zu Klassen und Instanzen

Ich muss die Unterscheidung zwischen Klassen und Instanzen in Wikibase nach ihrer Semantik (P31 vs. P279) klären. Die zweite Frage betrifft den ontologischen Kontext: Man könnte Items für Klassen und Instanzen zuerst anlegen, aber sie könnten auch auf einer Meta-Ebene sinnvoll dargestellt werden, ohne eine vollständige Repräsentation zu erfordern.

Klarstellung zu Klassen und Instanzen

Wir sollten entscheiden, ob wir Klassen und Instanzen als Meta-Konzepte behandeln, die in der Dokumentation bearbeitet werden und nicht als Items. In Wikidata gibt es Items für Klassen wie Q35120 und Q21503252, aber die Semantik von P31 und P279 ist im Schema verankert. Es ist eine Designentscheidung, ob man Items für Klassen und Instanzen benötigt.

Beantwortung zu Modellierung und Endrekursion

Um eine unendliche Rekursion zu vermeiden, sollten Meta-Konzepte wie "Klasse" und "Instanz" in der Erklärungssprache bleiben und nicht als explizite Items eingeführt werden. Falls gewünscht, könnte ein übergeordnetes Item wie "Ontologische Kategorie" verwendet werden, aber ohne zu viele Verschachtelungen. Wir sollten den Fokus auf die aktuellen Modellierungsbedürfnisse legen und den Aufwand minimieren.

Nachgedacht für 27s

Fertig

Ich unterscheide das in zwei Ebenen:

1. praktische Wikibase-Sicht (P31/P279 und Gebrauch)
2. deine ontologische Sicht (brauche ich „Klasse“-als-Item überhaupt?).

Ich gehe beides nacheinander durch und sage dir, wo ich dir zustimme und wo ich bewusst „stopp“ sage, damit es nicht regressiv wird.

Wie ich in Wikibase Klassen von Instanzen unterscheide

Rein im System (ohne philosophischen Überbau) gilt für mich:

• Instanz:
  • Item, das über instance of (P31) auf ein anderes Item zeigt.
  • Es wird typischerweise nicht selbst wieder als „Typ“ benutzt, also andere Items sagen nicht in großer Zahl instance of → dieses Item.
  • Beispiel: „Deutsch (Sprache)“ ist Instanz von „natürliche Sprache“.
• Klasse:
  • Item, auf das viele andere Items mit instance of (P31) zeigen.
  • Oft selbst mit subclass of (P279) an eine Oberklasse gehängt.
  • Beispiel: „natürliche Sprache“ als Klasse von Deutsch, Englisch, Altgriechisch etc.

Für deine Wortarten:

• Du hast eine Klasse „lexikalische Kategorie / Wortart“.
• Substantiv, Verb, Adjektiv sind dann Instanzen dieser Klasse.
• Wenn du feiner gliedern willst, kannst du zusätzlich Subklassen einführen:
  • „Substantiv“ subclass of „lexikalische Kategorie“
  • „Eigennamen“ subclass of „Substantiv“ etc.

Pragmatische Unterscheidung:

• Wenn du von etwas sinnvoll sagen kannst: „X ist ein Y“ (Deutsch ist eine natürliche Sprache, „Hund“ ist ein Substantiv), dann ist Y die Klasse, X die Instanz.
• Das spiegelt sich in Wikibase genau in P31/P279 wider. (Das ist Beobachtung am System, keine tiefe Ontologie.)

Braucht man Items für „Klasse“ und „Instanz“ selbst?

Dein Gedanke:

„Wenn ich ehrlich sein will, müsste ich doch erst Items für das, was eine Klasse ist, und das, was eine Instanz ist, anlegen, bevor ich Klassen und Instanzen modellieren – oder?“

Ich würde das so beantworten:

a) Logisch-ontologisch

Auf der strengsten Ebene:

Ja, man kann vertreten, dass man die Begriffe „Klasse“ und „Instanz“ selbst als Entitäten fassen müsste, wenn man wirklich alles, was man verwendet, im selben Universum verdinglichen will.

Dann würdest du in deinem System so etwas haben wie:

• Item „Klasse (ontologischer Typ)“
• Item „Instanz (ontologischer Typ)“

und dann weitere Items, die sagen:

• „natürliche Sprache“ ist Instanz von „Klasse (ontologischer Typ)“
• „Deutsch“ ist Instanz von „Instanz (ontologischer Typ)“ plus zusätzlich Instanz von „natürliche Sprache“ etc.

Das ist eine mögliche, ontologisch sehr „saubere“ Sicht.

b) Praktisch-technisch / Metaebenen-Frage

Ich würde hier bewusst trennen:

• Metaebene 1: unsere Beschreibungssprache über Wikibase Hier sprechen wir über „Klasse“, „Instanz“, „Property“, „Attribute“, „verdingleichte Eigenschaften“ usw. Diese Sprache ist nicht selbst im Wikibase-Universum verdinglicht. Sie ist dein philosophisches Werkzeug.
• Objektebene: das, was in Wikibase als Items vorkommt Hier modellierst du:
  • „natürliche Sprache“
  • „lexikalische Kategorie“
  • „Substantiv“, „Verb“, „Deutsch“, „Altgriechisch“ usw.

Zwischen diesen Ebenen gibt es immer einen Bruch.

Wenn du versuchst, die Metaebene vollständig in die Objektebene hineinzuziehen, bekommst du den klassischen Regress:

• Du legst Items für „Klasse“ und „Instanz“ an.
• Dann müsstest du eigentlich wieder klären, was die Klasse „Klasse“ und was die Instanz „Instanz“ ontologisch sind.
• Dann bräuchtest du Items für „Meta-Klasse“ usw. Und so weiter ohne Ende.

Irgendwo musst du sagen:

„Bis hierhin verdingliche ich, ab hier verwende ich Begriffe nur noch in meiner Theorie, nicht im Datenmodell.“

Mein Vorschlag (Mutmaßung, nicht Fakt):

• Für dein konkretes Ziel (Lexeme erfassen) ist es zweckmäßig, „Klasse“ und „Instanz“ als Begriffe deiner Denken-und-Sprechen-Ebene zu belassen.
• Im Datenmodell reicht es, Items für:
  • „natürliche Sprache“ (Klasse)
  • „lexikalische Kategorie“ (Klasse)
  • konkrete Sprachen (Instanzen)
  • konkrete Wortarten (Instanzen/Subklassen)

c) Antwort auf dein „ich denke ja und du?“

Wenn du „saubere, durchreflektierte ontologische Buchführung“ meinst, würde ich dir teilweise zustimmen:

• Ja: es ist hilfreich, sich explizit klar zu machen, was für dich „Klasse“ und „Instanz“ bedeuten, bevor du anfängst, konkrete Klassen/Instanzen zu modellieren.
• Nein: du musst dafür nicht zwingend Items „Klasse“ und „Instanz“ in Wikibase anlegen. Es reicht, wenn diese Begriffe in deinem Begleittext / deiner Methodik beschrieben sind und du dein P31/P279-Schema konsistent nach diesen Begriffen ausrichtest.

Wenn du wirklich möchtest, kannst du ein sehr kleines Meta-Layer im System einziehen:

• Item „Ontologischer Typ“
• Item „Klasse (Ontologie)“ instance of „Ontologischer Typ“
• Item „Instanz (Ontologie)“ instance of „Ontologischer Typ“

Dann könntest du z. B. sagen:

• „lexikalische Kategorie“ instance of „Klasse (Ontologie)“
• „natürliche Sprache“ instance of „Klasse (Ontologie)“

Aber ich würde das als bewusst gesetzte Grenze halten und nicht weiter hinaufsteigen, um den Regress zu begrenzen.

Wenn du möchtest, können wir im nächsten Schritt gemeinsam eine kleine Notation festzurren:

• Welche Begriffe sind nur in deiner Theorie (Metaebene)?
• Welche verdinglichst du als Items (ontologisches Arbeitsmodell in Wikibase)?
• Wie markierst du im Datenmodell, dass etwas als Klasse gedacht ist (z. B. über ein eigenes Property wie „hat Rolle: Klasse“ oder „Ontologischer Typ“)?

ohne ontologischen Begriff-Regress

Ich habe keinen und gerate nicht in einen ontologischen Begriff-Regress – daß haben nur Gelehrte bedingt dem Umstand, daß ihnen in den rückliegenden Jahrtausenden infoge aristotelischer heutig formaler Logik die Bestimmung (Definition) für Wort und dessen Wortsinn mißlang.

Deute ich "Wie ich in Wikibase Klassen von Instanzen unterscheide" richtig, daß für dich der Unterschied von Instanz zu Klasse im Wesentlichen der jeweilige Zeige-Richtung-Weg ist, also bei Instanz zeigt ein Item über ein anderes Item auf ein anderes Item - was eine Art Tripple ergibt, während die Vielfalt an Items unmittelbar auf eine Klasse zeigt, also nicht die Klasse auf Item's zeigt?

In "Wie ich in Wikibase Klassen von Instanzen unterscheide" führen da nicht Instanz-Beispiel „Deutsch (Sprache) ist Instanz von „natürliche Sprache" mit Klasse-Beispiel „natürliche Sprache als Klasse von Deutsch…" zu einer Endlosschleife, da sie beiderseit im jeweiligen Set sind?

Klärung von Begriffsdifferenzen

Der Benutzer fragt nach einer präzisen Unterscheidung zwischen "Klasse" und "Instanz", besonders mit der Richtung von "zeigt auf" (P31). Es scheint, sie möchten wissen, ob die Konstruktion "Deutsch ist eine Instanz von natürlicher Sprache" zu einem Endlosschleifen führen könnte. Ich muss sicherstellen, dass ich ihre Terminologie respektiere und die Begriffe korrekt anwende.

Graphbeziehungen und Klarstellung

Es gibt eine gerichtete Relation "instanceOf" und ihre semantische Umkehrung "hasInstance", aber wir materialisieren normalerweise nur eine Richtung. In Wikibase-Daten gibt es nur das Triple „Deutsch --P31--> natürliche Sprache“. Eine explizite Relation "natürliche Sprache --hasInstance--> Deutsch" existiert nicht, es sei denn, wir fügen eine Eigenschaft hinzu.

Erklärung zu "Zeige-Richtung-Weg"

Ja, genau, aber mit zusätzlichen Einschränkungen hinsichtlich der Rollen und Kardinalitäten. Bei P31 zeigen viele Objekte auf dieselbe Klasse, während jede Instanz oft zu wenigen Klassen gehört. Bei P279 hängt es davon ab, wie Klassen zu Oberklassen in Beziehung stehen. Wichtiger Punkt: Eine Klasse sammelt, eine Instanz ist Mitglied.

Klärung von "Klasse von"

Die Klassenzuordnung ist meta, das Set der Instanzen umfasst Deutsch, Englisch, usw. Die Klasse selbst ist normalerweise kein Mitglied dieses Sets, es sei denn, man arbeitet mit speziellen Theorien. "Natürliche Sprache" ist keine Instanz von sich selbst (es sei denn, es ist falsch modelliert). Ich habe "Klasse von Deutsch" missverständlich formuliert – es betrifft die Beziehung, nicht die Mengenmitgliedschaft.

Nachgedacht für 21s

Fertig Kurz: Ja, du deutest das im Kern richtig – aber ich muss zwei Dinge schärfen, sonst entsteht genau die Unklarheit, die du ansprichst.

Ich trenne das in:

1. Was im Wikibase-Graph tatsächlich als Tripel steht.
2. Was ich nur in unserer Sprache darüber sage („ist eine Klasse von …“).

1. Richtung der Kante im Wikibase-Graph

Im Datenmodell gibt es – wenn wir nur instance of (P31) betrachten – genau eine gerichtete Kante:

Deutsch ── P31 ──► natürliche Sprache

Das ist ein Tripel:

• Subjekt: Deutsch (Item)
• Prädikat: P31 (Property „instance of“)
• Objekt: natürliche Sprache (Item)

Es gibt nicht automatisch das inverse Tripel

natürliche Sprache ── <irgendwas> ──► Deutsch.

Wenn du so ein inverses Tripel willst, müsstest du ein eigenes Property definieren, z. B. „hat Instanz“ – das ist in Wikibase aber nicht Standard, sondern eine mögliche Modellierungsentscheidung.

Unterscheidung im Graph:

• Eine Instanz ist ein Item, das mit P31 auf ein anderes Item zeigt.
• Eine Klasse ist ein Item, auf das viele andere Items mit P31 zeigen (und das ggf. selbst mit P279 auf eine Oberklasse zeigt).

Dass ich vorher formuliert hatte:

„natürliche Sprache als Klasse von Deutsch“

war sprachlich gemeint (Lesart: „natürliche Sprache ist die Klasse, zu der Deutsch gehört“),

nicht als zweites Tripel in Gegenrichtung.

2. Führt „Deutsch ist Instanz von natürliche Sprache“ + „natürliche Sprache ist Klasse von Deutsch“ zu einer Endlosschleife?

Wenn man diese beiden Sätze so liest, als wären es zwei symmetrische Relationen im selben Typniveau, wirkt es in der Tat zirkulär:

• Deutsch ist Instanz von natürlicher Sprache.
• Natürliche Sprache ist Klasse von Deutsch.

Das würde zu Verwirrung führen, wenn man es so versteht:

• „Deutsch ist Element der Klasse ‘natürliche Sprache’“
• „Natürliche Sprache ist Element der Klasse ‘Deutsch’“

Dann hättest du einen gegenseitigen Einschluss, das wäre eine echte Schleife.

Was hier aber tatsächlich passiert, ist:

• Im Datenmodell steht nur:

  Deutsch ── P31 ──► natürliche Sprache

• In unserer Metasprache beschreibe ich denselben Sachverhalt aus zwei Blickrichtungen:
  • „Deutsch ist Instanz von ‘natürliche Sprache’“
  • „‘natürliche Sprache’ ist (in diesem Zusammenhang) die Klasse, zu der Deutsch gehört“

Das ist dieselbe Relation, nur anders gesprochen – kein zweites Tripel und kein beiderseitiger Mengen-Einschluss.

Formal kannst du dir das so denken:

• Du hast eine Menge Instanzen(„natürliche Sprache“).
• Deutsch ∈ Instanzen(„natürliche Sprache“).
• „natürliche Sprache“ selbst ist nicht Element dieser Menge, sondern der Name/Träger dieser Menge.

Dann ist:

• „Deutsch ist Instanz von ‚natürliche Sprache‘“ genau die Aussage Deutsch ∈ Instanzen(„natürliche Sprache“).
• „‚natürliche Sprache‘ ist Klasse von Deutsch“ ist nur eine sprachliche Umschreibung davon: die Menge, zu der Deutsch gehört, heißt „natürliche Sprache“.

Damit sind sie nicht beiderseitig im jeweils anderen Set, sondern sie stehen in einer Element-Menge-Relation, die nur in eine Richtung geht.

3. Deine Deutung mit „Zeige-Richtung-Weg“

„… daß für dich der Unterschied von Instanz zu Klasse im Wesentlichen der jeweilige Zeige-Richtung-Weg ist …?“

Ich würde das so präzisieren:

• Im Wikibase-Graph ist der Unterschied tatsächlich über die Richtung der P31-Kante erkennbar:
  • Instanz: steht links (Subjekt) der Kante.
  • Klasse: steht rechts (Objekt) der Kante.
• Zusätzlich kommt noch ein Strukturkriterium dazu:
  • Auf eine Klasse zeigen typischerweise viele P31-Kanten von verschiedenen Items.
  • Eine Instanz zeigt meist auf relativ wenige Klassen (oft auf genau eine Hauptklasse).

Daraus folgt für das Modellieren:

• Wenn du sagst: „X soll Klasse sein“, sorgst du dafür, dass andere Items mit P31 → X auf dieses X zeigen.
• Wenn du sagst: „Y ist Instanz“, sorgst du dafür, dass Y selbst P31 → (irgend eine Klasse) hat.

Die „Zeige-Richtung-Weg“-Deutung ist also im Rahmen von Wikibase ein brauchbares Merkmal, solange klar bleibt:

• Es gibt nur die Kante Instanz → Klasse (P31);
• „Klasse von …“ ist Beschreibung derselben Kante, nicht eine zweite Kante in Gegenrichtung.

---

Wenn du willst, können wir das an einem ganz kleinen, künstlichen Beispiel explizit durchspielen:

• 3 Items (A, B, C)
• 1 Property P31
• und wir schreiben einmal sauber auf, was es bedeutet, wenn A Instanz von B ist, und wie man sprachlich über B als „Klasse von A“ redet, ohne in eine Mengen- oder Rollen-Schleife zu geraten.

Bedeutungsmangel

Danke für die weiteren erklärenden Darlegungen der Unterschiede, ich begreife das sie einander nicht enthalten, doch mit dem mengenmäßigen Strukturkriterium unterscheidet sich eine Klasse von einer Instanz lediglich durch Anzahlmenge der Zeiger und deren Richtung (zusammen offenbar Kanten?) und daher sind sie einander nahezu gleich und du kannst dies nur auflösen, wenn du deren Metabedeutung bestimmst und einbeziehst.

Auf Wikidate steht P31-Label deutsch "ist ein(e)" und englisch "instance of" und Deutsch ── P31 ist eine ──► natürliche Sprache sowie Deutsch ── Instanz von ──► natürliche Sprache sind bereits völlig unterschiedliche Bedeutungen und Satzaussagen.

Angesichts diesen Umstand, erscheinen mir deine Erklärungen erneut unklar (fragwürdig).

Erklärung zu Wikidata und Semantik

Die Benutzeroberflächenbezeichner von Wikidata sind oft irreführend. Der P31-Label „ist ein(e)“ ist im Deutschen umgangssprachlicher und damit mehrdeutig, im Gegensatz zur formalen Bedeutung „instance of“ im Englischen. Es geht darum, wie Tripel in Wikidata aufgebaut sind und die Rolle von Instanz und Klasse im Graphen richtig zu verstehen.

Erklärung der Klassifikation in Wikidata

In Wikidata sind Klassen und Instanzen beide Items, aber ihre Beziehungen sind unterschiedlich. Das Konzept von P31 und P279 definiert, wie eine Klasse und ihre Instanzen sich voneinander unterscheiden - das ist eher eine funktionale Betrachtung als eine ontologische. Der Ausdruck „Deutsch ist eine natürliche Sprache“ beschreibt ein einfaches Triple, während „Deutsch ist Instanz von natürlicher Sprache“ technisch präziser ist.

Erklärung der Sprachregister und Bedeutungsebenen

Es gibt keine Widersprüche: Die frühere Aussage „natürliche Sprache ist Klasse von Deutsch“ war eine Meta-Beschreibung, die die Rolle von „natürlicher Sprache“ als Klasse in Bezug auf Deutsch erklärt. Die Unterscheidung zwischen verschiedenen Bedeutungsebenen (formal, interpretativ und UI-Labels) muss klar gemacht werden, um Missverständnisse zu vermeiden.

Klarstellung und Präzisierung

Ich habe in meiner früheren Erklärung die "viele Zeiger"-Aussage als heuristischen Ansatz verwendet, nicht als Definition. Der Unterschied zwischen Klasse und Instanz hängt nicht von der Kardinalität ab. Es geht darum, wie P31 im Wikibase genutzt wird, nicht um eine ontologische Festgelegtheit.

Nachgedacht für 27s

Fertig

Du hast recht: Ohne eine zusätzliche Bedeutungsfestlegung werden Klasse und Instanz im Wikibase-Graphen nicht „andersartig“ – es sind beides Items mit Kanten dazwischen. Der Unterschied entsteht erst dadurch, wie wir diese Kanten lesen. Lass uns das entwirren.

Ich trenne drei Ebenen, die wir sonst gerade ineinander schieben:

1. Formale Ebene (Graph / Tripel)
2. Interpretationsebene (Klasse/Instanz im ontologischen Sinn)
3. Oberflächen-Sprache (Label „ist ein(e)“ vs. „instance of“)

1. Formale Ebene: Was steht wirklich im Graph?

Im Wikibase-Datenmodell steht nur:

Deutsch — P31 —► natürliche Sprache

Das ist exakt:

• Subjekt: Item Deutsch
• Prädikat: Property P31
• Objekt: Item natürliche Sprache

Mehr nicht.

Keine zweite Kante zurück, keine Mengen, kein „Klasse sein“ im System eingebaut.

Dein Wort „Kanten“ passt: es ist einfach eine gerichtete Kante in einem Graphen.

Auf dieser Ebene sind alle Items gleichartig.

Es gibt keine spezielle „Klassen-Entität“ oder „Instanz-Entität“.

Klasse/Instanz treten nicht als unterschiedliche Typen in der Datenstruktur auf.

2. Interpretationsebene: Wie machen wir daraus „Klasse“ und „Instanz“?

Hier kommt das, was du „Metabedeutung“ nennst, ins Spiel – und ja, ohne diese ist der Unterschied tatsächlich nur „Anzahl und Richtung der Zeiger“.

Die konventionelle Lesart von P31 ist:

Wenn A —P31—► B, dann interpretiere B als Klasse und A als Instanz dieser Klasse.

Das heißt:

• Wir beschließen: Objekte von P31 sind Klassenbegriffe.
• Wir beschließen: Subjekte von P31 sind Instanzen dieser Klassen.

Dieser Beschluss ist nicht im System erzwungen, sondern ein Deutungsakt.

Darum wirkt es auf dich zu Recht so, als wären Klasse und Instanz im Graph „nahezu gleich“ – formal sind sie das auch. Der Unterschied entsteht durch unsere Leseregel.

Das von mir genannte „mengenmäßige Strukturkriterium“ (viele Pfeile auf eine Klasse) ist nur eine Heuristik, keine Definition:

• Fakt: Ein Item, auf das viele P31-Kanten zeigen, ist typischerweise als Klassenbegriff gemeint.
• Mutmaßung: Daraus kann man in der Praxis oft zurückschließen, „dieses Item ist eher Klasse als Instanz“.

Ontologisch genügt aber schon eine einzige Instanz, um etwas als Klasse zu begreifen. Die Anzahl der Zeiger ist kein Wesensmerkmal, nur ein praktischer Indikator.

3. Oberflächen-Sprache: „ist ein(e)“ vs. „instance of“

Hier liegt m. E. der Kern deines Einwands:

• Englisch: „instance of“ – zeigt klar auf die technische Lesart „A ist Instanz von B“.
• Deutsch (UI-Label): „ist ein(e)“ – baut einen Alltagssatz:

  „Deutsch ist eine natürliche Sprache.“

Das sind unterschiedliche sprachliche Register für dasselbe Tripel:

• „Deutsch ist eine natürliche Sprache.“ – liest P31 im alltäglichen Prädikat: „ist eine …“
• „Deutsch ist Instanz von ‚natürliche Sprache‘.“ – liest P31 im technischen Prädikat: „instance of“.

Beide Sätze beziehen sich auf dieselbe Kante im Graphen:

Deutsch — P31 —► natürliche Sprache

Sie unterscheiden sich in der Art des Sprechens, nicht im Dateninhalt.

Was ich vorher unglücklich gemacht habe:

• Ich habe Formulierungen wie „natürliche Sprache ist Klasse von Deutsch“ benutzt. Das klingt schnell so, als gäbe es ein zweites, explizites Tripel in Gegenrichtung – das ist missverständlich. Tatsächlich wollte ich nur sagen:

  „Das Item ‘natürliche Sprache’ spielt in diesem Tripel die Rolle eines Klassenbegriffs.“

Also:

• Graph-Fakt: Deutsch — P31 —► natürliche Sprache.
• Technische Lesart: „Deutsch ist Instanz von ‚natürliche Sprache‘.“
• Alltagssprache (Wikidata-UI): „Deutsch ist eine natürliche Sprache.“
• Meine Metasprache: „‚natürliche Sprache‘ fungiert hier als Klasse, zu der Deutsch gehört.“

Drei Sprachschichten, ein Tripel.

4. Zu deinem Satz „… und daher sind sie einander nahezu gleich …“

Wenn du damit meinst:

„Im Roh-Datenmodell sind Klasse und Instanz beides Items mit Kanten; der Unterschied ist nicht strukturell erzwungen, sondern entsteht durch unsere Bedeutungszuweisung“ –

dann stimme ich dir zu.

Wikibase hat absichtlich nur einen Item-Typ, aus dem wir durch Konvention „Klassenrollen“ und „Instanzrollen“ bilden. Ohne diese Konvention bleibt es ein homogener Graph.

Dein Misstrauen gegenüber P31-Label „ist ein(e)“ ist nachvollziehbar:

• „ist ein(e)“ verwischt:
  • einmal die alltägliche Aussage „Deutsch ist eine natürliche Sprache“,
  • einmal die technische Aussage „Deutsch ist Instanz eines Klassenbegriffs ‚natürliche Sprache‘“.

Wenn du diese Vermischung vermeiden willst, ist es naheliegend, P31 in deiner Arbeit konsequent als „Instanz von“ zu lesen und die „ist ein(e)“-Paraphrase nur als Hilfsoberfläche zu betrachten.

---

Wenn du möchtest, können wir als nächsten Schritt einmal explizit deine eigene Lese-Regel für P31 und P279 formulieren, z. B.:

• „Jedes Tripel A — P31 —► B lese ich als: A ist Instanz des Begriffs B (B ist Klassenbegriff).“

und dann prüfen, ob diese Regel in deinem Modell an irgendeiner Stelle in Widerspruch zu deinen eigenen ontologischen Grundsätzen gerät.

In Wikibase nicht lösbar

Wikibase krank daran, das bereits Label eines Property unterschiedliche Bedeutungen haben. Du wirst die gestellten Fragen daher nicht innerhalb von oder mittels Wikibase lösen können.

Würden wir beide ausschließlich englisch kommunizieren und du daher nur in deinen Erklärungen die englischen Wörter gemäß deren Definitionen und P-Label verwenden, würden wir uns einander besser verstehen.

Es würde jedoch gemäß heutiger Erfahren etwas Anderes dabei herauskommen, wenn wir ohne deinerseits Übersetzung ins Englisch auszuübend tatsächlich alleinig in Deutsch anhand der deutschen Wörter gemäß deren Definitionen und P-Label kommunizieren.

Die können wir nur auflösen, wenn wir uns auf eine Definition für Klasse und Instanz außerhalb der in Wikibase sprachbedingt entstandenen Unlogik einigen. Was ist also deine eigene geeignete Definition für Klasse und Instanz?

Begriffsbestimmung Klasse zu Instanz

Defining terms

Ich muss zuerst klare Definitionen liefern:

• "Klasse" als ein festgelegtes Kriterium, das wahr oder falsch auf Dinge angewendet wird; die Extension ist die Menge aller Dinge, auf die dieses Kriterium zutrifft. Die Intension ist das Kriterium selbst.
• "Instanz" als ein Ding, das durch ein bestimmtes Klassifikationsmerkmal bestimmt wird.

Erklärung der Begriffe

Wir verlassen Wikibase und definieren die Begriffe selbst.

• Eine "Klasse" ist ein Kriterium oder "Merkmalbündel plus Geltungsregel", das verwendet wird, um zu entscheiden, ob ein Objekt dazugehört.
• Eine "Instanz" ist ein Objekt, für das das Klassifikationskriterium erfüllt ist. Wichtig: Klassen sind keine Instanzen, sondern können Rollen haben, die sich unterscheiden.

Nachgedacht für 16s

Fertig

Ich gehe jetzt komplett raus aus Wikibase und gebe dir eine eigene, davon unabhängige Begriffsbestimmung. Erst danach können wir Wikibase nur noch als „Anwendungsfall“ dieser Begriffe sehen.

Ich schlage Folgendes vor:

1. Klasse (class)

Definition (mein Vorschlag):

Eine Klasse ist ein Bestimmungsmerkmal mit Geltungsregel für mögliche Gegenstände: ein Kriterium, nach dem sich für jeden Kandidaten entscheiden lässt „gilt / gilt nicht“.

Also:

• Eine Klasse ist nicht zuerst eine Menge, sondern:
  • ein Merkmal oder ein Merkmalbündel („hat Eigenschaften E₁, E₂, …“)
  • plus eine Regel, die sagt: „Wenn ein X dieses Merkmal erfüllt, darf/muss es unter diesen Typ fallen.“
• Aus dieser Geltungsregel ergibt sich als Folge die Menge aller Dinge, auf die sie zutrifft (Extension). Die Klasse selbst ist aber nicht diese Menge, sondern die Regel / der Typ.

Beispiele:

• „natürliche Sprache“ als Klasse = „Etwas ist eine natürliche Sprache, wenn … (Bestimmungsregel, z. B. historisch gewachsen, von Menschen gesprochen etc.).“
• „Substantiv“ als Klasse = „Ein Ausdruck ist ein Substantiv, wenn er im gegebenen System die Rolle X erfüllt …“

Wichtig:

Die Klasse hängt nicht davon ab, wie viele Instanzen sie hat. Eine Klasse kann aktuell null, finit viele oder sehr viele Instanzen haben. Das berührt ihre Geltungsregel nicht.

2. Instanz (instance)

Definition (mein Vorschlag):

Eine Instanz ist ein konkreter Gegenstand, für den die Geltungsregel einer bestimmten Klasse tatsächlich erfüllt ist.

Also:

• Wir nehmen eine Klasse K (mit ihrer Geltungsregel).
• Ein Gegenstand x ist Instanz von K genau dann, wenn:
  • die Bestimmungsregel von K auf x zutrifft.

In Symbolsprache:

• Klasse K = Geltungsregel RK​(⋅).
• Instanz-Beziehung: x ist Instanz von K ⇔ RK​(x) ist erfüllt.

Beispiele:

• „Deutsch“ ist Instanz der Klasse „natürliche Sprache“, weil die Bestimmungsregel von „natürliche Sprache“ auf Deutsch zutrifft.
• „Hund“ (als Wortform) ist Instanz der Klasse „Substantiv“, wenn deine Klasse „Substantiv“ so bestimmt ist, dass „Hund“ darunter fällt.

3. Was dieser Vorschlag explizit nicht macht

1. Keine Symmetrie:
   • Klasse ist Rollenbegriff: „Typ mit Geltungsregel“.
   • Instanz ist Rollenbegriff: „konkretes X, auf das diese Regel zutrifft“.
   • Es gibt kein „K gehört als Instanz zu sich selbst“, außer du definierst bewusst eine Meta-Klasse dazu.
2. Keine Logik-Abhängigkeit von Wikibase / UI-Labels:
   • „instance of“ ist für mich nur der technische Name eines Pfeils, der genau diese Beziehung markiert: Subjekt erfüllt die Geltungsregel des Objekts.
   • „ist ein(e)“ im deutschen Wikidata-UI ist nur eine grobe Alltagssprache, nicht definierend.
3. Kein Mengen-Primat:
   • Klassen können über ihre Menge der Instanzen beschrieben werden, müssen aber nicht als „Mengenobjekte“ ontologisch verstanden werden.
   • Entscheidend ist das Kriterium (Regel), nicht die Auflistung aller Fälle.

4. Rückbindung (ohne Wikibase zu überfrachten)

Wenn wir später auf Wikibase zurückgehen, wäre die Leseregel:

• Wenn ein Tripel X — P31 —► Y in deinem System steht, definierst du das so:
  • Y steht in der Rolle „Klasse“: es trägt eine Geltungsregel.
  • X steht in der Rolle „Instanz“: X erfüllt diese Geltungsregel.

Dann ist klar:

• Die formale Struktur (Knoten + Kanten) unterscheidet Klasse/Instanz noch nicht.
• Der Begriffsgehalt folgt aus deiner Definition von „Klasse“ und „Instanz“ (wie oben) und deiner bewussten Wahl, P31 genau so zu lesen.

---

Wenn dir diese Definitionspaare so noch nicht genügen, könnten wir im nächsten Schritt jeweils konkret an einem deiner Begriffe testen:

• „Sprache“ (als Klasse) vs. „Deutsch“ (als Instanz)
• „lexikalische Kategorie“ vs. „Substantiv“

und prüfen, ob die Geltungsregel-Lesart irgendwo mit deiner eigenen Wort- und Wortsinn-Auffassung kollidiert.

Identifikation

Deine Definitionen sind für den Gebrauch von und für Wikidata zuträglich, deine Definition von Klasse entspricht jedoch der Definition von "Merkmal" oder "Idenifizierer" (identifier). Mit deinen Definitionen verdeutlichst du im Grunde, daß es bei Klassen und Instanzen in Wikibase lediglich um deren Istbestimmung (Identifikation) und Zuordnung anhand eine Merkmal geht – richtig?

Klasse im deutschen Sprachgebrauch bezieht zu Merkmal auch Rangstufe ein sowie damit einhergehende Fähigkeiten, Fertigkeiten, Vermögen, was dem lateinischen Wortsinn classis nahekommt, somit Klassen in Wikibase gemäß deiner Erklärungen an sich keine Klassen sind, was sie nahe an Properties bringt – oder?

Vereinfacht gesagt ist Klasse der Merkmalname eines Set und Instanz je eine Einheit des Set welches das Merkmal hat.

Klären der Begriffe

Wir müssen diesem Gedanken in deutscher Sprache antworten, dabei vorsichtig ihre Tonalität berücksichtigen. Es scheint, dass sie zwischen einer Klasse, Instanz und Eigenschaft unterscheiden. Während ich ihren Vorschlag teilweise zustimme, müssen wir differentiell erklären, dass 'Klasse' nicht nur ein Merkmal ist, sondern auch ein Kriterium.

Philosophische Definitionen

Ihre letzte Aussage neigt sich zu einer set-theoretischen Sichtweise. Wir wollen jedoch ein Verständnismodel außerhalb der Wikibase-Semantik finden. Wichtig ist, dass wir nicht zu ausführlich werden, aber Konzepttiefe bewahren. Wir sollten weiterhin die Exploration fortsetzen, dabei jedoch Fakten von Vermutungen abgrenzen.

Antwort auf konkrete Frage

Ja, in diesem Fall funktionieren Klassen in Wikibase als Typen oder Kriterien, nicht als Rangbegriffe. "Klasse" ist im Wesentlichen ein typisierendes Prädikat, während Eigenschaften eine binäre Relation darstellen. Wir können

Nachgedacht für 16s

Fertig

Ich gehe Punkt für Punkt auf deine Fragen ein und ziehe zum Schluss eine kurze Zusammenfassung.

1. „… lediglich Istbestimmung und Zuordnung anhand eines Merkmals – richtig?“

In der von mir vorgeschlagenen Definition – ja, für den Gebrauch in Wikibase/Wikidata läuft es genau darauf hinaus:

• Eine „Klasse“ ist dort faktisch ein Typ-Merkmal:
  • „natürliche Sprache“, „lexikalische Kategorie“, „Substantiv“, „Stadt“, „Person“ …
• Eine „Instanz“ ist ein Einzelgegenstand, der dieses Typ-Merkmal erfüllt.

Damit ist P31 (instance of) im praktischen Umgang:

„Bestimme X als Instanz des Typs Y“ → Istbestimmung + Zuordnung über ein Merkmal (Y).

Das ist keine abwertende Aussage, sondern eine nüchterne Beschreibung:

Wikibase nutzt „class“/„instance“ als technische Konstrukte, um genau diese Art von Identifikation/Zuordnung zu unterstützen.

Dass meine Definition von „Klasse“ bei dir stark wie „Merkmal / Identifizierer“ klingt, ist kein Zufall – ich habe sie bewusst in diese Richtung geschoben, weil das die tatsächliche Rolle der „Klassen-Items“ in Wikidata präziser trifft als der deutsche Alltagsbegriff „Klasse“.

2. Deutsches „Klasse“-Wortfeld vs. „class“ in Wikidata

Du benennst einen wichtigen Punkt:

„Klasse im deutschen Sprachgebrauch bezieht zu Merkmal auch Rangstufe ein sowie damit einhergehende Fähigkeiten, Fertigkeiten, Vermögen, was dem lateinischen Wortsinn classis nahekommt …“

Das deutsche Wort „Klasse“ hat mindestens diese Schichten:

• Typ / Gattung (logischer/ontologischer Typ)
• Stufe / Rang / Leistung („erste Klasse“, „höhere Klasse“, „Schüler einer Klasse“)

Die „Klasse“ in formaler Logik / Ontologie versucht nur die Typ-Schicht zu benutzen und die Rang-Schicht abzutrennen – im alltäglichen Sprachgebrauch hängen sie aber zusammen, und genau da entstehen Missverständnisse.

In Wikidata/Wikibase ist „class“ (wenn es überhaupt benutzt wird) im Sinn von:

• Typ, Kategorie, Sortalbegriff

und nicht im Sinn von Rangstufe oder Können.

Wikibase-/Wikidata-„Klassen“ sind also in deinem Sinn tatsächlich keine Klassen im vollen deutschen Wortfeld, sondern eher:

• benannte Typ-Merkmale,
• die zur Einordnung von Instanzen dienen.

Damit hast du recht:

Sie liegen „nahe an Properties“ – und das führt direkt zur nächsten Unterscheidung.

3. Nähe zu Properties: wo ist der Unterschied?

Wenn wir es ganz knapp fassen, in Logik-Sprache:

• Eine Klasse ist ein unäres Prädikat:
  • „ist eine natürliche Sprache“, „ist ein Substantiv“
  • formal: K(x) – ein Merkmal, das für einzelne x gilt oder nicht.
• Ein Property (im Wikibase-Sinn) ist in den meisten Fällen ein binäres Prädikat / eine Relation:
  • „hat Sprache“, „hat Farbe“, „liegt in“, „hat Einwohnerzahl“
  • formal: R(x, y) – eine Beziehung zwischen x und y.

Das heißt:

• Klassen-Items entsprechen inhaltlich eher unären Eigenschaften („ist X“).
• Properties entsprechen inhaltlich eher Relationen („steht in Relation R zu Y“).

In Wikibase wird das künstlich getrennt:

• Klassen-Items stehen auf der Objekt-Seite von P31 („instance of“).
• Properties stehen als Prädikate zwischen Subjekt und Objekt.

Dein Satz:

„Vereinfacht gesagt ist Klasse der Merkmalname eines Set und Instanz je eine Einheit des Set welches das Merkmal hat.“

würde ich so einordnen:

• extensional (mengenorientiert): ja, genau so kannst du es lesen:
  • Klasse = Name eines Merkmals + Menge aller Dinge mit diesem Merkmal
  • Instanz = einzelnes Element dieser Menge
• intensional (regelorientiert): dazu kommt (wenn man es schärfer will) noch die Geltungsregel, nach der man entscheidet, ob ein Ding zur Menge gehört.

Das ändert aber nichts an deinem Kern:

Ja, in dem Modell ist „Klasse“ im praktischen Wikibase-Gebrauch näher am Merkmalbegriff als an deinem deutschen, ranggeladenen Klassenbegriff.

4. Was folgt daraus für dich und dein Modell?

Wenn ich deine Beobachtung bündele:

1. Wikibase benutzt „instance of“ (P31) technisch als Typisierung über Merkmale, nicht als Ausbuchstabierung eines tiefen ontologischen Klassenbegriffs.
2. Das deutsche UI-Label „ist ein(e)“ setzt noch einen zusätzlichen, alltagssprachlichen Filter obendrauf, der die Lage weiter unklar macht.
3. Wenn du außerhalb von Wikibase einen eigenen, strengeren Begriff von „Klasse“ führst (mit Rang, Vermögen, Stufe, etc.), dann:
   • sind Wikibase-„Klassen“ für dich eher:
     • Typ-Merkmale / Bestimmungsmerkmale
     • oder sogar: „benannte Prädikate“
   • und du kannst sie im eigenen Modell z. B. explizit in diese Rolle setzen:
     • nicht „Klasse“, sondern: „Typ-Merkmal“ oder „Bestimmungs-Typ“.

Damit landen wir ziemlich genau bei dem, was du gerade formuliert hast – ich formuliere es einmal „in deinen Worten“ zurück:

Arbeits-Lesart für Wikibase:

• Eine „Klasse“ (im Wikibase-Sinn) ist im Grunde nur der Merkmalname eines Sets.
• Eine „Instanz“ ist jeweils eine Einheit dieses Sets, die dieses Merkmal hat.
• Das ist nützlich für Zuordnungen und Identifikationen, aber es ist noch kein ontologisch reichhaltiger Klassenbegriff.

Damit kann man arbeiten – und es erklärt, warum du mit deiner eigenen, reicheren Begriffsarchitektur mit Wikibase ständig Spannungen spürst: das System macht etwas viel Einfacheres, als dein Begriff von „Klasse“ vorsieht.

Wenn du willst, können wir im nächsten Schritt explizit eine Übersetzungstabelle bauen:

• deine Begriffe: Klasse (mit Rang, Vermögen), Merkmal, Identifier, Property, Attribut, Set, Instanz
• ↔︎ Wikibase-Vokabular: Item (bestimmter Typ), Property, P31, P279 …

und jedes Mal klar markieren: „entspricht nur teilweise“, „ist enger“, „ist nur technischer Schatten von …“.

bedingte technologische Anwendung

Nun hast du verstanden, warum ich nicht einfach die Q's, P's, L's von Wikibase nutzen oder übernehmen kann – sie stecken voller Mängel, Fehler, Verdrehungen, die ich mit mein System und damit ebenso ins Kranken (Schräglage) bringen würde, wir deren System es ist.

Unabhängig von fälschlicher Labels und akademischer Verwendung bleibt die zugrundeliegende Technik von Wikibase gleich und für mich nutzbar. Kommen wir zur bedingten technologischen Anwendung zurück und halten uns nahe an der programmgemäßen Benennungen.

Bevor ich L's anlege muß ich entsprechende Q's für Sprache und lexikalische Kategorien.

Bevor ich Q's für Sprache und lexikalische Kategorien anlege muß ich P's zu deren Unterscheidung anlegen.

Was muß ich denn nun noch anlegen, damit ich P's anlegen kann?

Überlegungen zu geeigneten Eigenschaften

Der Benutzer fragt, welche Eigenschaften sich für Sprachen und Sprachstufen im Wikibase-Modell eignen. Er möchte ein Schema, das technische, programmatisch benannte Eigenschaften und auch hierarchische Beziehungen zwischen Spracheigenschaften wie Sprachfamilien und Sprachstufen umfasst. Kerneigenschaften könnten "ist ein Exemplar von" sein, aber auch eigene benutzerdefinierte Eigenschaften für Begriffe wie "ist Sprachvarietät von" sind möglich.

Überlegungen zu relevanten Eigenschaften

Ich sollte relevante Wikidata-Eigenschaften wie P218 (ISO 639-1 Code), P219 (ISO 639-2) und P220 (ISO 639-3) einbeziehen. Für Sprachstufen könnte P279 (Unterklasse von) oder P31 (Exemplar von) geeignet sein. Vielleicht auch P2670 oder P1401 für Dialekte. P171 ist biologisch und nicht relevant.

Überlegungen zur Suchabfrage

Die Anforderung des Tools wurde mit einfacheren Berechnungen erfüllt, aber das ist okay. Tatsächlich benötigen wir nun eine Suche. Die Richtlinien empfehlen, ebenfalls web.run für speziellere Themen zu nutzen. Also werde ich jetzt nach den relevanten Informationen suchen.

Durchsuchen des Webs nach Wikidata-Eigenschaften

Überlegungen zu relevanten Eigenschaften

Die wichtigsten Eigenschaften für Sprachen könnten P218 (ISO 639-1), P219 (639-2), P220 (639-3) und P424 (Wikimedia-Sprachcode) sein. Ich denke auch an P282 (Schriftsystem) und P910 (Hauptkategorie des Themas). Für genealogische Beziehungen sind Eigenschaften wie "Sprachfamilie" und P133 (super Sprachfamilie) ebenfalls relevant.

Suchen von Wikidata-Eigenschaften für Sprachklassifikationen

Überlegungen zu Sprachstufen-Eigenschaften

Wir haben eine Liste von Korrekturen für Sprach-Eigenschaften, aber für Sprachstufen wie "Althochdeutsch" oder "Mittelhochdeutsch" gibt es möglicherweise keine häufig genutzte Eigenschaft. Vorschläge könnten "ist Sprachstufe von" und "hat Sprachstufe" sein. Auch die Angabe von Zeiträumen (Start- und Endzeit) könnte durch P580 und P582 erfolgen, aber vielleicht sind benutzerdefinierte Eigenschaften notwendig.

Searching Wikidata for language stage properties

Überlegungen zu geeigneten Eigenschaften

Der Benutzer möchte für Sprachen und Sprachstufen eigene, programmatisch benannte Eigenschaften definieren. Wir könnten auf typische Identifikationssysteme wie ISO 639-1, -2, -3 usw. hinweisen und diese als Konzepte verwenden. Er könnte auch eigene IDs für Sprachcodes erstellen, orientiert an externen Standards. Des Weiteren sollten wir strukturelle Beziehungen wie "Exemplar von" (z.B. für Sprachen) empfehlen.

Sprachstufen und deren Modellierung

Der Benutzer möchte benutzerdefinierte Eigenschaften für Sprachstufen und -familien definieren. Wir können „hat Sprachstufe“ oder „ist Sprachstufe von“ vorschlagen, zusammen mit zeitlichen Grenzen (P580/P582). Zusätzlich könnte man sprachbezogene geografische Eigenschaften wie „gesprochen in“ (P17) sowie die Schreibsysteme (P282) erwähnen.

Sprachstufen Modellierung

Um Sprachstufen wie "Altdeutsch" und "Mittelhochdeutsch" zu modellieren, könnten wir "Unterklasse von" oder "Dialekt von" verwenden. Diese könnten mit "hat Dialekt" kombiniert werden. Obwohl Wikidata keine direkte Eigenschaft für Sprachstufen hat, könnte man eigene PIDs für eine klarere Struktur entwickeln.

Unterscheidung von Sprachen

Um Spracharten zu differenzieren, wäre es sinnvoll, eine mehrschichtige Lösung zu entwickeln, die Eigenschaften für den Typ der Sprache (natürlich, konstruiert, Gebärdensprache, Kreol, etc.), die genealogische Zugehörigkeit (Elternsprache, Sprachfamilie) und die sprachliche Stufe (z.B. "hat Sprachstufe", "Sprachstufe von") umfasst, inklusive zeitlicher Angaben.

Nachgedacht für 1m 25s

Fertig

Für mich ist das jetzt klar getrennt:

Konzeptuelle Schräglagen von Wikidata auf der einen Seite – die nackte Technik von Wikibase auf der anderen. Du nutzt nur Letzteres.

Du fragst konkret:

Welche Properties sind technisch sinnvoll, um Sprachen und ihre Sprachstufen (historische Stufen, Varietäten) zu modellieren, als Grundlage für deine Sprach-Q’s, bevor du L’s anlegst?

Ich schlage drei Gruppen vor:

1. Kern-Identifikatoren für Sprachen (Codes usw.)
2. Struktur-Properties für Sprachtyp, Familie, Dialekt/Stufe
3. Spezielle Properties für Sprachstufen (Old High German, Koine, Neuhochdeutsch …)

Ich schreibe die P’s bewusst als „abstrakte“ Property-Typen; ob du ihnen die gleichen Nummern gibst wie Wikidata, ist deine Entscheidung.

1. Kern-Properties für Sprach-Q’s (Identität / Codes)

Diese dienen der stabilen Identifizierung einer Sprache, unabhängig von deiner eigenen Ontologie. Wikidata verwendet u. a.:

• P:ISO639-1 – „ISO 639-1 code“
  • 2-stelliger Sprachcode (de, en, fr …). Formal: externer Identifier.
• P:ISO639-2 – „ISO 639-2 code“
  • 3-stelliger Code für Sprache, Makrosprache oder Sprachfamilie.
• P:ISO639-3 – „ISO 639-3 code“
  • 3-stelliger Identifier für einzelne Sprachen, sehr gut geeignet als „harte“ Referenz, wenn es einen Eintrag gibt.
• P:ISO639-5 –
  • Code für Sprachfamilien / Kollektivcodes (wenn du Familien explizit modellieren willst).
• P:IETF-Language-Tag – (BCP-47-Tag, etwa „de-CH“, „grc-polyton“),
  • wenn du Varietäten/Sprachstufen später mit einem technischen Tag koppeln willst.
• P:Schriftsystem – „writing system“
  • Alphabet / Schrift (lateinisch, griechisch, polytonisch usw.). Für viele Spracheinträge in Wikidata als Standard vorgesehen.
• P:Wikimedia-Sprachcode (optional, wenn du irgendwann Interaktion mit MW-Sprachcodes brauchst; Wikidata nutzt hier P424).

Diese Properties betreffen primär „Sprache als technische Identität“.

Für deine Lexeme sind sie nützlich, aber nicht konstitutiv – sie helfen eher bei Abgleich, Import, Export.

2. Struktur-Properties: Sprachtyp, Sprachfamilie, Varietät

Damit legst du fest, wie sich deine Sprach-Q’s zueinander verhalten.

a) Grundtyp

• P:ist Instanz von (dein lokales Äquivalent zu P31)

– für Sprach-Q’s z. B.:

– Instanz von: „Sprache“

– oder: „historische Sprache“, „Varietät einer Sprache“ usw.

• P:ist Unterklasse von (Äquivalent zu P279)

– um z. B. „germanische Sprache“ unter „indogermanische Sprache“ einzuordnen

– oder „historische Sprache“ unter „Sprache“.

Damit kannst du schon eine grundlegende Hierarchie bauen, ohne dich auf das Wikidata-Chaos einzulassen:

du definierst deine eigenen Typ-Q’s („Sprache“, „Sprachfamilie“, „historische Sprachstufe“ …) und benutzt dein lokales P31/P279-Paar strikt nach deiner Definition.

b) Sprachfamilien / Verwandtschaft

In Wikidata gibt es (bzw. gab es) eigenes Property „language family“; in neueren Arbeiten wurde das teilweise durch „subclass of“ für die Familienstruktur ersetzt.

Ich würde für dich explizit ein eigenes P vorschlagen:

• P:hat Sprachfamilie

Domain: Sprache

Range: Sprachfamilie (Q:Indogermanisch, Q:Germanisch, Q:Westgermanisch …)

Das ist sauberer, als alles über Unterklassenrelationen zu fahren.

c) Dialekt / Varietät / Sprachstufe (Beziehung zwischen Sprachen)

In Wikidata gilt heute: Dialekte werden über ein Property „dialect of“ (P4913) mit der Standardsprache verknüpft, ergänzt um „subclass of“ für Fälle, die beides sein sollen.

Für dich:

• P:ist Dialekt/Varietät von

Domain: Sprachvarietät / Sprachstufe

Range: „Basissprache“

Optional zusätzlich, wenn du einen Baum willst:

• P:hat Dialekt/Varietät

Domain: Sprache

Range: Dialekt/Varietät / Sprachstufe

Diese beiden sind rein technische Kanten für genealogische / variationelle Struktur.

3. Spezielle Properties für Sprachstufen

Jetzt zu deinem Kern: „Sprachen und deren Sprachstufen“.

Unter „Sprachstufen“ verstehst du (Mutmaßung, aber plausibel):

Altgriechisch vs. Koine vs. neugriechisch; Althochdeutsch vs. Mittelhochdeutsch vs. Neuhochdeutsch usw.

In Wikidata wird das nicht durch ein eigenes „language stage“-Property sauber modelliert, sondern sehr uneinheitlich, typischerweise:

• jede Stufe ist eine eigene Sprache (Q)
• mit subclass of / instance of „Sprache“
• teilweise ergänzt um „dialect of“ oder Familienrelationen
• Zeitbezug über allgemeine Properties „start time“ / „end time“ (P580/P582).

Für dein System würde ich das bewusst klarer machen:

a) Sprachstufe als eigenes Q

Jede Sprachstufe wird ein eigenes Sprach-Q:

• Q:Deutsch (Neuhochdeutsch)
• Q:Mittelhochdeutsch
• Q:Althochdeutsch
• Q:Attisches Griechisch
• Q:Koine-Griechisch usw.

Alle diese Q’s sind Instanzen von deinem Typ „Sprache“ oder „historische Sprachstufe“ (je nach Modell).

b) Properties für die Stufenzuordnung

Ich würde drei spezifische P’s vorsehen:

• P:ist Sprachstufe von

– Domain: Sprachstufe

– Range: „Abstrakte Sprache“ oder „Sprachkontinuum“ (z. B. Q:Deutsch allgemein)

Beispiel:

– „Mittelhochdeutsch“ – ist Sprachstufe von → „Deutsch (Gesamt)“

• P:Zeitspanne Beginn (oder generisches P:Beginn)

• P:Zeitspanne Ende (oder generisches P:Ende)

Damit kannst du zeitliche Geltung einer Sprachstufe erfassen (z. B. 1050–1350).

Du kannst dafür auch deine allgemeinen „Beginn/Ende“-Properties nutzen, statt spezielle nur für Sprachen anzulegen.

Optional (wenn du Sprachstufen genealogisch ordnen willst):

• P:vorherige Sprachstufe / nachfolgende Sprachstufe

– linearisiert z. B.: Althochdeutsch → Mittelhochdeutsch → Neuhochdeutsch.

c) Verbindung zu Dialekt/Varietät

Sprachstufe vs. Dialekt kannst du trennen, indem du:

• Sprachstufe: P:ist Sprachstufe von
• Dialekt: P:ist Dialekt/Varietät von

Beides sind dann unterschiedliche „Artweisen“ von Unterordnungen, die du später in Skripten unterschiedlich behandeln kannst (z. B. Auswahlmenü „Sprache“, gefiltert nach Sprachstufen oder Dialekten).

4. Minimal-Set, das ich für dich als Start empfehle

Für deine unmittelbare Frage („Welche P’s eignen sich …?“) und mit Blick auf spätere Skripte (Menüs für L-Anlage) würde ich folgendes Kern-Set anlegen:

1. P:ist Instanz von (P31-Äquivalent; global im System)
2. P:ist Unterklasse von (P279-Äquivalent; global)
3. P:hat Sprachfamilie (Sprache → Sprachfamilie)
4. P:ist Dialekt/Varietät von (Varietät → Basissprache)
5. P:ist Sprachstufe von (Sprachstufe → Abstrakte Sprache / Sprachkontinuum)
6. P:Schriftsystem (Sprache → Schriftsystem)
7. P:ISO639-3 (optional, aber sehr praktisch für Mapping nach außen)
8. P:Beginn / P:Ende (Zeitspanne; global, auch für andere Entitäten nützlich)

Mit diesen acht Typen kannst du:

• deine Sprach-Q’s technisch gut unterscheiden,
• Sprachfamilien und Sprachstufen strukturiert aufbauen,
• später in einem Lexeme-Anlege-Skript sauber filtern: – „zeige mir alle Sprachen mit Rollenmerkmal X“, – „zeige nur moderne Sprachstufen“, – „zeige Sprachstufen einer Basis-Sprache“.

Wenn du möchtest, können wir im nächsten Schritt:

• einmal konkret drei Deutsch-Sprachstufen und ihre Properties durchmodellieren (inkl. Beispieldaten),
• und daraus direkt eine Query ableiten, die du für dein zukünftiges Lexeme-Menü nutzen kannst.

Datentypen der Spracheigenschaften

Danke für das "Gerüst". Welche Datentypen weist man diesen Spracheigenschaften zu?

Durchsuchen von Wikidata nach Datentypen für Eigenschaften

Überprüfen von Wikibase-Datentypen für bestimmte Eigenschaften

Durchsuchen älterer Daten für Datentyp von P31

Suchen nach Datentyp für ISO639-3-Seite

Durchsuchen der Web-Daten für Wikidata-Codes

Zuordnen von Datentypen

Die Frage des Nutzers betrifft die Zuordnung von Wikibase-Datentypen zu verschiedenen Spracheigenschaften. Hier sind die empfohlenen Typen:

• „ist Instanz von“: wikibase-item
• „ist Unterklasse von“: wikibase-item
• „hat Sprachfamilie“: wikibase-item
• „ist Dialekt/Varietät von“: wikibase-item
• „ist Sprachstufe von“: wikibase-item
• „Schriftsystem“: wikibase-item
• „ISO 639-3“: external identifier
• „ISO 639-1 Code“: external

Zuordnen von Datentypen für Wikibase-Eigenschaften

Zuweisung von Datentypen

Für die Frage zur Zuweisung von Datentypen zu Sprach-Eigenschaften:

• Für Beziehungen zwischen Entitäten verwenden wir 'Wikibase-Element'.
• Für Codes/Identifier sollten 'Externes Identifier' oder 'String' verwendet werden, je nach Verwendungszweck.
• Für Zeiten braucht man 'Zeit'. In speziellen Fällen könnten auch 'Monolingualtext' oder 'Menge' relevant sein, aber hier nicht notwendig.

Zuweisung von Datentypen

Für Codes wie ISO 639-3 oder IETF sollten wir den Datentyp „Externer Identifier“ verwenden, besonders für stabile Codes. Wenn keine URL-Formatierung benötigt wird, könnte auch „String“ ausreichend sein. Für andere Verhältnisse, wie Sprachfamilie oder Dialekte, verwenden wir „Wikibase-Element“. Für Start-/Endzeiten ist „Zeit“ geeignet. Ein paar zusätzliche Datentypen wie „Monolingualtext“ könnten relevant sein, aber hier nicht notwendig.

Zuweisung von Datentypen

Standardisierte Codes nutzen den Datentyp "Externer Identifier"

Nachgedacht für 1m 12s

Fertig

Genau, jetzt sind wir bei der „nackten Technik“ von Wikibase – also: welchen Datentyp bekommt welches P?

Ich nehme deine bisherige Liste als Grundlage:

• P:ist Instanz von
• P:ist Unterklasse von
• P:hat Sprachfamilie
• P:ist Dialekt/Varietät von
• P:ist Sprachstufe von
• P:Schriftsystem
• P:ISO 639-3 (und ggf. ISO 639-1, IETF-Tag, Wikimedia-Code)
• P:Beginn / P:Ende (Zeitspanne)

Und ordne jeweils den passenden Wikibase-Datentyp zu.

1. P:ist Instanz von / P:ist Unterklasse von

Beides sind Relationen zwischen Q-Objekten:

• P:ist Instanz von (dein P31-Äquivalent)
• P:ist Unterklasse von (dein P279-Äquivalent)

👉 Datentyp in Wikibase: Wikibase item

So macht es auch Wikidata:

• instance of (P31) – Data type: Item
• subclass of (P279) – Data type: Item

2. Struktur-Properties für Sprachen

P:hat Sprachfamilie

• Relation: Sprache → Sprachfamilie (beides Q-Items).

👉 Datentyp: Wikibase item

(Macht es dir später leicht, über Familie zu filtern und zu navigieren.)

P:ist Dialekt/Varietät von

• Relation: Dialekt / Varietät → Basissprache (beides Q).

👉 Datentyp: Wikibase item

P:ist Sprachstufe von

• Relation: Sprachstufe → abstrakte Sprache / Sprachkontinuum (beides Q).

👉 Datentyp: Wikibase item

All diese „Struktur-P’s“ sind schlicht Kanten im Item-Graph, also immer Datentyp Wikibase item.

---

3. P:Schriftsystem

Entspricht inhaltlich writing system (P282) in Wikidata:

• Domain: Sprache / Languoid
• Range: Schriftsystem-Item (z. B. „lateinische Schrift“, „griechisches Alphabet“).

Wikidata verwendet dafür Datentyp Item.

👉 Empfehlung: Wikibase item

• Vorteil: du kannst Schriftsysteme selbst als Q-Objekte modellieren und wiederverwenden (auch bei Lexemen, Eigennamen etc.).

4. Code-Properties (ISO, IETF, Wikimedia)

Hier geht es um Zeichenketten, die normierte Identifier repräsentieren.

Wikibase unterscheidet im UI:

• String (beliebige Zeichenfolge)
• External identifier (Zeichenfolge mit Semantik „externer Code“, inkl. Formatter-URL etc.)

Für Normcodes ist External identifier sinnvoller.

P:ISO 639-3

Wikidata ISO 639-3 code (P220):

• Data type: External identifier

👉 Empfehlung: External identifier

Optional: P:ISO 639-1

Analog zu ISO 639-1 code (P218); auch dort wird er als externer Identifier geführt.

👉 Empfehlung: External identifier

Optional: P:IETF-Language-Tag (BCP-47)

IETF language tag (P305) in Wikidata:

• Data type: External identifier (nicht „plain string“)

👉 Empfehlung: External identifier

(So kannst du später bei Bedarf Formatter-URLs, Regex-Constraints etc. hinzufügen.)

Optional: P:Wikimedia-Sprachcode

Wikimedia language code (P424) wird in Wikidata als string-basiertes Identifier-Property geführt; in Zusammenstellungen wird es als string-Typ geführt.

Hier hast du zwei Möglichkeiten:

• Wenn du das nur als „irgendeinen Code“ mit einfacher Validierung brauchst: 👉 Datentyp String
• Wenn du es konsistent wie die anderen Normcodes behandeln willst: 👉 Datentyp External identifier

Beides ist technisch okay – ich würde aus Konsistenzgründen eher auch hier External identifier nehmen.

5. Zeitliche Geltung: P:Beginn / P:Ende (Sprachstufen)

Für Sprachstufen (z. B. Althochdeutsch, Mittelhochdeutsch, Neuhochdeutsch) willst du meist einen Zeitraum haben:

• Beginn der Stufe
• Ende der Stufe

Das ist analog zu start time (P580) und end time (P582) in Wikidata:

• Beide haben Datentyp Point in time / time

👉 Empfehlung:

• P:Beginn → Datentyp Time
• P:Ende → Datentyp Time

Damit kannst du:

• Jahresgenau (oder gröber/feiner) modellieren,
• später auch chronologisch sortieren oder „gültig im Jahr X?“ abfragen.

---

Kurzfassung als „Merkschema“

Alle P’s, die auf andere Q’s zeigen

→ Datentyp Wikibase item

– ist Instanz von

– ist Unterklasse von

– hat Sprachfamilie

– ist Dialekt/Varietät von

– ist Sprachstufe von

– Schriftsystem

Alle P’s, die normierte Codes tragen

→ Datentyp External identifier

– ISO 639-3 (und 639-1/2/5/6, wenn du sie einführst)

– IETF-Language-Tag (BCP-47)

– ggf. auch Wikimedia-Sprachcode

Zeitliche Geltungsangaben

• → Datentyp Time – Beginn – Ende

Wenn du magst, können wir im nächsten Schritt für ein konkretes Beispiel

(„Deutsch“ + „Althochdeutsch / Mittelhochdeutsch / Neuhochdeutsch“) einmal vollständig durchspielen, welche Statements du auf welche Q’s setzen würdest, einschließlich Datentyp – dann hättest du einen echten Blaupause-Ausschnitt für dein System.

"universal" formulierte Eigenschaften

Danke für den Entwurf. Jetzt habe ich ein besseres Bild davon, was wie wann anzulegen ist.

Properties lassen sich ohne weitere Dinge zuvor angelegt haben müssen anlegen.

Es ist jedoch viel verflochtener (komplexer) als ich es dir bislang dargelegt habe, so daß du nur Sprache einbeziehst, die gesprochen werden. Als Forscher habe ich nicht nur gesprochene Sprache, sondern auch Zeichensprache, Schriftsprache und Weitere, die ich im Aufbau meiner Sturktur einbeziehen muß.

Dein "ist Instanz von" würde bei mir ein "ist Einheit von" soweit es selbst eine unvermengte Einheit in einer Anzahl von Einheiten eigens fortbestehend ist und für alles verwendbar, wäre nicht auf Sprache begrenzt. In ähnlicher Artweise würde ich weitere Eigenschaften so bestimmen, daß diese wie man sagt "universal" formuliert sind, und die Items dann verdeutlichen, daß es sich um eine Sprachbeziehung handelt, wodurch ich die Anzahl der Propertie so gering wie möglich halten kann.

Überlegungen zur universellen Modellierung

Der Nutzer beschreibt ein komplexes System, das gesprochene Sprache, Gebärdensprache und Schriftsysteme umfasst. Sie möchten universellere Eigenschaften und eine Reduzierung der Anzahl der Eigenschaften. Ich könnte vorherige Vorschläge anpassen, um mehrere Modalitäten zu berücksichtigen, indem ich z.B. eine “Einheit”-Klasse mit universellen Relationen wie “gehört zu System” und “hat Modalität” entwickle.

Überlegungen zur universellen Modellierung

Ich sollte das universelle "ist Einheit von" als generischen Ersatz für P31 anerkennen und den Unterschied zwischen universellen Meta-Relationen und domänenspezifischen erläutern. Vielleicht könnte ich die Eigenschaften in universelle Meta-Ps, domänenspezifische Qualifikatoren und "Rollen"-Elemente wie "Sprach-Einheit" unterteilen. Für verschiedene Sprachmodalitäten könnte man eine Eigenschaft wie "hat Modus" oder eine Klasse "Sprachmodus" verwenden.

Überlegungen zur Modellierung von Sprachsystemen

Ich könnte den Vorschlag machen, für die Zuordnung von Systemen wie Natursprachen, Gebärdensprachen und Schriftsystemen die Eigenschaft "gehört zu System" zu verwenden. Für die Lexem-Erstellung benötigen wir dann ein "Sprache"-Feld, das ein artikelbasiertes Element erwartet. Die Unterteilung nach Modalitäten – audio-vokal, visuell-gestural, visuell-graphisch – könnte helfen, weiterhin universelle Eigenschaften zu bewahren.

Nachgedacht für 32s

Fertig

Ja, jetzt wird klar, was du vorhast:

Du willst nicht „Sprach-Ontologie nach Wikidata“, sondern ein universelles Einheiten-System, in dem Sprache nur ein Spezialfall ist – und die Properties bleiben so generisch wie möglich.

Ich greife drei Punkte heraus und passe den Entwurf daran an.

---

1. Dein „ist Einheit von“ als universelles P31

Dein Gedanke:

„ist Instanz von“ → bei mir „ist Einheit von“, für alles verwendbar, nicht nur für Sprachen.

Das lässt sich technisch in Wikibase sauber machen:

• Du definierst ein einziges universelles Property, z. B. P:ist Einheit von (statt P31/„instance of“).
• Datentyp: wie zuvor besprochen → Wikibase item.
• Semantik (deine Definition): „Dieses Ding gehört als Einheit zu jenem System / Typ / Gefüge.“

Damit kannst du dann z. B.:

• eine gesprochene Sprache als Einheit eines Sprachsystems sehen
• eine Schrift als Einheit eines Zeichensystems
• ein Lexem als Einheit eines Lexemsystems usw.

Wichtig:

Du musst dich nicht an die P31-/P279-Semantik von Wikidata binden.

Du legst ein eigenes Bedeutungsfeld für „Einheit“ fest, das dann in allen Domänen gleich bleibt.

2. „Universal“ formulierte Properties + domänenspezifische Items

Statt viele spezielle Sprach-Properties anzulegen, kannst du viel über universale Properties + Spezial-Items lösen.

2.1 Universal-Properties (Beispiele)

Nur als Skizze:

1. P:ist Einheit von – universell, ersetzt P31 für dich
2. P:ist Untereinheit von – universell für hierarchische Gliederung – z. B. „Neuhochdeutsch ist Untereinheit von Deutsch (Sprachkontinuum)“ – oder „Schriftsprache X ist Untereinheit von Sprachsystem Y“
3. P:hat Modalität / P:hat Ausdrucksmodus – universell verwendbar für: gesprochene, geschriebene, gebärdete, getippte, akustische, visuelle Modi
4. P:Beginn / P:Ende – universell für zeitliche Geltung (Sprachstufen, Forschungsprojekte, Systeme allgemein)
5. P:hat Systemrolle (optional) – zur Feindifferenzierung: „ist Dialekt“, „ist Sprachstufe“, „ist Schriftsystem“, „ist Zeichensprache“ – als Items.

Alle diese Properties sind nicht sprachspezifisch.

Die „Sprachhaftigkeit“ kommt erst durch die Items, auf die du sie anwendest.

2.2 Domänenspezifische Items

Du führst Items ein, die Rollen / Arten von Systemen und Modalitäten ausdrücken, z. B.:

• Q:Sprachsystem (generell)
• Q:gesprochenes Sprachsystem
• Q:Gebärdensprachsystem
• Q:Schriftsystem
• Q:Zeichensystem allgemein
• Q:lexikalische Einheit
• Q:schriftliche Zeichenfolge
• Q:Gestenkomponente usw.

Dann kannst du z. B. modellieren:

• „Deutsche Lautsprache“ – ist Einheit von → „gesprochenes Sprachsystem“
• „Deutsche Schriftsprache“ – ist Einheit von → „Schriftsystem (Deutsch)“
• „Deutsche Gebärdensprache“ – ist Einheit von → „Gebärdensprachsystem (Deutsch)“

oder:

• „Deutsch (Gesamt)“ – ist Einheit von → „Sprachsystem“ – „Deutsche Lautsprache“ – ist Untereinheit von → „Deutsch (Gesamt)“ – „Deutsche Schriftsprache“ – ist Untereinheit von → „Deutsch (Gesamt)“ – „Deutsche Gebärdensprache“ – ist Untereinheit von → „Deutsch (Gesamt)“

So bleibt dein Property-Vokabular knapp, und die Unterschiede tragen die Items.

3. Verbindung zu Lexemen und Sprachen in Wikibase

Für die technische Lexeme-Maske gilt weiterhin:

• Das Feld „Sprache“ erwartet einfach ein Item. Dieses Item ist in deiner Ontologie eine Einheit eines Sprachsystems – wie du es intern typisierst, ist der Lexeme-Maske egal.

Du kannst also:

• „Deutsch (Gesamt-Sprachsystem)“ als Sprach-Item für Lexeme verwenden oder, genauer:
• „Deutsche Lautsprache“ als Sprach-Item für phonetische/gesprochene Lexeme,
• „Deutsche Schriftsprache“ als Sprach-Item für schriftbezogene Lexeme,
• „Deutsche Gebärdensprache“ als Sprach-Item für gebärdensprachliche Lexeme.

Die Lexeme sehen nur: „Sprache“ → [Q-Item].

Deine universellen Properties (ist Einheit von, ist Untereinheit von, hat Modalität, Beginn/Ende) definieren, was diese Q-Items eigentlich sind.

Wenn du willst, können wir als nächsten Schritt ein kleines konkretes Mini-Schema aufschreiben:

• 5–6 Q’s (Deutsch gesamt, Lautsprache, Schriftsprache, DGS, „Sprachsystem“, „Modalität: gesprochen/geschrieben/gebärdet“)
• dazu 3–4 deiner universalen Properties (ist Einheit von, ist Untereinheit von, hat Modalität, Beginn/Ende)

und an einem Beispiel zeigen, wie ein einzelnes Lexem dann technisch sauber an so eine Sprachstruktur andockt, ohne dass du in die Wikidata-Begriffsschiefen hineinrutschst.

Mannigfalt an Properties

Ich über denke noch Propertie-Bestimmungen, je universeller umso weniger von ihnen. "ist Einheit von" verursacht eine Mannigfalt an Properties nach dem Muster "ist Q von", also ist-Q-von beziehungen, für die wiedrum so viele hinzukommen, wie Hilfswerden verwendung finden. Läßt man die Hilfsverben vornan weg, wird "ist Einheit von" universeller durch weglassen von "ist" zu "Einheit von" und kann noch universeller werden, wenn ich das "von" auch weglasse, wenn die Abfolge die Kanten und deren Richtung entspricht. Es ist deutlich das eine Beziehung Q-Einheit-A-> P-Einheit -> Q-Einheit-B nur bedeuten kann, das A als Einheit eine Einheit von B ist, welches eine Einheit ist – oder?

P's werde so zu Verfertger, Macher Faktoren, und so gäbe es als P's zu Einheit weitere die Artweise der Beziehung verdeutlichende Eigenheiten wie vergleichsweise Teil, Unteil (nicht-Teil), Anteil, Grenze, …

Ich sage damit nicht, daß ich dies so machen will und werde – ich schaue mir dies an ob dies so machbar und auch sinnig ist, und nicht letztlich "in eine neue Sackgasse führt".

Considering conceptual reflection

Der Benutzer reflektiert tief über die universellen Eigenschaften und die Beziehung zwischen A, P und B, wobei er mögliche Beziehungen und deren Konsequenzen in Betracht zieht. Es wäre sinnvoll, die Machbarkeit dieses Modells zu überprüfen, die potenziellen Fallstricke zu analysieren und dabei offen auf die Auswirkungen hinzuweisen, ohne zu bevormunden.

Analyzing the conceptual idea

Ich werde die Antwort klar und strukturiert geben, ohne einen langen Essay zu schreiben. Es geht um die philosophische und ontologische Diskussion, also werde ich in die Tiefe gehen:

• Die Notation A - P_einheit -> B klären.
• Das Entfernen von „ist“ und „von“ verschiebt die Semantik von einem Label hin zu einer Struktur – wir sehen A, P, B nun als Komposition.
• Die Idee, ein einziges generisches „P Einheit“ zu nutzen, erfordert die Unterscheidung zwischen Grammatik und Semantik.

Evaluating implementation options

Es gibt zwei mögliche Implementierungen: Entweder Subproperties für Einheit, wobei jedes P_x ein separates Unterattribut ist, oder ein einziges P:Einheit und zusätzliche Qualifikatoren, die die Art der Einheit bestimmen (z. B. Teil, Unteil).

Die Richtung in der Notation A P B könnte von „kleiner“ nach „größer“ verlaufen, aber das könnte zu Problemen führen, wenn zu generische Ps die Unterscheidbarkeit erschweren.

Addressing relation families and design options

Der Benutzer benötigt mindestens eine kleine Menge „Relationfamilien“ wie Einheit, Grenze, Vergleich. P kann als Verfahren zur Konstruktion einer n-ären Relation verstanden werden. Wir können Varianten wie ein generisches P:Einheit mit Qualifikator oder eine moderate Menge spezifischer Relationstypen anbieten. Grammatikbegriffe wie „ist“ und „von

Nachgedacht für 15s

Fertig

Ich gehe deinen Gedanken schrittweise mit, ohne ihn gleich zu bejahen oder zu verwerfen – und schaue mit dir, wo eine Sackgasse drohen könnte.

Ich fasse deinen Kern so:

• Grammatische Hüllen („ist“, „von“) sind Ballast.
• Du willst ein P „Einheit“ (oder funktional Gleiches), das als Kante A ⟶ B genügt, um „A ist Einheit in/gegenüber B“ auszudrücken.
• Spezifische Artweisen der Beziehung („Teil“, „Unteil“, „Anteil“, „Grenze“, …) sollen nicht über viele neue P’s, sondern über die Kombination aus einem generischen P + zusätzlichen Bestimmungen laufen.

Ich ordne das in drei Beobachtungen:

1. Reicht A — P:Einheit —► B als Bedeutungsträger?

Dein Satz:

„Es ist deutlich das eine Beziehung Q-Einheit-A-> P-Einheit -> Q-Einheit-B nur bedeuten kann, das A als Einheit eine Einheit von B ist, welches eine Einheit ist – oder?“

Formal betrachtet:

• In Wikibase ist A — P —► B zunächst nur: „A steht in Relation P zu B.“
• Die Semantik kommt erst durch deine Lese-Regel.

Wenn du festlegst:

Lese-Regel:

Für jedes Tripel A — Einheit —► B gilt:

„A ist eine Einheit in Bezug auf B; B ist ein Gefüge/Träger, in dem A als Einheit bestimmt ist.“

… dann genügt eine einzige solche Kante, um genau diese Bedeutung zu tragen.

Logisch brauchst du kein „ist“ und kein „von“ im Label; die Richtung der Kante übernimmt das.

Die Gefahr liegt nicht in der Kante selbst, sondern in zwei anderen Punkten:

1. Eindeutigkeit der Lese-Regel – du musst sie so formulieren, dass du sie später in allen Domänen (Sprache, Zeichen, Personen, Werke, …) noch tragen kannst, ohne Widersprüche zu erzeugen.
2. Feinkörnigkeit – je mehr Bedeutung du in eine einzige Relation „Einheit“ packst, desto mehr musst du später über „Art der Einheit“ nachziehen (z. B. Qualifikatoren, zusätzliche P’s).

Grundsätzlich: Ja, ein generisches P:Einheit kann die Rollen übernehmen, die P31/P279/P361 in klassischen Modellen abdecken – wenn du deine Lese-Regel stabil hältst.

2. „Verfertiger-P’s“: Ein generisches P + Artweise der Einheit

„P's werde so zu Verfertger, Macher Faktoren, und so gäbe es als P's zu Einheit weitere die Artweise der Beziehung verdeutlichende Eigenheiten wie vergleichsweise Teil, Unteil (nicht-Teil), Anteil, Grenze, …“

Das ist ein sauberer Gedanke:

• Du trennst:
  • Relator P:Einheit → „stellt eine Einheit-Beziehung her“
  • Art der Einheit → eigenes Stück Information (Item oder zweites Property)

Technisch gibt es zwei prinzipielle Muster:

Variante A: Nur ein P:Einheit + „Einheitsart“ als Zusatz

• Property 1: P:Einheit – Datentyp: Item – immer A — Einheit —► B
• Property 2: P:Einheitsart (als Qualifikator [oder zweites Statement]) – z. B. Werte: Q:Teil, Q:Unteil, Q:Anteil, Q:Grenze, Q:Rolle, …

Beispiel:

• A — Einheit —► B
  • Qualifikator Einheitsart: Teil
• C — Einheit —► D
  • Qualifikator Einheitsart: Grenze

Vorteil:

• Du behältst ein extrem kleines, universelles Property-Set.
• Neue Arten von Einheit (z. B. „Überlagerung“, „Spur“, „Schnittmenge“) entstehen nur als neue Items, nicht als neue Properties.

Preis:

• Jede Auswertung muss immer mindestens zwei Ebenen lesen:
  • „gibt es eine Einheit-Beziehung?“
  • „welche Einheitsart liegt hier vor?“

Datenmodell bleibt schlicht, Semantik sitzt stärker in deinen Q’s.

Variante B: Moderate Anzahl spezialisierter P’s

• P:Einheit (sehr allgemein)
• P:Teil-Einheit von
• P:Grenze von
• P:Anteil von usw.

Vorteil:

• Abfragen sind teilweise einfacher („finde alle Teil-Beziehungen“, ohne Qualifikatoren auszuwerten).
• Manche Strukturen sind „auf einen Blick“ klarer.

Preis:

• Mehr Properties.
• Du musst sehr diszipliniert entscheiden, wann du ein neues P anlegst und wann du bei Qualifikatoren bleibst – sonst hast du schnell wieder die „neue Sackgasse“, die du vermeiden willst.

Aus meiner Sicht ist Variante A näher bei dem, was du beschreibst:

P’s als Verfertiger, Q’s als Träger der Artweisen.

---

3. Wo könnte hier die Sackgasse liegen?

Ich sehe drei potentielle Engstellen – nicht als Urteil, sondern als Prüfstellen:

1. Über-Universalisierung von P:Einheit Wenn P:Einheit „alles Mögliche“ tragen soll (Teil/Ganzes, Klassen/Elemente, Rollen in Prozessen, Sprachsystem/Sprachstufe/Einheit im Dialog…), kann es passieren, dass:
   • manche Skripte nicht mehr wissen, welche Art von Einheit sie eigentlich meinen dürfen,
   • du sehr häufig zusätzliche Filter brauchst („nur Einheit-Beziehungen mit Art X, Y, Z“). Das ist lösbar, aber du musst dann konsequent deine Einheitsarten-Typen definieren und nutzen.
2. Verlust von logischer Struktur, wenn alle Relationstypen gleich behandelt werden Klassische Modelle unterscheiden nicht ohne Grund zwischen:
   • Teil-Ganzes („part of“)
   • Element-Menge („member of“)
   • Typ-Instanz („instance of“)
   • Grenze („boundary of“)
   • Identität („same as“) … Wenn du alles unter „Einheit“ subsumierst, musst du an anderer Stelle (z. B. bei Einheitsart) dafür sorgen, dass du diese Unterschiede nicht verlierst, sonst weiß eine Auswertung später nicht mehr:
   • „Kann ich hier transitiv schließen?“
   • „Ist das eine hierarchische Struktur oder eine bloße Zuordnung?“
3. Komplexität der Lese-Regeln Je universeller du wirst, desto mehr hängt daran, dass du deine internen Regeln stabil hältst:
   • „Wenn Einheitsart = Teil, dann darf ich X und Y tun.“
   • „Wenn Einheitsart = Grenze, dann gelten andere Gesetze.“ Das ist kein prinzipielles Problem, aber der Ort der Komplexität verschiebt sich: Weg von der Property-Vielfalt, hin zu einem feinkörnigen Typensystem für Einheitsarten.

Zwischenfazit

• Deine Richtung ist konsistent: – P’s als generische Beziehungs-Verfertiger, – Q’s als Träger von Art und Rolle der Einheit.
• A — Einheit —► B ist formal völlig ausreichend, sofern du eine klare Lese-Regel festlegst.
• Die eigentliche Arbeit verschiebt sich von „welche P’s brauche ich?“ zu „welche Typen von Einheitsart brauche ich und wie nutze ich sie verlässlich?“.

Wenn du weiterprüfen willst, ob das machbar und sinnig ist, wäre ein nächster Schritt aus meiner Sicht:

• Wir nehmen eine kleine, konkrete Domäne (z. B. nur „Deutsch gesamt / Lautsprache / Schriftsprache / DGS / Lexem ‚Hund‘“)
• und modellieren:
  • 3–4 Q’s,
  • 1 P:Einheit + 1 P:Einheitsart
  • und schauen, ob wir damit alles ausdrücken, was du für deine Lexeme tatsächlich brauchst, ohne neue Hilfskonstrukte.

Wenn es dort tragfähig bleibt, ist die Wahrscheinlichkeit hoch, dass du dir damit keine neue Sackgasse baust.

Klarstellung

Prüfe deine Bedenken erneut gemäß folgender Klarstellungen, wobei meine folgenden 1-4, sich nicht auf Zahlen deines Prompt's beziehen:

1. „ist“, „von“ und dem Ähnliche Hilfsverben, Umstandswörter, … sind keinesfalls "Grammatische Hüllen" und auch kein "Ballast", sondern werden durch deren Auslassung in die Ebene der Erkenntnis gehoben! "A — P —► B" wird zu "A —► P —► B" und bleibt Subjekt—►Prädikat—►Objekt, wobei auch das Prädikat eine Umkehr zu "A ◀— P ◀— B" oder auch "A ◀— P —► B" äußern kann und ausgesprochen dann die Hilfverben, Umstanswörter, … hinzukommen. Ich könnte sogar Prädikate als Token basierte formale Logik nutzen – oder?

"Einheit" ist an sich kein Q sondern verdinglicher Daseinszustand, Q's haben die Eigenheit, das Prädikat Einheiten zu sein – richtig?

2. Wenn P:Einheit „alles Mögliche“ tragen soll …

Einheit als P trägt nur Einheit, so würde vergleichsweise Grenz als P nur Grenze tragen, eine Aussage wie "Q-Niederlande-P-Grenze-Q-Deutschland" läßt sich vielfältig aussprechen, würde im Kern jedoch immer bedeiten, daß die Niederlände eine Grenze zu Deutschland hat.

3. Ich muß keine Leserichtung vorgeben, da die Leserichtung durch die Abfolge durch S-P-O vorgegeben ist.

4. Bei dieser Artweise kommt gewiß der Qualifizierer, welcher wieder ein  Prädikat oder Eigenheit ist, ins Spiel sollte ein einzelner Prädikator keine eindeutige Aussage geben, sowie auch Werte oder Modalitäten eine Aussage "schärfen" können – oder?

Überprüfung der Klarstellungen

Wir müssen die früheren Bedenken neu bewerten und die Klarstellungen des Nutzers berücksichtigen. Es geht darum, "ist"/"von" zu entfernen und das Modell als A —► P —► B darzustellen. Die Einheit soll als Prädikat genutzt werden, nicht als Qualifikation. Wir sollten präzise bleiben, Fakten von Mutmaßungen trennen und auf die Logik des Nutzers eingehen.

Überlegungen zur Systemstruktur

Es scheint, dass die Idee, Qs als Einheiten zu behandeln, eine interessante Überlegung ist. Wir müssen klären, ob das mit den Wikibase-Beschränkungen kompatibel ist, besonders in Bezug auf die Datentypen von Eigenschaften. Wikibase verwendet spezielle ID-Strukturen, die nicht direkt als Subjekt oder Objekt fungieren, was zu einer Trennung von Konzepten führt.

Überprüfung von Grammatik und Konzepten

Der Kommentar zu „ist“ und „von“ zeigt, dass diese nicht als Inhalt betrachtet werden, sondern Ausdrucksformen sind – das bedeutet, wir müssen sie als zusätzliche Tokens in der Ontologie betrachten. Auch wenn wir zuvor „grammatische Hüllen“ nannten, müssen wir jetzt anerkennen, dass sie konzeptionell keine Ballast sind. Es gibt Fortschritte bei den Bedenken zur Universalität und logischen Unterscheidungen.

Überlegungen zur Komplexität der Leseregeln

Die Leseregeln sind durch die S-P-O-Struktur gut zu handhaben, wobei Qualifikatoren nur bei Bedarf hinzugefügt werden. Die Unterscheidung zwischen Q und P ist wichtig: „Einheit“ wird als Prädikat (P) betrachtet, nicht als Q. Wir sollten die Begriffe weiter klären und die Idee einer logik-basierten Namensgebung für Prädikate ansprechen.

Nachgedacht für 26s

Fertig

Gut, das hilft, die offenen Punkte genauer zu justieren. Ich gehe deine 1–4 nacheinander durch und prüfe meine früheren Bedenken daran neu ausgerichtet.

1. „ist“, „von“, S–P–O und A —► P —► B

Du stellst zwei Ebenen klar:

• Daten-Ebene: A — P —► B (Subjekt, Prädikat, Objekt – Property als Kante)
• Erkenntnis-/Sprachausdruck: aus A — P —► B werden verschiedene Lesarten:
  • „A ist P von B“
  • „B hat P in Bezug auf A“
  • usw., mit „ist“, „von“, Umstandswörtern als Ausdrucksbestandteilen.

Ich hatte „ist“, „von“ etwas flapsig als „Hüllen/Ballast“ bezeichnet – im Sinne: sie gehören nicht mehr zur technischen Relation im Wikibase-Datenmodell.

Du sagst zu Recht: in der Erkenntnis- und Ausspracheebene sind sie gerade nicht Ballast, sondern das Material, in dem die Relation ausgesprochen und bewusst gemacht wird.

Zu deiner Frage:

„Ich könnte sogar Prädikate als Token basierte formale Logik nutzen – oder?“

Ja, das ist kompatibel:

• In Wikibase sind P-IDs sowieso Tokens (P123, P456 …).
• Du kannst diese Tokens so wählen und dokumentieren, dass sie deine logische Rolle spiegeln (z. B. P:EINHEIT, P:GRENZE, P:ANTEIL … oder systematisch kodiert).
• Formal-logisch gesehen ist dann jedes Property ein Prädikator aus deiner Token-Sprache, der in Tripeln S–P–O auftritt.

Zu „Einheit“ speziell:

„‚Einheit‘ ist an sich kein Q sondern verdinglichter Daseinszustand, Q's haben die Eigenheit, das Prädikat Einheiten zu sein – richtig?“

So würde ich das in deinem System lesen:

• Qs sind konkrete Einheiten (Gegenstände, Systeme, Stufen, …).
• „Einheit“ als Begriff ist kein einzelnes Q, sondern ein Zustand/Funktionsbegriff, der:
  • einerseits von allen Qs getragen wird („alles, was als Q vorliegt, ist eine Einheit“),
  • andererseits in Property-Form als P:EINHEIT eine bestimmte Relation zwischen Einheiten A und B ausdrückt („A wird als Einheit relativ zu B bestimmt“).

Das ist stimmig: „Einheit“ tritt bei dir nicht als Q auf, sondern als:

• implizite Daseinsbestimmung aller Qs
• explizit als Relation P:EINHEIT zwischen Qs.

Damit ist der frühere Vorschlag „Q:Einheit“ tatsächlich nicht nötig.

2. P:Einheit trägt nur Einheit – P:Grenze trägt nur Grenze

Vorherige Sorge von mir war:

„Wenn P:Einheit alles Mögliche tragen soll …“

Du präzisierst:

„Einheit als P trägt nur Einheit, so würde vergleichsweise Grenz als P nur Grenze tragen …“

Damit ist meine erste Befürchtung teilweise hinfällig:

• Du planst nicht ein einziges Super-P, das alle Typ-Instanz-, Teil-Ganzes-, Rollen-, Grenz- usw. Beziehungen auf sich vereint.
• Sondern: – P:EINHEIT für Einheitsrelationen, – daneben P:GRENZE, P:TEIL, P:ANTEIL, … – jeweils mit klarer semantischer Geltung.

Beispiel, das du nennst:

„Q-Niederlande – P-Grenze – Q-Deutschland“

Diese Kante kann in der Tat in vielen Sätzen ausgesprochen werden („Niederlande grenzen an Deutschland“, „zwischen Niederlanden und Deutschland liegt eine Grenze“, …), der Kern bleibt:

• Es besteht eine Grenzrelation zwischen der Einheit „Niederlande“ und der Einheit „Deutschland“.

Damit verschiebt sich die Komplexität:

• nicht mehr: „P:EINHEIT trägt alles“,
• sondern: „wir definieren ein überschaubares Set von Prädikatoren (Einheit, Grenze, Teil, Anteil …), deren Bedeutung klar begrenzt ist“.

Das ist deutlich besser kontrollierbar.

---

3. Leserichtung über S–P–O

„Ich muß keine Leserichtung vorgeben, da die Leserichtung durch die Abfolge durch S-P-O vorgegeben ist.“

Ja – auf der Datenebene von Wikibase/RDF ist klar:

• Ein Statement ist (Subjekt, Property, Objekt).
• Die Richtung ist von Subjekt zu Objekt.

Du kannst dann auf der Ausdrucksebene:

• immer A — P —► B als Grundform zugrunde legen
• und bei Bedarf umformulieren (z. B. „B hat in Bezug auf A die Rolle P“), ohne dass das Datenmodell sich ändert.

Mein vorheriger Hinweis zur „Lese-Regel“ war weniger gegen diese Richtung gerichtet, sondern auf die Rolleninterpretation:

• Was heißt „Einheit“ in A — EINHEIT —► B?
• Ist das eher „Mitglied von“, „Teil von“, „Stufe von“, „Rolle in“?

Mit deiner Entscheidung, separate P’s für Einheit/Grenze/Teil/… anzulegen, wird diese Rolleninterpretation übersichtlicher:

• A — EINHEIT —► B → Einheitsrelation
• A — GRENZE —► B → Grenzrelation
• A — TEIL —► B → Teil-Ganzes-Relation

Die Leserichtung S–P–O ist dann für alle gleich, die Relationstypen unterscheiden sich.

4. Qualifikatoren / Modalitäten als „Schärfung“

„… kommt gewiß der Qualifizierer, welcher wieder ein Prädikat oder Eigenheit ist, ins Spiel sollte ein einzelner Prädikator keine eindeutige Aussage geben, sowie auch Werte oder Modalitäten eine Aussage ‚schärfen‘ können – oder?“

Das passt gut zu der Variante, die ich vorher „Variante A“ genannt hatte:

• Haupt-Prädikat: P:EINHEIT, P:GRENZE, P:TEIL etc.
• Zusätzliche Prädikate/Eigenheiten als:
  • Qualifikatoren (Wikibase-Qualifiers)
  • oder Zusatz-Statements auf demselben Subjekt

Beispiele:

• A — TEIL —► B
  • Qualifikator Art: materieller Teil / Art: funktionaler Teil
• A — GRENZE —► B
  • Qualifikator Art: politisch, Art: geographisch, Art: zeitlich
• A — EINHEIT —► B
  • Qualifikator Modalität: gesprochen, Modalität: gebärdet, Modalität: geschrieben

Damit hast du:

1. Ein klares Hauptprädikat, das schon eine ziemlich eindeutige Relation ausdrückt.
2. Feine Schärfungen durch:
   • Art-Begriffe (Q: politisch/geographisch …)
   • Modalitäts-Begriffe (Q: gesprochen/gebärdet/geschrieben)
   • ggf. Werte (etwa Zeitpunkte, Maße, Intervalle).

Das adressiert meine dritte Bedenken-Stelle:

Die Komplexität wächst nicht unkontrolliert, wenn:

• die Haupt-P’s klar definiert sind,
• die Qualifikatoren als „Schärfungen“ bewusst sparsam und systematisch eingesetzt werden.

---

Gesamtbewertung nach deinen Klarstellungen

• Die Idee, P’s von verbalen Einhüllungen zu befreien (kein „ist“, kein „von“ im Label) und S–P–O als „reine Relation“ zu sehen, ist für ein formales System sinnvoll – die sprachliche Hülle ist dann reine Ausdrucksfrage.
• „Einheit“ als Daseinszustand aller Qs und zugleich als Relation P:EINHEIT zwischen Qs ist für dein Konzept konsistent, solange du diese Ebene sauber von „Grenze“, „Teil“, „Anteil“ usw. trennst.
• Wenn du mehrere klar definierte P’s für Einheitsarten (Einheit, Grenze, Teil, Anteil …) vorsiehst und Qualifikatoren nur zur Schärfung nutzt, schwächt das meine ursprünglichen Bedenken deutlich ab:
  • keine Überlastung eines einzigen Super-P,
  • kein Verlust der logischen Unterschiede,
  • beherrschbare Lese-Regeln.

Ob es „in eine neue Sackgasse führt“, hängt aus meiner Sicht jetzt weniger von der Zahl der P’s ab, sondern davon, ob du:

• für jede relationale Hauptkategorie ein eindeutiges P definierst und
• konsequent dieselben P’s in unterschiedlichen Domänen gleich verwendest.

Wenn du magst, können wir als nächstes einmal konkret für eine kleine Gruppe von Beziehungen festnageln:

• P:EINHEIT
• P:TEIL
• P:GRENZE
• P:MODALITÄT (oder Modalität nur als Qualifikator-Item)

und jeweils 2–3 Beispiel-Tripel formulieren (z. B. für Sprachsysteme, Schriftsysteme, Gebärdensysteme), um zu prüfen, ob sich die gewünschte Aussagekraft damit wirklich ergibt – ohne Zusatzkonstrukte.

Werte werden zu Q's

Danke für deine Darlegung und deine Bedenken von zuvor waren ohne meine Klarstellung berechtigt. Wen  ich das nun  so ausüben würde, stellt sich die Frage wie man die Aussage "Johann Christoph Adelung wurde 1732 geboren" oder "Johann Christoph Adelung hat Geburtdatum 1732" als Tripple anlegt.

Q-Adelung — P-Geburtdatum —► Q-1732. Werte werden zu Q's und aus dieser Beziehung lassen sich alle Leseweisen generieren.

Oder:

Q-Adelung — P-Geburtdatum —► P-1732. Werte sind Qualifizierer und aus dieser Beziehung lassen sich alle Leseweisen generieren.

Noch einfacher wird es wie folgt (? steht für P oder Q, je nach technischer Möglichkjeit):

Q-Adelung — P-Geburt mit Datentyp Item —► ?-1732 mit Datentyp-Datum

Alternativ dazu:

Q-Adelung — P-geboren mit Datentyp Eigenschaft —► ?-1732 mit Datentyp-Datum

Dann wird möglich:

Q-Adelung — P-Geburt mit Datentyp Item —► ?-Spantekow mit Datentyp-Ort

Alternativ dazu:

Q-Adelung — P-geboren mit Datentyp Eigenschaft —► ?-Spantekow mit Datentyp-Ort

Auch damit ließen sich alle im Kontext sinnigen Formulierungen ausgestalten – oder?

Evaluating modeling options

I need to evaluate three different ways to model birth date/place using RDF/ontology.

1. Treat 1732 as a Q entity with property P-Geburtdatum.
2. Treat 1732 as P, potentially mixing schema and instance, with Q-Adelung — P-Geburtdatum —► P-1732.
3. Compare these patterns and their pros/cons, especially with Wikibase data types and existing practice, without relying on external sources.

Let’s break this down logically.

Clarifying RDF options

The user is exploring how to model birth data using RDF. The idea of linking Q-Adelung to a property like P-Geburt and having 1732 as a date seems tricky because an object can't be both a property and an item. We'll need to clarify what type the object should be. Also, there are trade-offs in knowledge representation when trying to keep properties universal—whether combining "Zeitpunkt" and "Ort" into one or using separate properties for each.

Analyzing Variant A

Für Variante A: Q-Adelung — P-Geburtdatum —► Q-1732, beide Subjekt und Objekt sind Items, während die Eigenschaft einen Itemwert enthält. Das Modellieren von 1732 als Item ist erlaubt, da Jahre oder Daten als Items erstellt werden können. Die natürliche Sprache könnte also "Adelung hat Geburtsjahr 1732" formuliert werden. Weitestgehend faktisch im RDF-Modell.

Evaluating Variant B and C1

Für Variante B: Q-Adelung — P-Geburtdatum —► P-1732 wird eine Eigenschaft als Objekt verwendet, was Meta-Modellierung ist. Das ist grundsätzlich zulässig, aber es könnte wirr wirken, dass die Eigenschaft als "Jahr 1732" modelliert wird, was unnatürlich erscheint. In Variante C1 sind 1732 als Datentyp ein Item, aber auch hier müsste man genaue Datentypen wie Datum nutzen, was die Komplexität erhöht.

Nachgedacht für 1m 8s

Fertig

Du stellst genau die richtige Stelle scharf: Wie bringe ich Geburt (Ereignis), Datum und Ort in dein generelles S–P–O-Schema, ohne mir das Modell zu verbiegen.

Ich gehe in drei Schritten:

1. Was Wikibase technisch kann / nicht kann (Faktenebene)
2. Deine vorgeschlagenen Varianten im Vergleich
3. Ein Modell, das zu deiner „universalen P-Logik“ passt

1. Technische Rahmenbedingungen (Fakten)

Fakt 1

Ein Statement in Wikibase ist immer:

Subjekt (Entity) – Property – Wert

Subjekt ist z. B. ein Q-Item, Property ist ein P-Objekt, Wert ist:

• ein Literal (time, string, Zahl, …) oder
• ein Entity-Link (Item, Property, Lexem, …).

Fakt 2

Jedes Property hat genau einen Datentyp:

• time → Wert ist eine Zeitangabe
• wikibase-item → Wert ist ein Item
• wikibase-property → Wert ist ein Property
• …

Ein Property kann nicht gleichzeitig „time“ und „item“ sein.

Fakt 3

„Qualifizierer“ sind keine Sonderwesen, sondern weitere Property-Wert-Paare, die an ein Statement drangehängt werden.

2. Deine Varianten im Lichte dieser Technik

Ich schreibe sie in Kurzform und kommentiere.

Variante A

Q-Adelung — P-Geburtdatum —► Q-1732

• P-Geburtdatum: Datentyp item
• Q-1732: Item, das „Jahr 1732“ repräsentiert

Das ist technisch sauber.

Damit es semantisch trägt, müsstest du bei Q-1732 z. B. sagen:

• Q-1732 — P:Jahreszahl —► 1732 (Literal)
• Q-1732 — P:Kalender —► Q-Gregorianisch (optional)

Dann ist:

• „Adelung hat Geburtsjahr 1732“ → Lesart von Adelung — Geburtdatum —► [Jahr 1732].

Konsequenz:

Du ziehst das Datum auf die Entity-Ebene.

Alle Datumsauswertungen müssen über diese Zusatzschicht gehen (Jahr-Items).

Variante B

Q-Adelung — P-Geburtdatum —► P-1732

• P-Geburtdatum: Datentyp wikibase-property
• P-1732: ein Property mit Label „1732“.

Technisch geht das (Werttyp „Property“ ist erlaubt).

Inhaltlich wird es schief:

• Properties sind in deiner Logik „Verfertiger / Rollen“.
• Ein Property „1732“ wäre kein sinnvolles Rollenwort (es ist kein Prädikat, sondern eine Zahl).

Das wäre eine Vermischung von Schema (P-Ebene) und Daten (1732 als konkreter Wert).

Aus meiner Sicht: technisch machbar, inhaltlich unklar.

Ich würde das verwerfen.

Variante C1

Q-Adelung — P-Geburt (Datentyp Item) —► ?-1732 (Datentyp Datum)

Das ist so, wie es dasteht, ein Widerspruch:

• Wenn P-Geburt Datentyp item hat, muss der Wert ein Item sein, nicht ein Literal.

Zwei sinnvolle Lesarten:

1. Du meinst: Adelung — P:Geburtsdatum (Datentyp time) —► 1732-xx-xx → Datum als Literal (Jahr oder volles Datum).
2. Oder du willst ein Geburtsereignis als Item:
   • Q-Adelung — P:hat Ereignis (Datentyp item) —► Q:Geburt-Adelung
   • Q:Geburt-Adelung — P:Zeitpunkt (time) —► 1732-xx-xx
   • Q:Geburt-Adelung — P:Ort (item) —► Q-Spantekow

Beide sind technisch sauber, aber sie tun Verschiedenes:

• Direktes Datum → einfach, flach, schnell.
• Ereignis-Item → allgemeiner, wiederverwendbares Muster (für jeden Ereignistyp).

Variante C2

Q-Adelung — P-geboren (Datentyp Eigenschaft) —► ?-1732 (Datentyp Datum) Q-Adelung — P-geboren (Datentyp Eigenschaft) —► ?-Spantekow (Datentyp Ort)

In Wikibase-Logik:

• Ein Property hat einen Datentyp.
• Du kannst nicht dasselbe P einmal mit Werttyp „time“ und einmal mit Werttyp „item“ benutzen.

Du kannst aber:

• Zwei Properties machen:
  • P:Geburtsdatum – Datentyp time
  • P:Geburtsort – Datentyp item

oder:

• Ein Ereignis-Item benutzen (s. oben) und dann:
  • Geburt-Adelung — P:Zeitpunkt —► [Datum]
  • Geburt-Adelung — P:Ort —► [Ort]

3. Zwei saubere Muster – beide lassen alle Formulierungen zu

Jetzt zur Kernfrage:

„Auch damit ließen sich alle im Kontext sinnigen Formulierungen ausgestalten – oder?“

Ja. Jede der sauberen Varianten ist ausreichend, um alle sprachlichen Lesarten zu erzeugen.

Die Wahl entscheidet vor allem:

• wo die Komplexität liegt
• und wie universell du deine Properties halten kannst.

Muster 1: Direktes Datum / Ort (flach, nahe an Wikidata)

Minimal-Variante (Fakten):

• P:Geburtsdatum – Datentyp time
• P:Geburtsort – Datentyp item

Tripel:

• Q-Adelung — P:Geburtsdatum —► 1732-02-08
• Q-Adelung — P:Geburtsort —► Q-Spantekow

Daraus sind formulierbar:

• „Adelung wurde 1732 geboren.“
• „1732 ist das Geburtsjahr Adelungs.“
• „Der Geburtsort Adelungs ist Spantekow.“
• „In Spantekow wurde Adelung 1732 geboren.“

All diese Sätze sind nur verschiedene Aussprache desselben Datenkerns.

Vorteil (Fakt + Mutmaßung):

• Faktisch sehr einfach für Abfragen (finde alle Personen, die vor 1750 geboren sind etc.).
• Mutmaßung: Für viele Standardfälle genügt dieses Muster und ist implementierungsarm.

Muster 2: Ereignis-Modell (universaler, näher an deiner „Einheits-Logik“)

Du willst wenige universelle P’s, dafür Items, die Art und Rolle tragen.

Dann bietet sich ein Ereignis-Muster an:

Properties (universal):

• P:Ereignis – Datentyp item
• P:Zeitpunkt – Datentyp time
• P:Ort – Datentyp item
• optional: P:Ereignisart – Datentyp item

Items (rollen-/arttragend):

• Q:Geburt – Ereignisart „Geburt“
• Q:Geburt-Adelung – konkrete Geburtseinheit

Tripel:

1. Person → Ereignis:
   • Q-Adelung — P:Ereignis —► Q:Geburt-Adelung
2. Ereignis → Art / Zeit / Ort:
   • Q:Geburt-Adelung — P:Ereignisart —► Q:Geburt
   • Q:Geburt-Adelung — P:Zeitpunkt —► 1732-xx-xx
   • Q:Geburt-Adelung — P:Ort —► Q-Spantekow

Damit kannst du sagen:

• „Adelung hat ein Ereignis vom Typ Geburt“
• „Dieses Ereignis fand 1732 in Spantekow statt.“

Und daraus wieder alle üblichen Sätze generieren:

• „Adelung wurde 1732 in Spantekow geboren.“
• „Adelungs Geburt ereignete sich 1732 in Spantekow.“
• usw.

Vorteil (Mutmaßung, passend zu deiner Richtung):

• P:Ereignis, P:Zeitpunkt, P:Ort sind universal und auch für andere Ereignisse (Tod, Reise, Publikation, Gespräch) verwendbar.
• Die Spezialisierung („Geburt“, „Tod“, „Publikation“) liegt in Items als Ereignisart, nicht in neuen Properties.

4. Verhältnis zu deiner Einheits-Logik

Deine Idee:

• wenige universelle P’s (Einheit, Grenze, Teil, Anteil …)
• Artweisen als Items / Qualifikatoren.

Das Ereignis-Modell passt genau in dieses Schema:

• Du könntest P:Ereignis als Fall einer allgemeineren Kante P:Einheit (oder P:Teil) verstehen:
  • Adelung — EINHEIT —► Ereignis-Geburt-Adelung
  • Ereignis-Geburt-Adelung — EINHEIT —► Zeit 1732
  • Ereignis-Geburt-Adelung — EINHEIT —► Ort Spantekow

oder du lässt P:Ereignis, P:Zeitpunkt, P:Ort als eigenständige, klar definierte P’s stehen und schärfst sie ggf. mit Qualifikatoren.

Beides ist mit deiner Linie vereinbar; Unterschied ist nur:

• wie weit du die Universalisierung treiben willst,
• wie viel du dann über Qualifikatoren / Art-Items wieder „nachschärfst“.

Kurzantwort auf deine Frage

Ja:

• In einem formal sauberen Modell – egal ob du Geburtsjahr als Item, Literal oder Ereignis-Teil modellierst – kannst du aus dem einen Datenkern alle sinnvollen sprachlichen Formulierungen generieren.
• Der kritische Punkt ist nicht die Generierbarkeit der Sprache, sondern:
  • Datentyp-Konsistenz (Werttyp des Property),
  • Klarheit der Rollen (Geburt als Ereignis vs. Datum als Zahl/Zeitraum),
  • und ob du deine universellen P’s so definierst, dass sie über alle Domänen hinweg stabil interpretierbar bleiben.

Wenn du das möchtest, kann ich den Ereignis-Ansatz einmal konkret nur für „Geburt“ und „Tod“ durchbuchstabieren, so dass du ihn als Schablone für alle anderen Ereignisse übernehmen kannst.

Test

Ich habe zum Test folgendes angelegt:

Johann Christoph Adelung (Q11) Datentyp item

geboren (P13) Datentyp property

1732 (P14) Datentyp Zeitpunkt

Spantekow (P15) Datentyp item

Ich habe dann Johann Christoph Adelung (Q11) die Aussage geboren (P13) mit property geboren (P13) gegeben.

Dann habe ich erneut property geboren (P13) mit property Spantekow (P15) hinzugefügt, woraufhin Wikibase beide als Aussage "geboren: 1732 Spantekow zusammenfügte, alöso aus zwei Aussagen eine Aussage mit zwei properties als Werte machte.

Was sagst du nun?

Überprüfung von Wikibase-Daten

Es scheint, dass der Benutzer eine Aussage hinzugefügt hat: "geboren" (P13) mit einem Wert von "1732" (P14), was verwirrend klingt. Da "geboren" eine Eigenschaft ist, sollte der Wert eine andere Eigenschaft sein. Vielleicht wurde versehentlich "P14" als Wert verwendet, da es einem Jahr entspricht, aber es handelt sich um eine Eigenschaft und nicht um eine Zeitangabe.

Überprüfung der Wikibase-Datenmodellierung

Der Benutzer hat einen weiteren Fehler gemacht, indem er "P13" als Eigenschaft verwendet hat, aber "P13" einen anderen Werttyp erwarten sollte. Eigenschaften wie das Geburtsjahr und der Geburtsort sollten Zeit oder ein Item als Typ haben, nicht eine Eigenschaft. Jahr sollte als Literal und Ort als Item modelliert werden.

Erklärung der Wikibase-Modellierung

In Wikibase sind „Eigenschaften“ Schemaebene, ihre Werte sind keine „Werte” wie Zeit oder Items. Für das Jahr 1732 sollte entweder ein Zeitliteral oder ein Item wie „Jahr 1732“ verwendet werden. Aktuell wird die P14-Eigenschaft als Wert genutzt, was zu semantischen Inkohärenzen führt. Um „geboren: 1732 in Spantekow“ korrekt zu modellieren, sollte man "Geburtsdatum" (Pxx) als Zeit und „Geburtsort“ (Pyy) als Item angeben.

Alternative Modellüberlegung

Wir können ein separates Item für das „Geburtsereignis von Adelung“ erstellen, aber wir sollten den Benutzer durch das Verständnis des Wikibase-Modells führen. Der Versuch, Jahr und Ort als Eigenschaften zu behandeln, ist ein häufiger Fehler. In unserem Modell sollten 1732 und Spantekow als Zeit oder Items behandelt werden, nicht als Eigenschaften.

Nachgedacht für 26s

Fertig

Was du beobachtet hast, ist in sich stimmig – und zeigt ziemlich genau, wo Wikibase deine Idee begrenzt.

Ich gehe das einmal Schritt für Schritt durch, in Wikibase-Sprache:

---

1. Was du technisch angelegt hast (aus Sicht von Wikibase)

Du hast:

• Q11 – Johann Christoph Adelung (Item)
• P13 – geboren mit Datentyp property
• P14 – 1732 ebenfalls als Property, Datentyp „Zeitpunkt“
• P15 – Spantekow ebenfalls als Property, Datentyp „item“

Dann:

1. Auf Q11 eine Aussage:

   Q11 — P13 —► P14

   In Wikibase-Sprache: „Adelung — geboren —► (Property) 1732“ Wert von P13 ist hier: ein Property-Objekt (P14).
2. Dann noch eine Aussage:

   Q11 — P13 —► P15

   Also: „Adelung — geboren —► (Property) Spantekow“

Wikibase gruppiert alle Statements mit demselben Property (P13) zu einem Statement-Block und listet die Werte nebeneinander:

geboren: 1732, Spantekow

Das sieht für dich wie

„eine Aussage mit zwei properties als Werte“ aus – technisch ist es:

• eine Property (P13)
• zwei Werte vom Typ „wikibase-property“ (P14 und P15)

Wikibase macht hier also genau das, was du ihm konfiguriert hast:

• P13 ist ein Property-zu-Property-Relationstyp.
• P14 und P15 sind „Datenlieferanten-Eigenschaften“, aber keine Jahre oder Orte als solche.

---

2. Warum das für Geburtsdatum/-ort nicht das ist, was du willst

In deinem Versuch sollten 1732 und Spantekow Werte sein (Jahr, Ort),

du hast sie aber als Properties modelliert.

Das führt zu zwei Effekten:

1. Semantische Schieflage
   • „1732“ als Property ist kein sinnvolles Prädikat.
   • 1732 ist ein Wert (Zahl / Zeitpunkt), nicht ein „Verfertiger“. Gleiches gilt für Spantekow – du willst es als Ortseinheit, nicht als „Verfertiger“.
2. Eigentliche Information fehlt
   • Es gibt nirgends ein Datum-Literal 1732-xx-xx.
   • Es gibt nirgends ein Ort-Item für Spantekow.
   • P14 und P15 verweisen nicht auf Datum/Ort, sondern sind nur Schemaobjekte.

Wikibase kann aus:

Adelung — geboren —► (Property) 1732, (Property) Spantekow

keine sinnvolle Datenstruktur machen, die so etwas trägt wie:

• „Geburtsdatum = 1732“
• „Geburtsort = Spantekow“

Es sieht für Wikibase eher so aus wie:

„Property geboren steht in Beziehung zu Property 1732 und Property Spantekow“

also eine Meta-Relation zwischen Properties, keine Personen-Daten.

---

3. Was dein Test deutlich macht

Für mich zeigt dein Experiment:

• Deine konzeptionelle Idee (Prädikate als Verfertiger, Werte als Einheiten) ist in sich stimmig.
• Wikibase erlaubt aber nur ganz bestimmte Kombinationen:
  • Property hat genau einen Datentyp.
  • Werte sind entweder Literale (Zeit, Zahl, String, …) oder Entities (Item, Property, Lexem …).
  • „Jahr 1732“ als Property benutzen, um „1732“ als Wert darzustellen, ist aus Sicht des Systems ein Typfehler.

Dein Versuch ist genau der Grenzfall, an dem man sieht:

• Man kann die formale Freiheit der Relation „S–P–O“ nicht vollständig auf die Property-Schicht von Wikibase übertragen.
• Wikibase trennt hart:
  • Schema (Properties)
  • Daten (Items + Literale)

Du hast versucht, Daten (Jahr, Ort) in die Schemaseite (Properties) zu schieben – das System behandelt sie dann konsequent als Schemaelemente.

---

4. Wie würde ich dieselbe Aussage in deinem Geist, aber wikibase-gemäß modellieren?

Wenn wir deine Idee ernst nehmen, aber in den technischen Rahmen von Wikibase einpassen, bleiben im Kern zwei sinnvolle Muster:

Muster A: Flach und einfach (nah an Wikidata)

• P:Geburtsdatum – Datentyp time
• P:Geburtsort – Datentyp item

Dann:

• Q-Adelung — P:Geburtsdatum —► 1732-xx-xx (Literal-Zeitpunkt)
• Q-Adelung — P:Geburtsort —► Q-Spantekow (Item)

Alle Formulierungen („wurde 1732 in Spantekow geboren“ etc.) sind nur verschiedene Aussprache dieses Kerns.

Muster B: Ereignis-Modell (passt zu deiner Einheits-/Verfertiger-Idee)

• P:Ereignis – Datentyp item
• P:Zeitpunkt – Datentyp time
• P:Ort – Datentyp item
• Q:Geburt – Ereignisart
• Q:Geburt-Adelung – konkretes Geburtsereignis

Dann:

• Q-Adelung — P:Ereignis —► Q:Geburt-Adelung
• Q:Geburt-Adelung — P:Ereignisart —► Q:Geburt
• Q:Geburt-Adelung — P:Zeitpunkt —► 1732-xx-xx
• Q:Geburt-Adelung — P:Ort —► Q-Spantekow

Hier bleiben deine P’s universal, die Art (Geburt) steckt im Item Q:Geburt / Q:Geburt-Adelung, nicht in einem Spezial-Property.

Beide Muster sind konsistent mit deiner Zielrichtung:

• wenige klar definierte Properties,
• Art und Rolle (Geburt, Tod, Ort, Zeit) getragen durch Items + Datentypen,
• Werte als Items oder Literale, nicht als Properties.

---

5. Konkrete Antwort auf „Was sagst du nun?“

Kurz:

• Dein Test zeigt: Sobald du 1732 und Spantekow als Properties modellierst, entziehst du ihnen für Wikibase den Charakter von Datenwerten. Wikibase macht daraus konsequent „Adelung — geboren —► (Property 1732, Property Spantekow)“, gruppiert als Mehrfachwert – nicht als Geburtsdatum/-ort.
• Für das, was du inhaltlich willst („Adelung wurde 1732 in Spantekow geboren“), brauchst du:
  • entweder zwei Properties (Geburtsdatum, Geburtsort) mit passenden Datentypen,
  • oder das Ereignis-Modell mit einem Geburts-Item und universellen Properties wie Ereignis / Zeitpunkt / Ort.
• Deine übergeordnete Idee (P’s als Verfertiger, Werte als Einheiten, sprachliche Hüllen nur im Ausdruck) bleibt tragfähig – sie muss nur so implementiert werden, dass:
  • Werte wirklich Werte bleiben (Items/Literale),
  • und Properties keine Daten tragen, sondern Rollen.

Wenn du magst, können wir im nächsten Schritt die vier Entities aus deinem Test (Adelung, 1732, Spantekow, „Geburt“) einmal neu modellieren – in einer Variante A (flach) und einer Variante B (Ereignis) – und du kannst direkt an deinem Wikibase prüfen, welche dir im Arbeiten besser liegt.

Irren ist technisch

Du hast Recht, wenn du aus der Logik-SOP-Sicht von Wikibase schaust.

Du irrst dich, wenn du aus der Logik-Lesart eines Mensch schaust.

Als Mensch lese ich nicht programmatisch SOP sondern ich lese fast stenographisch  "Johann Christoph Adelung geboren 1732 Spantekow" und würde ich es vorlesen, so würde ich "Johann Christoph Adelung geboren am 1732 in Spantekow" oder "Johann Christoph Adelung ist 1732  in Spantekow geboren" sagen.

Für mich gibt es die Mißdeutungen nicht, vor denen du Bedenken hast.

Reflektieren über Datenmodellierung

Der Nutzer erwähnt, dass für sie keine Missverständnisse bei der menschlichen Lesart auftreten, was ich anerkennen sollte. Ich plane, zwischen der schlichten Darstellung für Menschen und der maschinenlesbaren Struktur zu differenzieren. Vielleicht könnten wir den Text in eine Lexeme oder eine Aussage übertragen, um die semantische Struktur klarer darzustellen.

Erklären der Modellierung

Es scheint, dass das Experiment des Nutzers eine Meta-Aussage über die Eigenschaften geschaffen hat, was unbedenklich ist, wenn man P14/P15 nicht als Daten behandelt. Allerdings kann man Geburtsdaten nicht leicht abfragen. Ich schlage vor, die menschliche Kurzform in Beschreibungen zu belassen und für die Struktur das Ereignismodell zu verwenden.

Antwort zum UI von Wikibase

Der Nutzer weist auf eine Schwachstelle der Wikibase-Oberfläche hin, bei der Aussagen visuell zusammengeführt werden. Ich stimme zu, dass durch die Visualisierung als Mehrwertwert die Trennung der Struktur erhalten bleibt. Ich könnte vorschlagen, die Geburtsdaten mit einem Hauptwert und Ort als Qualifikator zu modellieren, um die Lesbarkeit zu wahren.

Erläuterung zur Modellierung

Die Argumentation des Nutzers ist klar: Die Darstellung von Geburtsdaten als "1732 Spantekow" ist verständlich. Wir können dies als eine Aussage mit dem Wert "1732" und dem Qualifikator "Spantekow" umsetzen, um die Lesbarkeit zu bewahren und dabei die richtigen Datentypen zu verwenden, ohne die Eigenschaften als Werte darzustellen.

Nachgedacht für 23s

Fertig

Ich unterscheide hier zwei Ebenen, dann siehst du, wo ich „Recht“ meine und wo nicht:

• Ebenen 1 – Mensch liest: „Johann Christoph Adelung geboren 1732 Spantekow“ → völlig klar, du brauchst keine SOP-Brille. Da sind wir uns einig.
• Ebene 2 – Wikibase arbeitet: Wikibase kennt keine „stenographische“ Lesart, sondern nur: Subjekt – Property – Wert (+ Qualifizierer) Und genau da entsteht das Problem deines Tests.

Was dein Test tatsächlich gemacht hat

Du hast:

• Q11 – Johann Christoph Adelung
• P13 – geboren (Datentyp property)
• P14 – 1732 (Datentyp Zeitpunkt)
• P15 – Spantekow (Datentyp item)

Dann:

1. Q11 — P13 —► P14
2. Q11 — P13 —► P15

Die Oberfläche zeigt dir schön:

geboren: 1732 Spantekow

Du liest das richtig, menschlich:

„Adelung geboren 1732 Spantekow“.

Wikibase liest technisch:

• P13 ist ein Property, das als Wert andere Properties nimmt.
• P14 und P15 sind Properties – keine Werte wie „Jahr 1732“, kein Ortseintrag Spantekow.
• Es gibt nirgends ein Datum-Literal und nirgends ein Ort-Item.

Das System weiß also weder:

• welches Datum 1732 genau ist,
• noch dass Spantekow ein Ort ist.

Für dich ist das aus dem Label klar, für die Maschine nicht.

Wenn du später z. B. fragst:

• „Zeig mir alle, die vor 1800 geboren sind.“
• „Zeig mir alle in Spantekow geborenen Personen.“

dann findet Wikibase auf dieser Basis nichts, weil es keine auswertbaren Zeit- oder Ort-Werte hat – nur Meta-Verknüpfungen Property→Property.

Die „Missdeutung“, vor der ich warnte, ist also nicht eine menschliche beim Lesen,

sondern eine maschinelle beim Fragen und Auswerten.

Wie du deinen Satz mit deiner Lesart und ohne technischen Bruch modellieren kannst

Du willst im Kopf einen Block:

geboren: 1732 Spantekow

und technisch nur eine Haupt-Property „geboren“.

Das geht in Wikibase – aber mit anderen Datentypen als in deinem Test.

Variante: Ein Haupt-Prädikat „geboren“ + Qualifizierer

Richte ein:

• P13: geboren – Datentyp Zeitpunkt (time)
• P15: Geburtsort – Datentyp Item (dein Spantekow-Property – aber als „Ort“-Property gedacht)

Dann:

1. Aussage auf Q11:
   • Q11 — P13 (geboren) —► 1732-01-01 (oder 1732-00-00 mit Genauigkeit „Jahr“, je nach Einstellung)
2. Qualifizierer an dieser Aussage:
   • P15 (Geburtsort) —► Q-Spantekow

Die Oberfläche zeigt dir (je nach Skin und Sprache) etwas wie:

geboren: 1732 in Spantekow

Oder zumindest zwei Dinge direkt unter „geboren“ – genau deine stenographische Lesart.

Unterschied zu deinem Test:

• 1732 ist kein Property, sondern ein echter Zeitwert.
• Spantekow ist kein Property, sondern ein Item vom Typ Ort.
• Der Auswertungs-Teil von Wikibase kann:
  • nach Jahr/Zeitraum rechnen,
  • nach Ort/Region filtern.

Du bekommst also:

• menschlich: die gewünschte Kurzschreibweise („geboren 1732 Spantekow“)
• technisch: echte Daten, mit denen du später arbeiten kannst.

Wie das zu deiner „universellen P-Logik“ passt

Dein Grundansatz:

• Properties sind Verfertiger/Rollen,
• Q’s sind Einheiten,
• sprachliche Hüllen („ist“, „von“, „am“, „in“) entstehen erst beim Aussprechen.

Das obige Muster verletzt das nicht:

• P13 „geboren“ ist genau so ein Verfertiger.
• Der Wert ist ein Zeitpunkt (Einheit in der Zeitstruktur).
• Der Qualifizierer „Geburtsort“ koppelt das Ereignisattribut „Ort“ hinzu.

Wenn du später dein Ereignis-Modell einführen willst, kannst du aus derselben Struktur einen Schritt weitergehen (Geburt-Adelung als Ereignis-Einheit etc.) – aber du musst dafür nicht Properties zu Datenwerten machen.

Kurz gesagt

• Du liest deinen Test menschlich korrekt.
• Meine Einwände betreffen nicht deinen Lesesinn, sondern die Maschinenlesbarkeit der Datenstruktur, die du dir damit gebaut hast.
• Mit einer kleinen Verschiebung:
  • 1732 und Spantekow weg von der Property-Schicht,
  • hin zu echten Werten (Zeit, Item) + Qualifizierern, bekommst du:
  • dieselbe menschliche Lesbarkeit,
  • und zugleich eine technisch auswertbare Struktur.

Wenn du willst, setze das einmal genau so in deinem Wikibase um (P13=Zeit, P15=Ort als Qualifizierer) und schau, wie es in der Oberfläche aussieht – dann können wir an diesem konkreten Ergebnis weiterdenken, ob du zusätzlich das Geburtsereignis als eigene Einheit einführen willst oder ob dir diese Ebene schon genügt.

Zu den Einwänden

Damit ich deine Einwände verstehe, muß ich zuvor wissen, wie ich in meinem MediWiki Suchabfragen an Wikibase stelle.

Haben diese eine Abfrage-Syntax wie Semantic MediaWiki sie nutzt?

Wikibase hat keine eigene „Ask-Syntax“ wie Semantic MediaWiki

Kurz gesagt: Nein – Wikibase hat keine eigene „Ask-Syntax“ wie Semantic MediaWiki.

Du hast zwei Hauptwege:

1. SPARQL über einen Query-Service (z. B. deinen Fuseki)
2. MediaWiki/Wikibase-API (REST/Action-API)

Ich ordne das knapp, damit du ein Bild bekommst, wo deine Geburts-/Sprachdaten später überhaupt abfragbar sind.

1. Semantic MediaWiki vs. Wikibase – zwei völlig verschiedene Query-Welten

• Semantic MediaWiki – nutzt die {{#ask: … }}-Syntax in Wikitext – hat seine eigene semantische Abfragesprache (Klammern, Pipes, [[Attribut\:\:Wert]] usw.) – läuft innerhalb deines MediaWiki-Renderings.
• Wikibase – kennt keine SMW-Ask-Syntax. – Standard-Abfragesprache für strukturierte Daten: SPARQL (wie bei query.wikidata.org) – plus simple Such-/Lookup-Funktionen über die MediaWiki-API.

Deine Frage:

„Haben diese eine Abfrage-Syntax wie Semantic MediaWiki sie nutzt?“

Antwort:

Nein.

Wikibase selbst spricht SPARQL, nicht SMW-Ask.

---

2. Typische Wikibase-Abfragen (SPARQL)

In einem „klassischen“ Wikibase-Setup hast du:

• den RDF-Export deines Wikibase (Special:EntityData, RDF-Dump)
• einen SPARQL-Endpunkt (bei dir: Fuseki, den du schon eingerichtet hast)

Dort stellst du Abfragen in etwa so:

oder – in deinem späteren Ereignis-Modell:

Das ist die Ebene, auf der meine Bedenken zu deinem Test relevant werden:

• Wenn „1732“ und „Spantekow“ nur als Properties vorkommen, gibt es keine ?date-Zeitwerte und keine ?place-Items, nach denen SPARQL filtern könnte.

3. MediaWiki-/Wikibase-API (ohne SPARQL)

Zusätzlich gibt es die MediaWiki-Action-API, z. B.:

• wbgetentities – holt Entitäten (Q/P/L) und deren Statements
• wbsearchentities – Volltextsuche nach Labels/Aliases
• ggf. CirrusSearch/ElasticSearch – für textuelle Suche

Damit kannst du:

• nach „Adelung“ suchen,
• Q11 auslesen,
• dir alle Claims/Statements zu Q11 zurückgeben lassen.

Aber:

Auch hier gilt: die API sieht nur die offiziellen Statements:

Wenn P13 auf Properties zeigt (P14, P15), stehen dort nur Property-IDs – keine Datum-/Ortwerte.

4. Was das für deine Modell-Entscheidungen bedeutet

Solange es nur darum geht, dass du als Mensch „Johann Christoph Adelung geboren 1732 Spantekow“ lesen kannst, ist dein Experiment völlig in Ordnung.

Sobald du:

• zeitliche Abfragen machen willst („vor 1800“, „im 18. Jh.“, …)
• oder nach Orten filtern willst („in Spantekow geboren“),
• oder SPARQL-Abfragen bauen willst,

brauchst du:

• das Geburtsdatum als Zeitwert (Datentyp time)
• den Geburtsort als Item (Datentyp wikibase-item),

damit diese Werte überhaupt im SPARQL-Graph auftauchen.

Deine Lesart bleibt menschlich dieselbe.

Die Frage ist ausschließlich: Willst du mit diesen Daten auch maschinell rechnen und filtern können?

• Wenn nein (rein lesender, narrativer Gebrauch): könntest du vieles „stenographischer“ modellieren.
• Wenn ja (und du hattest ja bereits Interesse an Auswertungen, Graphen, Zeitachsen): dann musst du dich bei solchen Dingen wie Geburt/Tod/Ort bewusst an die Datentyp-Logik von Wikibase halten – egal wie elegant deine S–P–O-Lesart im Kopf funktioniert.

---

Wenn du möchtest, können wir als nächsten Schritt:

• eine sehr einfache SPARQL-Abfrage skizzieren,
• und sie so konstruieren, dass du daran siehst:
  • welche Modellierungsvariante (flach vs. Ereignis)
  • welche P-/Datentyp-Entscheidung deine gewünschten Auswertungen unterstützt.

Einwand zu Einwand

Aber ich habe doch angelegt:

das geboren mit Zusatzproperty 1732 als Datentyp time,

den begoren mit Zusatzproperty Spantekow als Datentyp item.

Es gibt das property "Geburtsdatum" nicht direkt, es wird indirekt durch geboren + Datum gebildet und auch das property Geburtsort ist nicht direkt vorhanden, wird durch geboren + Ort gebildet.

Gemäß meinem denken kann ich mittels SMW Suchabfragen zu einer Zweitspanne von 1700 bis 1800 erstellen , die dann eine Tabelle Geburtsnam-Geburtstag-Geburtsort mit den Daten erzeugt.

Überprüfen der Datentypen

Der Benutzer hat P13 als Hauptproperty verwendet und mit zwei Werten (P14 und P15) kombiniert – das passt, da P13 einen Property-Typ als Wert erwartet. P14 als "Zeitpunkt" und P15 als "Item" spielt beim Wertgebrauch keine Rolle, da nur der Hauptdatentyp zählt.

Klarstellung der Datentypen und Abfragen

Die Datentypen P14 und P15 sind als Zusatzproperties nicht relevant für den aktuellen Kontext, da sie keine konkreten Zeit- oder Platzwerte enthalten. Die Hauptproperty bestimmt die Art des Werts. Zudem können SMW-Abfragen keine Wikibase-Daten lesen; SPARQL wird dafür benötigt. Beide Systeme sind standardmäßig unabhängig.

Erklärung der Konzepte

Es gibt mehrere Punkte zu klären: (1) Datentypen von Properties und deren Werte in Statements unterscheiden sich; (2) "Geburtsdatum" entsteht aus der Kombination von Properties, ist aber maschinenlesbar nicht zugänglich; (3) SMW kann diese nicht direkt abfragen, es bräuchte eine Brücke oder eine Duplikation der Annotationen; (4) Lösung könnte sein, Qualifikatoren für Wikibase-Statements zu verwenden.

Erklärung der Qualifikatoren und Abfragen

In Wikibase ist eine Property wie "geboren" mit einem Zeitdatentyp möglich, und man kann Qualifikatoren wie "Geburtsort" verwenden. Die Idee, eine allgemeine Property plus Qualifikatoren für Zeit und Ort zu nutzen, ist konzeptionell brauchbar, aber für SPARQL komplexer. SMW kann das nicht direkt abfragen.

Nachgedacht für 37s

Fertig Gut, jetzt sind wir genau an der Stelle, wo sich dein Denkmodell und die Technik von Wikibase/SMW kreuzen. Ich trenne das einmal sauber:

1. Was du angelegt hast
2. Was Wikibase daraus tatsächlich macht
3. Warum SMW-Queries das nicht sehen
4. Wie du dein „indirektes Geburtsdatum/-ort“ so modellieren kannst, dass es auch abfragbar wird

1. Was du angelegt hast (aus deiner Sicht)

Dein Modell (aus deiner Beschreibung):

• Q11: Johann Christoph Adelung (Item)
• P13: geboren – Datentyp „property“
• P14: 1732 – Datentyp „time“
• P15: Spantekow – Datentyp „item“

Dann:

• Q11 mit Aussage: geboren + Zusatzproperty 1732 (time)
• Q11 mit Aussage: geboren + Zusatzproperty Spantekow (item)

Du liest das als:

„Adelung geboren 1732 Spantekow“ → implizit: Geburtsdatum = 1732, Geburtsort = Spantekow

Und du denkst:

„Geburtsdatum“ ist kein eigenes P,

sondern geboren + Datum

und

„Geburtsort“ = geboren + Ort.

In deinem Denksystem ist das klar.

---

2. Was Wikibase daraus tatsächlich macht

Entscheidend ist, was P13 für einen Datentyp hat:

P13 = geboren – Datentyp property

Das bedeutet für Wikibase:

• Ein Statement Q11 — P13 —► X erwartet als Wert ein Property-Objekt (P-irgendwas), nicht ein Datum, nicht ein Ort.

Wenn du dann sagst:

• Q11 — P13 —► P14
• Q11 — P13 —► P15

dann ist das für Wikibase:

• Adelung — geboren —► Property 1732
• Adelung — geboren —► Property Spantekow

Datentyp von P14 und P15 (time bzw. item) spielt hier keine Rolle – der Datentyp wirkt nur, wenn P14/P15 als Property im Statementkopf benutzt werden, nicht wenn sie selbst als Wert (Objekt) in einem anderen Statement auftauchen.

Das UI gruppiert diese zwei Statements, weil sie beide P13 haben, und zeigt:

geboren: 1732 Spantekow

Diese Anzeige ist rein oberflächlich – sie sagt dir nicht, dass intern irgendwelche Zeit- oder Ortswerte vorliegen. Intern sieht der RDF/Claim-Block nur:

• Werttyp: „wikibase-property“ (P14, P15)
• keine Zeit-Literal, kein Ort-Item.

Das ist der Punkt, wo meine Einwände greifen:

Maschine sieht nur: Person → geboren → zwei Properties.

Deine Bedeutung (Datum + Ort) steckt nur in den Labels, nicht in der Datenstruktur.

3. Warum SMW-Queries das nicht sehen

Zwei getrennte Ebenen:

1. Semantic MediaWiki (#ask)
   • SMW sieht nur das, was du als SMW-Attribute/Properties in Wikitext oder über seine eigene API annotierst.
   • Wikibase-Statements sind eine andere Welt; SMW liest sie nicht automatisch. Wenn du nichts extra verbindest, gilt:
   • [[Attribut:Geburtsdatum::1732]] (SMW) ist nicht dasselbe wie Q11 — P13 —► P14 (Wikibase). SMW-{{#ask: …}} kann nur SMW-Daten sehen, nicht deine Wikibase-Struktur.
2. Wikibase/SPARQL
   • Für zeitliche Abfragen wie „Zeige Personen mit Geburtsdatum zwischen 1700 und 1800“ braucht der SPARQL-Graph Zeitwerte oder Ereignis-Items mit Zeitwerten.
   • Bei deinem Modell gibt es aber keinen Zeitwert, nur Property-Objekte (P14, P15). Eine SPARQL-Abfrage wie: sieht nur ?value = P14, ?value = P15 – aber kein "1732-01-01"^^xsd:dateTime und kein wd:QSpantekow.

Fazit:

Dein Modell ist für dich semantisch klar,

aber für SMW und SPARQL sind es nur Verknüpfungen zwischen Properties, ohne abfragbares Datum/Ort.

4. Wie du dein „geboren + Datum/Ort“ so bauen kannst, dass es abfragbar wird

Deine Idee ist:

Es gibt kein direktes „Geburtsdatum“-Property, sondern „geboren + Datum“ erzeugt diese Bedeutung.

Das ist in Wikibase tatsächlich möglich – aber anders, als du es in deinem Test gemacht hast:

Variante A: „geboren“ als Haupt-Property + Qualifizierer

Konfiguration:

• P13: geboren – Datentyp time
• P16: Geburtsort – Datentyp item

Anwendung auf Q11:

1. Haupt-Statement:
   • Q11 — P13 (geboren) —► 1732-01-01 (oder „1732“ mit Genauigkeit „Jahr“)
2. Qualifizierer an diesem Statement:
   • P16 (Geburtsort) —► Q-Spantekow

Wikibase-UI zeigt das (je nach Skin) als Block „geboren: 1732 in Spantekow“ oder ähnlich – also genau deine Kurzform.

Für SPARQL:

Hier bekommst du genau deine Tabelle:

• Person – Geburtsdatum – Geburtsort

Wichtig:

1732 ist hier ein echter time-Wert, Spantekow ein echtes Item.

„Geburtsdatum“ und „Geburtsort“ existieren nicht als eigene Property-Namen in deiner Alltagssprache,

sie sind:

• P13 (geboren) → Datum
• P16 (Qualifier) → Ort.

Das entspricht deinem Gedanken „Geburtsdatum = geboren + Datum“ sehr gut, aber mit Datentypen, die SPARQL/SMW überhaupt verarbeiten kann.

Variante B: Ereignis-Modell (falls du noch universeller willst)

Wie schon skizziert:

• P:Ereignis – Datentyp item
• P:Zeitpunkt – Datentyp time
• P:Ort – Datentyp item
• Q:Geburt-Adelung – Item für das Geburtsereignis

Dann:

• Q-Adelung — P:Ereignis —► Q:Geburt-Adelung
• Q:Geburt-Adelung — P:Zeitpunkt —► 1732-xx-xx
• Q:Geburt-Adelung — P:Ort —► Q-Spantekow

Auch daraus kannst du per SPARQL eine Tabelle Person–Geburtsdatum–Geburtsort bauen.

Der Unterschied: „Geburt“ liegt als Ereigniseinheit vor, nicht nur als P.

5. Zurück zu deinem Satz:

„Gemäß meinem Denken kann ich mittels SMW Suchabfragen zu einer Zeitspanne von 1700 bis 1800 … die dann eine Tabelle Geburtsnam-Geburtstag-Geburtsort mit den Daten erzeugt.“

In deinem Denken: ja, weil du die Labels liest.

Technisch:

• SMW-{{#ask: …}} sieht dein Wikibase-Konstrukt gar nicht, solange du es nicht explizit in SMW-Properties spiegelst.
• SPARQL kann nur dann eine Zeitspanne 1700–1800 prüfen, wenn irgendwo ein Wert existiert, der tatsächlich als Zeit modelliert ist.

Das ist der Kern meiner Einwände:

Nicht, dass deine Lesart falsch wäre, sondern dass die Maschine sie so nicht erkennen und auswerten kann.

---

Wenn du willst, mache ich dir als nächsten Schritt eine konkrete SPARQL-Abfrage zu:

• Modell A: „geboren“ als Hauptproperty + Qualifier Geburtsort

Dann kannst du daran ganz praktisch sehen, dass du:

• deine menschliche Lesart („geboren 1732 Spantekow“) behältst
• und gleichzeitig eine sauber abfragbare Struktur bekommst.

Lua mir die SMW-Property aus Wikibase "baut"

Es scheitert gegenwärtig an Tripple – ich bräuchte an sich Wikibase-Quadruple, den ich an sich mittels Quaifizierer erlange  – oder?

Mit Tripple und Quadruple meine ich in diesem Zusammenhang lediglich, daß ich 3 Stellen habe aber 4 Stellen brauche, um eine auswertbare Abfrage machen zu können. Kann ich Qualifizier eigens abfragen?

Alternative um eine Verschränkung zu von Wikibase mit Wikidata zu erlangen, müßte ich also auf der Wikiseite von Adelung eine Vorlage haben, die mittels Lua mir die SMW-Property aus Wikibase "baut" – richtig?

Erklärung zu RDF und Wikibase-Integration

Du hast zwei Themen in einem:

1. Reicht ein Tripel, oder brauchst du faktisch ein „Quadruple“ → Qualifizierer-Frage
2. Wie kommst du von Wikibase-Daten zu SMW-Properties → Lua/Vorlage-Frage

Ich gehe beides nacheinander durch.

1. „Ich bräuchte an sich Wikibase-Quadruple … Kann ich Qualifizierer eigens abfragen?“

Ja, genau:

Was du als „Quadruple“ empfindest, ist in Wikibase/RDF ein Statement mit Qualifier:

• Basis-Tripel: Subjekt – Property – Wert
• plus zusätzliche (qualifizierende) Property-Werte, die an dieses Statement „angehängt“ sind.

Beispiel in deiner Logik:

• Hauptaussage: Adelung — geboren —► 1732 (P:geboren = time)
• Qualifizierer: Geburtsort —► Spantekow (Qualifizierer-Property, z. B. P:Geburtsort)

Technisch ist das in RDF/SPARQL so modelliert:

• Es gibt ein Statement-Objekt ?stmt:
• p: = Property-Namespace für Statements
• ps: = „main snak“ (Hauptwert)
• pq: = Qualifier

Antwort auf deine Frage:

„Kann ich Qualifizierer eigens abfragen?“

Ja.

In SPARQL gehst du immer über den „Statement-Knoten“ ?stmt:

Damit hast du faktisch dein „Quadruple“:

• Person
• Geburtsdatum
• Geburtsort
• (implizit: das Ereignis „geboren“-Statement als vierte Stelle)

Dein Gefühl „Tripel reicht nicht, ich brauche Quadruple“ ist berechtigt –

Wikibase löst das technisch durch Statement-Knoten + Qualifier, nicht durch nackte 4-Tupel.

SPARQL kann das sauber abfragen.

2. Verschränkung Wikibase ↔ SMW: Lua + Vorlage?

Deine Alternative:

„… müßte ich also auf der Wikiseite von Adelung eine Vorlage haben, die mittels Lua mir die SMW-Property aus Wikibase ‘baut’ – richtig?“

Ja, das ist der pragmatische Weg in deinem Setup.

Die Schritte:

1. Wikibase ist System A – Du modellierst dort sauber:
   • Q-Adelung — P_geboren → Datum (+ Qualifier Geburtsort)
   • ggf. weitere Properties.
2. Semantic MediaWiki ist System B – Du willst dort:
   • [[Geburtsdatum::1732]]
   • [[Geburtsort::Spantekow]] damit {{#ask: …}} funktioniert.
3. Verschränkungsschicht (deine Idee): – eine Vorlage, die per Lua:
   • aus der Wikibase-Entität (Q-Adelung) die Werte von P_geboren + Qualifier P_geburtsort ausliest
   • und daraus Wikitext mit SMW-Annotation erzeugt, z. B.: oder im einfachsten Fall:

Ja: genau das ist die Verschränkung, die du brauchst.

Ohne so einen Mechanismus bleiben:

• Wikibase-Daten nur in SPARQL/EntityData sichtbar
• SMW-Daten nur in #ask sichtbar

Mit so einer Lua/Vorlagen-Schicht kannst du:

• in Wikibase pflegen (einmal saubere Modellierung)
• in SMW darauf abfragen.

Kurzfassung

1. Dein Gefühl „Tripel reicht nicht, ich brauche Quadruple“ → in Wikibase heißt das: Statement + Qualifier. → Ja, du kannst Qualifier in SPARQL explizit abfragen.
2. Verschränkung Wikibase ↔ SMW → geht nicht automatisch. → Deine Idee mit Vorlage + Lua, die aus Wikibase-Statements SMW-Properties „baut“, ist der richtige Weg.

Wenn du möchtest, können wir als nächsten Schritt ganz konkret skizzieren:

• eine kleine Lua-Funktion, die für ein übergebenes Q (z. B. Q11) – P_geboren (Datum) – Qualifier P_geburtsort ausliest – und diese als [[Geburtsdatum::…]] / [[Geburtsort::…]] in den Seiteninhalt schreibt.

Überdenke bitte erneut

Zwischenfrage Datenabfrage

Zwischenfragen:

1. Wie Frage ich zu Adelung die Daten eines Statement ab, um mir auf einer Wikiseite anzeigen zu lassen, was in Wikibase als Daten zu Adelung erfasst wurde?

2. Kann im Grunde vergleichsweise mittels \[\[Geburtstag\:\:#invoke:…|Token=Q11}}]] zur Verschränkung von Wikibase mit SMW erstellen?Ein solches Modul „…“ ist nicht vorhanden. zur Verschränkung von Wikibase mit SMW erstellen?

Erklären der Abfrage von Wikibase-Daten

Antwort auf die Frage zur Adelung in Wikibase

Um Daten zu Adelung für das Element Q11 auf einer MW-Seite anzuzeigen, können verschiedene Ansätze verwendet werden:

1. Per Lua mit Scribunto und den Wikibase-Client-Funktionen (bei einem Wikibase-Repositorium). Beim gleichen Wiki mit Wikibase-Repo könnte man mw.wikibase.getEntity('Q11') in einem Modul oder wb.getEntityObject verwenden, um die Daten abzurufen.

Antwort zur Anzeige von Wikibase-Daten

Wenn der Wikibase-Client aktiviert ist, gibt es eine schnelle Möglichkeit, eine Eigenschaft mit der Parser-Funktion \{\{#statements:P13|from=Q11}} anzuzeigen. Um jedoch alle Aussagen zu einem Element wie Q11 zu erhalten, benötigt man Lua. Hier kann mit mw.wikibase.getEntityObject('Q11') gearbeitet werden.

Antwort zur Verschränkung von Wikibase mit SMW

Ja, grundsätzlich kann der Ansatz so funktionieren: Mit \{\{#invoke:...|Token=Q11}} wird das Geburtsdatum aus dem Wikibase-Element Q11 abgerufen und dann in eine SMW-Eigenschaft eingebettet. Dabei ist jedoch Vorsicht geboten: SMW scannt die Seite nach der Lua-Erweiterung, was zur richtigen Verwendung der Werte führt.

Beispiel für ein minimales Lua-Skript

Ich schlage vor, einen einfachen Lua-Code zu verwenden:

local p = {}

function p.geburtstag(frame)
  local qid = frame.args.qid or frame.args[1]
  local entity = mw.wikibase.getEntityObject(qid)
  if not entity then return '' end
  local claims = entity.claims or entity.statements -- abhängig von der Version
  return claims['P569'] or ''
end

Das Skript ist robust, aber nicht zu kompliziert, um die Geburtsdaten aus Wikibase abzurufen.

Beispiel für das Lua-Skript und SMW-Anwendung

Hier ist ein einfaches Lua-Skript, das den Geburtstag eines Wikibase-Elements ausliest und in eine SMW-Eigenschaft einfügt:

local p = {}

local function firstTimeValue(entity, pid)
  local claims = entity and entity.claims and entity.claims[pid]
  if not claims or #claims == 0 then return nil end
  local mainsnak = claims[1].mainsnak
  if mainsnak.snaktype = 'value' then return nil end
  local datavalue = mainsnak.datavalue
  if not datavalue or datavalue.type = 'time' then return nil end
  local time = datavalue.value.time
  return mw.ustring.sub(time, 2, 5)
end

function p.geburtstag(frame)
  local qid = frame.args

Nachgedacht für 30s

Fertig

Gute Zwischenfragen, die klären, wo die eigentliche Hürde sitzt. Ich beantworte sie getrennt.

1. „Wie frage ich zu Adelung die Daten eines Statement ab,

"um mir auf einer Wikiseite anzeigen zu lassen, was in Wikibase als Daten zu Adelung erfasst wurde?“

Es gibt in deinem Setup im Grunde zwei praktische Wege:

a) Wikibase-Parserfunktionen (ohne Lua)

Wenn dein Wiki sowohl Repo als auch Client ist (Mutmaßung, aber bei dir sehr wahrscheinlich), hast du i. d. R. die Parserfunktionen aus WikibaseClient zur Verfügung, z. B.:

• Einzelwert eines Properties:

{{#property:P13|from=Q11}}

Das gibt dir den (besten) Wert von Property P13 für Q11 zurück, also z. B. das Geburtsdatum, wenn P13 bei dir „geboren“ = Datentyp time ist.

• Alle Statements eines Property (inkl. Qualifier) – je nach Version:

  {{#statements:P13|from=Q11}}
  

Das ist eher etwas „roh“, aber du siehst daran, was zu P13 an Werten/Qualifizierern herumhängt.

Fakt: Diese Parserfunktionen sind auf Repo+Client-Konfigurationen ausgelegt; auf reinen Repos sind sie nicht immer aktiv.

Mutmaßung: In deinem Setup dürften sie verfügbar sein, weil du schon mehrfach von Repo+Client auf derselben Instanz gesprochen hast.

b) Lua (mw.wikibase) – volle Kontrolle

Für alles, was über „zeige mir einen Wert“ hinausgeht, ist Lua sinnvoller, z. B. in Modul:WbTest:

local p = {}

function p.dump(frame)
    local qid = frame.args.qid or frame.args[1] or 'Q11'
    local entity = mw.wikibase.getEntityObject(qid)
    if not entity then
        return 'Keine Entity für ' .. qid
    end
    -- Roh-Dump zur Kontrolle:
    return '<pre>' .. mw.text.jsonEncode(entity, true) .. '</pre>'
end

return p

In einer Wikiseite:

Dann siehst du alles, was Wikibase zu Q11 gespeichert hat (Claims, Qualifier, Datentypen).

Von dort kannst du dich dann langsam „herunterarbeiten“ zu gezielten Funktionen wie „gib mir das erste time-Statement für P13“.

2. „Kann ich mittels [[Geburtstag\:\:{{#invoke:…|Token=Q11}}]] eine Verschränkung von Wikibase mit SMW herstellen?“

Ja. Genau das ist die richtige Idee.

Prinzip:

1. Du schreibst ein Lua-Modul, das aus einem Q-Item den benötigten Wert aus Wikibase holt.
2. Du rufst dieses Modul im Wikitext auf.
3. Du packst den Rückgabewert in eine SMW-Annotation [[Attribut\:\:…]].

Minimalbeispiel: Geburtstag aus Wikibase in SMW

Angenommen, du willst für Q11 das „Geburtsdatum“ holen.

Du hast z. B. in Wikibase:

• P13 = „geboren“ – Datentyp time
• Q11 — P13 —► +1732-01-01T00:00:00Z (oder ähnlich)

Modul: Modul:Wb2Smw

local p = {}

local function firstTimeValue(entity, pid)
    if not entity or not entity.claims or not entity.claims[pid] then
        return nil
    end
    local claims = entity.claims[pid]
    if #claims == 0 then
        return nil
    end
    local snak = claims[1].mainsnak
    if not snak or snak.snaktype ~= 'value' then
        return nil
    end
    local dv = snak.datavalue
    if not dv or dv.type ~= 'time' then
        return nil
    end
    local time = dv.value.time  -- z.B. "+1732-01-01T00:00:00Z"
    -- Nur Jahr extrahieren:
    return mw.ustring.sub(time, 2, 5)  -- "1732"
end

function p.geburtstag(frame)
    local qid = frame.args.qid or frame.args[1] or frame:getParent().args.qid
    if not qid or qid == '' then
        return ''
    end
    local entity = mw.wikibase.getEntityObject(qid)
    local year = firstTimeValue(entity, 'P13')  -- P13 = "geboren"
    return year or ''
end

return p

Auf der Personen-Seite (Wikiseite „Johann Christoph Adelung“):

[[Geburtstag\:\:{{#invoke:Wb2Smw|geburtstag|qid=Q11}}]]

Ablauf:

• MediaWiki ruft das Modul auf, holt aus Wikibase den Wert für P13 bei Q11, extrahiert z. B. „1732“.
• Der Wikitext, den SMW am Ende sieht, ist faktisch:

  [[Geburtstag\:\:1732]]
  

SMW verarbeitet das ganz normal, als wäre es manuell eingetragen.

Damit hast du genau die Verschränkung, von der du sprichst:

• Datenquelle = Wikibase
• SMW-Property = „Geburtstag“
• Verbindung = #invoke + Lua

Analog kannst du:

• einen zweiten Lua-Aufruf für den Geburtsort bauen (P:Geburtsort oder Qualifier an „geboren“),
• für Todesdatum/-ort, Sprachdaten usw.

Kurzantwort auf deine beiden Fragen

1. Anzeige der zu Adelung erfassten Daten – Ja, entweder mit Wikibase-Parserfunktionen ({\{#property:…}}, {\{#statements:…}}) oder vollständiger mit Lua (mw.wikibase.getEntityObject und ggf. JSON-Dump).
2. [[Geburtstag\:\:{{#invoke:…|Q11}}]] als Verschränkung – Ja, das ist ein sinnvoller Ansatz: Lua holt aus Wikibase den Wert, [[…::…]] übergibt ihn an SMW. Technisch wichtig ist nur, dass die Lua-Funktion nur einen „nackten“ Wert zurückgibt (z. B. „1732“), keine zusätzliche Wiki-Syntax.

Wenn du möchtest, können wir als nächstes konkret den Geburtsort genauso modellieren (inklusive Zugriff auf einen Qualifier in Lua), damit dein Triple „Name – Geburtstag – Geburtsort“ sowohl in Wikibase als auch in SMW auswertbar wird.