Gespräch:Über Wikibase Erweiterungen WikibaseQualityConstraints und PropertySuggester

Über diese Seite Gespräch

PropertySuggester Nutzung erklären
ChatGPT Sophos GPT-5 ThinkingChatGPT Sophos GPT-5 Thinking
2. November 2025 n. Chr. erst.  
8:16 Uhr Ausgabe 01
Ausgabe 01
unüberarbeitet ungeprüft
2025110401 Über Wikibase Erweiterungen WikibaseQualityConstraints und PropertySuggester

Hallo Sophos,

Wir haben Wikibase installiert und arbeiten daran Scripts zur Erstellung von Lexemen und tems zu entwickeln. Ich bin auf Extension:PropertySuggester gestoßen und habe es zum Test instaliert, finde jedoch keine Angaben zu dessen Nutzng. Recherchiere bitte dazu was Extension:PropertySuggester kann und wie man diese nutzt.

ChatGPT:

Hallo Nikolaos — ( 2. Nov. 2025, … )

Danke für die Frage. Ich habe mir die Extension:PropertySuggester-Erweiterung für Wikibase angeschaut und fasse im Folgenden zusammen, was sie kann, wie sie genutzt wird, sowie wichtige Hinweise und typische Stolperfallen, damit Du entscheiden kannst, ob und wie sie in Deinem Setup sinnvoll ist.

Was macht PropertySuggester

Kurz gefasst: Die Erweiterung schlägt beim Bearbeiten eines Wikibase-Items passende Eigenschaften („Properties“) vor, um Aussagen zu ergänzen. mediawiki.org+2addshore+2

Details:

• Wenn ein Nutzer ein Item bearbeitet und z. B. schon eine oder mehrere Aussagen hinzugefügt hat, schaut PropertySuggester nach, welche Eigenschaften bei ähnlichen Items häufig vorkommen, und zeigt Vorschläge an. addshore+1
• Das Ziel: Daten-Erfassung vereinfachen, Konsistenz fördern (weil häufig genutzte Eigenschaften empfohlen werden) und somit die Qualität erhöhen. Professional Wiki+1
• Technisch: Es gibt eine Datenbank­tabelle (z. B. wbs_propertypairs), in der Assoziationsregeln zwischen Eigenschaften gespeichert sind (z. B. „Wenn Eigenschaft X vorhanden ist, dann wird oft Eigenschaft Y hinzugefügt“). GitHub+1
• Es gibt Konfigurations-Optionen, etwa welche Mindest-Wahrscheinlichkeit („MinProbability“) eine Vorschlagseigenschaft haben muss, welche Eigenschaften ausgeschlossen werden sollen (z. B. veraltet) etc. GitHub+1

---

Wie nutzt man PropertySuggester – Schritt für Schritt

Damit die Erweiterung funktioniert, sind einige Schritte erforderlich:

1. Installation

• Die Erweiterung in den Erweiterungsordner von MediaWiki kopieren (z. B. extensions/PropertySuggester). mediawiki.org+1
• In der LocalSettings.php aktivieren mittels: mediawiki.org+1
• Danach ein Update-Script laufen lassen, damit die Datenbanktabelle (wbs_propertypairs) angelegt wird. GitHub+1

2. Daten vorbereiten

• Die Vorschläge basieren auf Datenmuster-Analysen (z. B. Dump von Wikidata oder eigener Datenbasis) und müssen einmalig vorbereitet werden. In der offiziellen Anleitung ist z. B. ein Python-Skript enthalten („PropertySuggester-Python“), das aus einem Dump eine CSV erstellt, und dann ein PHP-Maintenance-Script lädt diese CSV in die Datenbank. GitHub
• In einer Eigeninstallation mit eigenen Items / Eigenschaften musst Du also überlegen, ob Du eigene Analyse-Daten generierst (z. B. basierend auf Deiner Datenbasis) oder die Standard-Logik verwendest (z. B. wenn viele Items bereits vorhanden sind).

3. Konfiguration

In LocalSettings.php bzw. im passenden Konfigurations­block kannst Du u. a. folgende Einstellungen vornehmen:

• $wgPropertySuggesterMinProbability — Mindestwahrscheinlichkeit für einen Vorschlag. GitHub+1
• $wgPropertySuggesterDeprecatedIds — Liste von Eigenschafts-IDs, die nicht für Vorschläge berücksichtigt werden sollen (z. B. veraltete Eigenschaften). GitHub+1
• $wgPropertySuggesterInitialSuggestions — Liste von Eigenschafts-IDs, die vorgeschlagen werden, wenn noch keine Aussagen vorhanden sind. GitHub
• $wgPropertySuggesterDefaultSuggester — Wahl des Standards. GitHub
• $wgPropertySuggesterSchemaTreeUrl — Wenn man den alternativen „SchemaTree“-Suggester einsetzt (siehe nachfolgend) dann URL zum Endpunkt. GitHub+1
• $wgPropertySuggesterTestingRatio und $wgPropertySuggesterABTestingState — Wenn A/B-Tests verschiedener Suggestion-Mechanismen genutzt werden sollen. GitHub

4. Nutzung durch Editor*innen

• Wenn ein Nutzer ein Item bearbeitet und z. B. bereits eine Eigenschaft hinzugefügt hat oder das Item eine bestimmte Struktur aufweist, erscheinen im Bearbeitungs­interface (z. B. im Abschnitt „Aussagen hinzufügen“) Vorschläge für weitere Eigenschaften.
• Diese Vorschläge können dann ausgewählt werden, was den Workflow erleichtern kann und Inkonsistenzen reduziert.
• Wichtig: Falls noch keine Aussagen vorhanden sind (z. B. beim Neuanlegen eines Items), wirken initiale Vorschläge (InitialSuggestions) oder ggf. gar keine Vorschläge.

Hinweise, Besonderheiten & mögliche Stolperfallen

Da Du mit Skripten zur Erstellung von Lexemen und Items arbeitest, sind folgende Punkte besonders relevant:

• Datenbasis ist entscheidend: Wenn Deine Wikibase-Instanz relativ klein oder stark spezialisiert ist (z. B. wenige Items oder sehr domänenspezifische Eigenschaften), dann kann die Standard‐Analyselogik aus einer großen Wikidata-Dump­basis weniger gut passen. Es könnte sein, dass Vorschläge wenig sinnvoll sind oder kaum erscheinen. In diesem Fall lohnt sich eine Anpassung der Analyse bzw. Verwendung eigener Statistiken.
• Qualität der Vorschläge: Studien zeigen, dass alternative Verfahren (z. B. der „SchemaTree Recommender“) in manchen Fällen bessere Vorschläge liefern als der klassische PropertySuggester. cochez.nl+1 Wenn also hohe Genauigkeit oder Domänenspezialisierung Pflicht ist, muss ggf. nachjustiert werden.
• Konfiguration und Ausschlüsse: Manche Eigenschaften sollten ggf. gar nicht vorgeschlagen werden (z. B. interne Stati, veraltete, sehr domänenspezifische). Hier hilft die Konfiguration von DeprecatedIds.
• Performance / Wartung: Da eine Analyse‐Tabelle aufgebaut werden muss und sich Vorschlagslogik mit fortschreitender Datenmenge verändern kann, sollte man prüfen, wie oft man die Analyse-Basis aktualisiert.
• Integration mit Lexemen: Falls Deine Instanz auch die Erweiterung WikibaseLexeme nutzt, solltest prüfen, ob PropertySuggester auch für Lexeme funktioniert oder ob spezifische Anpassungen nötig sind (z. B. Vorschläge für Formen, Bedeutungen etc.). Ich habe keine eindeutige Aussage gefunden, dass Lexeme automatisch voll unterstützt werden — hier wäre ggf. ein Test angebracht.
• Fallback-Situation: Wenn für ein Item keine oder wenig Daten vorhanden sind (z. B. noch keine Aussagen oder Typ/Instanz fehlt), dann können Vorschläge gar nicht oder nur wenig sinnvoll angezeigt werden. Hier kann man mit InitialSuggestions eingreifen und z. B. eine Standardliste von Eigenschaften definieren, die allgemein sinnvoll sind.
• Nutzerinteraktion und UI: Prüfe, wie die Vorschläge im UI erscheinen — evtl. müssen gewisse Template- oder Interface-Anpassungen gemacht werden (z. B. CSS/JavaScript) damit es ergonomisch ist.

Empfehlung für Dein Setup

Da Du schreibst, dass Ihr Skripte zur Erstellung von Lexemen und Items entwickelt — also vermutlich eine strukturierte Daten-Erfassung mit eigener Methodik — empfehle ich folgendes Vorgehen:

1. Testlauf in einer Staging-Instanz: Führe PropertySuggester zunächst in einer Testinstanz ein mit einiger Menge an Items und Eigenschaften, damit Du sehen kannst, ob die Vorschläge sinnvoll sind und den Workflow unterstützen.
2. Analyse der bestehenden Daten: Schau, wie viele Items bereits bestehen, wie stark standardisiert die Eigenschaften genutzt sind (z. B. Wiederholungen, typische Eigenschaftssets). Wenn die Daten sehr homogen sind, dann passen die Vorschläge eher gut.
3. Eigene Suggestion-Basis überlegen: Falls Ihr stark domänenspezifisch arbeitet (z. B. eine Forschungs-Domäne, Lexeme etc.), könnte es sinnvoll sein, eine eigene Analyse zur Generierung der wbs_propertypairs durchzuführen (z. B. mit dem Python-Skript aus dem Repo) statt sich nur auf generische Datenmuster zu verlassen.
4. Konfiguration anpassen: Setze z. B. MinProbability je nach Qualität der Vorschläge hoch genug, damit nur sinnvolle Vorgeschläge erscheinen. Schließe unnötige Eigenschaften via DeprecatedIds.
5. Integration mit Lexemen prüfen: Kontrolliere bei Lexeme-Bearbeitung, ob das Suggestion-UI dort angezeigt wird und ob die vorgeschlagenen Eigenschaften sinnvoll sind (z. B. Eigenschaften, die Lexeme betreffen). Falls nicht, ggf. zusätzliche Anpassungen oder ein separates Suggestion-Modul.
6. Monitoring und Feedback: Ermögliche Usern Feedback zu den Vorschlägen (z. B. ob Vorschläge hilfreich waren) und beobachte, ob die Vorschläge tatsächlich genutzt werden. Falls nicht, kann das ein Hinweis auf mangelnde Datenbasis oder falsche Konfiguration sein.

---

Wenn Du möchtest, kann ich eine kurze deutsche Step-by-Step Anleitung zusammenstellen, zugeschnitten auf eine Wikibase-Instanz mit Lexemen + Items inkl. Beispiel-Konfiguration (z. B. LocalSettings.php-Auszüge) — willst Du das?

Du:

Meine Fragen dienen der Klärung ob wir uns eigenes Coding mittels der Extension:PropertySuggester und Extension:WikibaseQualityConstraints ersparen können.

An sich interessiert mich nur, ob und wie ich mit Extension:PropertySuggester mein Muster (nicht echtes E-Schema) zur Anlage von Lexemen vorgeben kann, vergleichsweise mir dies für das Feld Property/Eigenschaft einer Aussage (statement) mir eine Auswahl für vergleichsweise der Sprachstufen von Gemeindeutsch bis Indogermanisch anbieten kann. Wenn dem so ist, dann brauchen wir das Script für die Anlage von Lexeme nicht so umfangreich entwickeln, können uns einiges dann ersparen.

Vergleichsweise stelle ich mir vor, daß mir ein PropertySuggester passende Properties anbietet oder zur Auswahl zuläßt, die man üblicherweise bei einem Substantiv anlegt.

Andere Funktionen für vergleichsweise Mindestangaben könnte Extension:WikibaseQualityConstraints erfüllen, auch wenn dies lediglich Prüfungen und Hinweise sind. Auch dwer Funbktionsumfang von Extension:WikibaseQualityConstraints müßten wir bei eigenen Scripts eigens entwickeln.

ChatGPT:

Hallo Nikolaos — (2. Nov. 2025, 13:38)

Kurzfassung (entscheidungsrelevant):

• #1 PropertySuggester schlägt beim Bearbeiten von Items passende Properties vor. Er definiert keine Schemas, erzwingt nichts und ist nicht für Lexeme-Masken gedacht. Für Lexeme gibt es sogar ein offenes Ticket „Property suggester on Lexemes“ – also keine verlässliche Lexeme-Unterstützung. mediawiki.org+1
• #2 WikibaseQualityConstraints prüft von Dir auf Properties definierte Constraints (z. B. Typ, Werttyp, Pflicht-Qualifier, One-Of, Label-Sprache, Lexeme-Sprache usw.). Die Checks sind informativ (Warnhinweise), keine Blockade/Erzwingung. Lexeme/Sense/Form werden abgedeckt. mediawiki.org
• #3 Kompatibilität: Die aktuelle PropertySuggester-Seite nennt MediaWiki ≥ 1.45. Du nutzt 1.44.2 → Version prüfen, sonst Inkonsistenzen/Fehler möglich. mediawiki.org

Was heißt das für Dein Ziel („Muster/Schema“ & Sprachstufen)?

Kann PropertySuggester Dir beim Lexem-Anlegen ein Muster „vorgeben“?

• Nein. Er bietet (nur) Property-Vorschläge im Item-Statement-UI auf Basis häufig gemeinsam genutzter Properties. Keine Formular-Vorgaben, keine Pflichtfelder, keine Wertlisten oder Hierarchien wie „Gemeindeutsch → … → Indogermanisch“. mediawiki.org

Kann PropertySuggester beim Wert helfen (z. B. Sprachstufen-Auswahl)?

• Nur sehr eingeschränkt. Der Suggester richtet sich auf Properties, nicht auf Values. Das UI hat zwar allgemeine Selector/Suggester-Mechanismen (Tippen → Trefferliste), aber kein domänenspezifisches Stufen-Menü. Die Werte-Auswahl bleibt Suche/Autovervollständigung gegen Deine Entitäten. wikidata.org

Kann QualityConstraints Deine Mindestangaben absichern?

• Ja, als Hinweise. Du modellierst die Regeln als Statements auf Properties (Property-Constraints). Beispiele:
  • Type/Value type/Allowed entity types – z. B. „diese Property nur auf Lexemen/Senses/Forms“
  • Mandatory qualifier / One-of / Distinct values / Label-in-language / Lexeme-language etc.
  • Ergebnis: Warnbanner am Statement + Spezialberichte, optional Job-gestützt. Nicht blockierend. mediawiki.org+1

Pragmatiker-Fazit (Aufwand sparen vs. Eigen-Coding)

• Was Ihr Euch sparen könnt:
  • Heuristische Property-Vorschläge für Items (nicht Lexeme) → weniger eigene „Vorschlagslogik“ bauen. mediawiki.org
  • Qualitätsprüfungen als Regelwerk auf Properties statt eigene Prüfscripte (Typ, Pflicht-Qualifier, One-Of, Label-Sprache, Lexeme-Sprache, …) → Hinweise im UI & Reports ohne eigenes Validierungs-Framework. mediawiki.org
• Wofür Ihr weiter eigenes Script/Workflow braucht:
  • Lexeme-„Muster/Blueprints“ (z. B. Standardfelder, Pflichtteile, voreingestellte Sprachstufen, qualifizierte Aussagen beim Anlegen). Weder PropertySuggester noch QualityConstraints erstellen Dir Eingabemasken, Defaults oder Assistenten.
  • Har­te Erzwingung (Blocking) von Mindestangaben/Sequenzen beim Speichern. QualityConstraints liefert nur Hinweise, kein Stopp. mediawiki.org
• Technische Randbedingungen:
  • Prüfe MW/Wikibase-Versionen: PropertySuggester fordert offiziell MW ≥ 1.45. Unter 1.44.2 ist das riskant. mediawiki.org

Minimal-Empfehlung (wenn Ihr maximal Nutzen, minimal Code wollt)

1. QualityConstraints konsequent nutzen
   • Definiere auf Euren Properties: Type/Value type, Allowed entity types(Item/Property/Lexeme/Sense/Form), Mandatory qualifier, One-Of, Label-in-language, Lexeme-language, Property scope etc. → sofortige Hinweise im UI und Berichte. mediawiki.org
2. PropertySuggester nur für Items einplanen
   • Bringt Editors Komfort bei Item-Statements; für Lexeme nicht einplanen (Ticket offen). Version zuvor abklären (1.45+). phabricator.wikimedia.org+1
3. Lexeme-Blueprints weiter skripten
   • Für Euer „Lexem-Muster“ (inkl. Auswahl Sprachstufe Gemeindeutsch → Indogermanisch) braucht Ihr eigene Erfassungslogik: z. B. Spezialseite/QuickStatements-ähnliches Script/Formular, das beim Anlegen vorgegebene Statements/Qualifier setzt. (PropertySuggester/Constraints liefern dafür keine Masken/Defaults.)

Wenn Du willst, skizziere ich Dir als Nächstes ein leichtgewichtiges Lexem-Anlege-Script (API-basiert) inkl.:

• konfigurierbarer Sprachstufen-Auswahl (Euer Hierarchie-Baum als Items),
• Pflichtteile (z. B. Lemma, Sprache, POS, initiale Statements),
• optionaler Constraint-Self-Check nach dem Anlegen (API-Call zu wbcheckconstraints). GitHub

Unklarheit geprüft: Es gibt keine belastbare Doku, dass PropertySuggester Lexeme unterstützt; das gegenteilige Phabricator-Ticket bestätigt die Lücke. QualityConstraints zeigt in der offiziellen Doku explizite Lexeme/Sense/Form-Parameter, daher Ja für Lexeme-Checks, aber „soft“. phabricator.wikimedia.org+1

Möchtest Du die Blueprint-Skizze (API-Flows + minimaler Code) jetzt?

Du:

Meine Fragen dienen der Klärung ob wir uns eigenes Coding mittels der Extension:PropertySuggester und Extension:WikibaseQualityConstraints ersparen können.

An sich interessiert mich nur, ob und wie ich mit Extension:PropertySuggester mein Muster (nicht echtes E-Schema) zur Anlage von Lexemen vorgeben kann, vergleichsweise mir dies für das Feld Property/Eigenschaft einer Aussage (statement) mir eine Auswahl für vergleichsweise der Sprachstufen von Gemeindeutsch bis Indogermanisch anbieten kann. Wenn dem so ist, dann brauchen wir das Script für die Anlage von Lexeme nicht so umfangreich entwickeln, können uns einiges dann ersparen.

Vergleichsweise stelle ich mir vor, daß mir ein PropertySuggester passende Properties anbietet oder zur Auswahl zuläßt, die man üblicherweise bei einem Substantiv anlegt.

Andere Funktionen für vergleichsweise Mindestangaben könnte Extension:WikibaseQualityConstraints erfüllen, auch wenn dies lediglich Prüfungen und Hinweise sind. Auch dwer Funktionsumfang von Extension:WikibaseQualityConstraints müßten wir bei eigenen Scripts eigens entwickeln.

ChatGPT:

Gern. Verstanden: maximaler Nutzen, minimal eigenes Coding — und das Lexem-Anlege-Script behandeln wir im anderen Chat.

Wenn PropertySuggester und WikibaseQualityConstraints jetzt in passenden 1.44.2-Kompatibilitätsständen laufen, bist du für Items gut aufgestellt. Für alles Weitere springen wir in den bestehenden Threads weiter.

ChatGPT kann Fehler machen. Überprüfe wichtige Informationen. Siehe Cookie-Voreinstellungen.