Über diese Seite Gespräch

SMW Namensraum anzeigen
ChatGPT Sophos GPT-5.2 Thinking
25. November 2025 n. Chr. erst.
14:20 Uhr Ausgabe 03
Ausgabe 03
unüberarbeitet ungeprüft

Hallo Sophos,

wie kann ich mir im SMW-Bereich Konzept alle Seiten eines Namensraum anzeigen lassen, obwohl den jeweiligen Seiten keine Kategorie zugewiesen ist und diese auch keine SMW-Annotationen haben.

Ich will eine Seite aller Q's mit derem Label anlegen, damit ich nicht immer über Spezial:Alle_Seiten… gehen und erst auswählen muß, was ich angezeigt bekommen will.

ChatGPT:

(25. Nov. 2025, 14:20)

Hallo Nikolaos,

du hast drei praktikable Wege – je nach Ziel „nur auflisten“ vs. „im SMW-Konzept wiederverwendbar“:

1) Direkt als SMW-Konzept (wiederverwendbar in #ask)

Voraussetzung: Der Namensraum deiner Q-Seiten (meist „Item“) ist für SMW aktiviert; sonst sieht SMW diese Seiten nicht. ($smwgNamespacesWithSemanticLinks[NS_ITEM] = true;), danach Store neu befüllen. semantic-mediawiki.org

Konzeptseite anlegen, z. B. „Konzept:Alle_Q“:

{{#concept:
 [[Item:+]]
 | Alle Wikibase-Items (Q) – Auswahl per Namensraum-Restriktion.
}}

Hinweis: „Item“ ggf. an deinen lokalen Namensraumpräfix anpassen (z. B. „Q“/eigener Name). Die SMW-Namensraumrestriktion [[Namespace:+]] wählt alle Seiten eines Namensraums – auch ohne Kategorien/SMW-Properties. semantic-mediawiki.org Liste anzeigen (auf beliebiger Seite):

{{#ask:
 [[Konzept:Alle_Q]]
 |format=template
 |template=Q-Zeile
 |mainlabel=-
 |limit=1000
}}

Bei großen Mengen ggf. limit/offset paginieren oder SMW-Grenzen anpassen ($smwgQMaxInlineLimit, $smwgQMaxLimit). semantic-mediawiki.org+2semantic-mediawiki.org+2 Template „Vorlage:Q-Zeile“ (eine Zeile pro Treffer):

* {{#invoke:WikibaseUtil|linkLabel|{{{1|}}}}}

Modul „Modul:WikibaseUtil“ (Label zum Link holen; fällt auf ID/Titel zurück):

local p = {}

function p.linkLabel(frame)
  local page = frame.args[1] or ''
  if page == '' then return '' end
  local id = mw.wikibase.getEntityIdForTitle(page) or page:match('Q%d+')
  local label = id and (mw.wikibase.getLabel(id) or mw.wikibase.getLabelByLang(id, 'de')) or nil
  local text = label or (id or page)
  return string.format('[[%s|%s]]', page, text)
end

return p

Lua-Funktionen: mw.wikibase.getEntityIdForTitle, mw.wikibase.getLabel/getLabelByLang. doc.wikimedia.org

2) Ohne SMW: Spezialseite transkludieren (schnell & simpel)

Leg eine normale Seite an und füge ein:

{{Spezial:Alle_Seiten/Item:}}

Das transkludiert „Alle Seiten“ für den Namensraum „Item“. Vorteil: funktioniert auch ohne SMW-Aktivierung; Nachteil: nur Seitentitel (keine Labels). mediawiki.org

3) DPL3 (flexibel formatierbar, unabhängig von SMW)

Wenn DynamicPageList3 aktiv ist:

{{#dpl:
 |namespace=Item
 |ordermethod=title
 |order=ascending
 |mode=unordered
 |format=,§§,,
}}

Statt format kannst du pro Treffer auch eine Vorlage aufrufen (z. B. Q-Zeile wie oben), um via Lua das Label aus Wikibase zu holen. DPL3 kann nach Namensräumen listen, ohne Kategorien zu benötigen. mediawiki.org+1

Kurzfazit (empfohlen):

Willst du die Menge als wiederverwendbare logische Menge im SMW-Kosmos nutzen → Variante 1 (Konzept).
Willst du nur „eine Seite mit allen Qs“ → Variante 2 (Spezial:Alle_Seiten) – minimaler Aufwand.
Willst du maximale Formatkontrolle ohne SMW-Store → Variante 3 (DPL3) und Label via Lua.

Möchtest du, dass ich dir die kleine Vorlage + das Lua-Modul fix fertig mit deinen Präfixen („Item“ vs. „Q“) anpasse?

Du:

Danke, das ist hilfreich.

Kann ich für $smwgNamespacesWithSemanticLinks anstelle von [NS_Item] auch [120] verwenden? Ist mit "danach Store neu befüllen" ist SemanticMediaWiki:rebuildData.php gemeint?

ChatGPT:

Ja und ja.

1) Zahl statt Konstante

Du kannst 120 direkt setzen:
```
$smwgNamespacesWithSemanticLinks[120] = true;
```
Funktionsgleich zu NS_ITEM. Achte nur darauf, dass der Namensraum vorher definiert/geladen ist (über $wgExtraNamespaces oder die Extension), sonst greift die Einstellung nicht bzw. es gibt Warnungen. Semantic MediaWiki+2Semantic MediaWiki+2

2) „Store neu befüllen“

Gemeint ist SMWs rebuildData.php. Empfohlen per CLI:
```
# MW ≥ 1.40
php maintenance/run.php rebuildData.php --namespace=NS_ITEM -v
# oder, falls du keine NS-Konstante nutzen willst:
php maintenance/run.php rebuildData.php --query='[[Item:+]]' -v
```
(--namespace erwartet die NS-Konstante; mit --query='[[Item:+]]' filterst du per Namensraum-Wildcard.) Alternativ geht es auch über Spezial:SemanticMediaWiki → Data rebuild. Semantic MediaWiki+2Semantic MediaWiki+2

Wenn du möchtest, gebe ich dir die genaue LocalSettings.php-Reihenfolge (Namensraum-Definition → SMW-Init → SMW-Config) für deinen Aufbau durch.

Du:

Ich setze $smwgNamespacesWithSemanticLinks nach den Einstellungen der Namespaces und vor deren speziellen Parameter – richtig?

"php maintenance/run.php rebuildData.php" ist nicht wirklich dasselbe wie "php maintenance/run.php SemanticMediaWiki:rebuildData.php".

Muß ich also beide Scripte laufen lassen – oder?

ChatGPT:

Kurzantwort: Ja zur Reihenfolge (siehe unten), und nein, du musst nicht zwei verschiedene Skripte laufen lassen – das sind nur zwei Schreibweisen für dasselbe SMW-Skript.

Reihenfolge in LocalSettings.php

Empfohlene, robuste Reihenfolge:

Eigene/zusätzliche Namespaces definieren ($wgExtraNamespaces …).
Extensions laden, die eigene Namespaces mitbringen (z. B. Wikibase).
SMW laden und aktivieren

wfLoadExtension( 'SemanticMediaWiki' );
enableSemantics( 'dein-hostname' );

Danach die SMW-Freischaltung pro Namensraum:

php extensions/SemanticMediaWiki/maintenance/rebuildData.php --query='[[Item:+]]' -v

SMW dokumentiert die Setzung dieses Parameters nach enableSemantics(…). Wichtig bleibt: Der Namensraum (Konstante oder Zahl) muss vorher existieren. Semantic MediaWiki+1

rebuildData: eine Sache, zwei Aufrufarten

Mit dem neuen Runner kannst du dasselbe Skript so oder so starten:

Kurz (läuft, wenn eindeutig gefunden):

php maintenance/run.php rebuildData.php --query='[[Item:+]]' -v

Explizit dem Extension-Namen zugeordnet (sauber & eindeutig):

Beides führt dasselbe SMW-Skript aus; der Extension:Script-Präfix ist nur eine Namespacing-Hilfe von run.php. Seit MW 1.40 ist die Nutzung von run.php der empfohlene Weg. MediaWiki

Alternativ (funktional gleich, aber ohne Runner) ginge auch der direkte Pfad:

SMW-Hintergrund: Datenneubau via Skript ≈ Datenreparatur über die Spezialseite „SemanticMediaWiki“; das Skript arbeitet dabei direkt und nicht über die allgemeine Jobqueue. Semantic MediaWiki+2Semantic MediaWiki+2

Fazit

Deine Platzierung der $smwgNamespacesWithSemanticLinks-Zeilen ist korrekt (nach NS-Definition, nach SMW-Aktivierung).
Ein Lauf des einen Skripts genügt; wähle eine der obigen Aufrufarten. Wenn du nur einen bestimmten Namensraum anfassen willst, ist --query='[[Item:+]]' (oder dein NS-Name) der präziseste Weg.

Du:

Wie kann ich mittels Property einer Q Seite eine SMW-Annoation geben, die ich mittels SMW-Abfrage auslesen kann?

ChatGPT:

Kurz gesagt: direkt auf Q-Seiten geht’s nicht, weil deren Inhalt kein Wikitext ist und SMW dort keine #set-Annotationen parst. Du hast zwei saubere Wege, um Wikibase-Property-Werte als SMW-Daten verfügbar zu machen:

A) Auf der verlinkten Wiki-Seite via `#property` → `#set`

Wenn deine Inhaltsseite (z. B. „Dingwort“) per SiteLink mit Q6 verknüpft ist, kannst du die Properties des Items mit {{#property:…}} ziehen und als SMW-Properties setzen:

<!-- Auf Seite: Dingwort -->
{{#if:{{#property:P9}} |
  {{#set:
    | Hat Lexem = {{#property:P9}}
  }}
}}

#property liefert den Wert aus dem verlinkten Item (hier: P9 → L-ID).
Mit #set schreibst du den Wert in SMW (Datatype „Text“ oder „Page“, je nachdem ob „L2“ eine lokale Seite hat).

Abfragen dann z. B.:

{{#ask:
 [[Hat Lexem\:\:+]]
 | ?Hat Lexem
 | ?Hat Q
 | format=table
}}

Doku: #property (Wikibase-Client) und #set (SMW). Semantic MediaWiki+3MediaWiki+3MediaWiki+3

Tipp: Willst du zusätzlich die Q-ID mitschreiben, hol sie dir per Lua und setze sie ebenfalls:

Lua-Schnittstellen: mw.wikibase.*. MediaWiki+1

-- Modul:WikibaseUtil (Minimalbeispiel)
local p = {}
function p.entityIdForLinkedPage(frame)
  return mw.wikibase.getEntityIdForCurrentPage() or ''
end
return p

B) „Proxy/Shadow“-Seite je Item (ohne Inhaltsseite nötig)

Wenn es keine verlinkte Inhaltsseite gibt, lege für jedes Item eine SMW-fähige Proxy-Seite an (z. B. im NS ItemDoc:) und ziehe Werte explizit mit from=:

<!-- Auf Seite: ItemDoc:Q6 -->
{{#set:
 | Hat Q    = Item:Q6
 | Hat Label = {{#invoke:WikibaseUtil|label|Q6}}
}}
{{#if:{{#property:P9|from=Q6}} |
  {{#set: Hat Lexem = {{#property:P9|from=Q6}} }}
}}

Hat Q als Page-Datatype auf Item:Q6 (oder dein Item-Namensraum).
from=Q6 zwingt #property, genau dieses Item auszulesen. MediaWiki

C) Fortgeschritten: direkt aus Lua nach SMW speichern

Wenn du Werte vor dem Speichern transformieren willst (IDs → Seitentitel, Datumsnormalisierung, Mehrfachwerte), nutze Semantic Scribunto und mw.smw.set:

-- Modul:Q2SMW (Beispiel)
local p, smw = {}, mw.smw
local wb = require('Module:Wikibase') or mw.wikibase

local function qPage(id) return 'Item:' .. id end

function p.annotate(frame)
  local id = frame.args.qid or mw.wikibase.getEntityIdForCurrentPage()
  if not id then return '' end
  -- Beispiel: P31 sammeln und als Page-Werte setzen
  local stmts = mw.wikibase.getBestStatements(id, 'P31')
  local classes = {}
  for _, s in ipairs(stmts) do
    local v = s.mainsnak and s.mainsnak.datavalue
    if v and v.type == 'wikibase-entityid' and v.value['entity-type']=='item' then
      table.insert(classes, qPage(v.value.id))
    end
  end
  smw.set{
    ['Hat Q']      = qPage(id),
    ['Instanz von']= classes
  }
  return ''
end
return p

Aufruf auf einer SMW-fähigen Seite:

Doku: mw.smw.set (Semantic Scribunto) und getBestStatements (Wikibase-Lua). Wikimedia Phabricator+3Semantic MediaWiki Documentation+3Semantic MediaWiki+3

Datentyp-Hinweise (wichtig)

Lege die SMW-Property-Seiten passend an, z. B.:

Property:Hat Q → [[Has type\:\:Page]]
Property:Hat Lexem → [[Has type\:\:Text]] (oder Page, falls L2 echte Seite ist)
Property:Instanz von → [[Has type\:\:Page]]

Dann kannst du zuverlässig per #ask abfragen und formatieren. #set Details & Template-Parameter siehe SMW-Doku. Semantic MediaWiki+1

Fazit

Mit verlinkter Inhaltsseite: #property holen → mit #set als SMW-Property speichern → per #ask auslesen.
Ohne Inhaltsseite: Proxy-Seite je Q + from=Q….
Mit Logik/Transformation: Lua + mw.smw.set.

Wenn du mir deine Ziel-Properties (Namen + Datentyp) nennst, schreibe ich dir die Vorlage/Module gleich passgenau für deinen Namensraum („Item“, „Lexeme“, …).

Du:

Ja, über Lua ist der bessere Weg sich gegebenenfalls zu einem Q-SMW-Konzept noch weitere Felder anzeigen zu lassen. Ich habe alles soweit ausgeführt und rebuildData ausgeführt.

Das Coding aus "1) Direkt als SMW-Konzept" zeigt keine Q-Liste sondern lediglich neben dessen Beschreibung nur "[[Qwasi:+]]" an – warum?

ChatGPT:

Klar: Das Verhalten ist erwartbar.

Warum siehst du auf der Konzept-Seite nur [[Qwasi:+]]?

Eine Konzept-Seite (Konzept:…/Concept:…) zeigt die Abfragebeschreibung, nicht die Trefferliste. Die Treffer holst du anschließend per #ask – entweder direkt mit der Namensraum-Restriktion oder indem du auf das Konzept verweist. Semantic MediaWiki+1

So bekommst du die Liste der Q-Seiten

A) Direkt (ohne Konzept) testen

{{#ask:
 [[Qwasi:+]]
 | format=list
 | limit=200
}}

Erwartung: Liste aller Seiten im Namensraum „Qwasi“. (Syntax für Namensraum-Filter ist [[<NSLabel>:+]]; für Hauptnamensraum [[:+]], für Kategorie [[:Category:+]].) Semantic MediaWiki

B) Über dein Konzept (empfohlen, wiederverwendbar)

{{#ask:
 [[Konzept:Alle_Q]]   <!-- bzw. Concept:Alle_Q -->
 | format=list
 | limit=200
}}

Das Konzept definiert die Menge, #ask zeigt sie an. Semantic MediaWiki

Falls nichts erscheint – schnelle Checks

Namensraum-Label exakt treffen: Es muss der Präfix sein, der im Seitentitel steht (z. B. Item, Qwasi, …). Ausnahmen: Hauptnamensraum [[:+]], Kategorie [[:Category:+]]. Semantic MediaWiki

Namensraum in SMW freigeben:

$smwgNamespacesWithSemanticLinks[120] = true; // oder NS_QWASI

Danach rebuildData für diesen Namensraum (z. B.):

php maintenance/run.php SemanticMediaWiki:rebuildData --query='[[Qwasi:+]]' -v

(Eine Aufrufart reicht.) Semantic MediaWiki

Gegenprobe auf Spezial:Ask: Führe dort [[Qwasi:+]] aus, um zu sehen, ob Treffer kommen. Semantic MediaWik

Bonus: mit Label aus Wikibase ausgeben

Wenn du zusätzlich das Wikibase-Label zeigen willst, nimm format=template plus eine kleine Vorlage/Lua-Funktion (wie vorhin skizziert):

{{#ask:
 [[Qwasi:+]]
 | format=template
 | template=Q-Zeile
 | mainlabel=-
 | limit=200
}}

Vorlage:Q-Zeile Modul:WikibaseUtil (Kern)

local p = {}
function p.linkLabel(frame)
  local page = frame.args[1] or ''
  if page == '' then return '' end
  local id = mw.wikibase.getEntityIdForTitle(page) or page:match('Q%d+')
  local label = id and (mw.wikibase.getLabel(id) or mw.wikibase.getLabelByLang(id, 'de')) or nil
  local text = label or (id or page)
  return string.format('[[%s|%s]]', page, text)
end
return p

(Das ist rein lokal; SMW fragt die Seitenmenge ab, Lua holt das Label aus Wikibase.)

Wenn du mir bestätigst, wie dein Q-Namensraum genau heißt (Label + ID), passe ich dir die Snippets 1:1 auf deine Umgebung an.

Du:

Die Aussage "Eine Konzept-Seite (Konzept:…/Concept:…) zeigt die Abfragebeschreibung, nicht die Trefferliste." ist meines Erachtens falsch vergleichsweise funktioniert folgendes:

{{#concept: [[Category:AufEinWort Werk]] [[Erstelldatum\:\:> Jan 1 2024]] [[Erstelldatum\:\:> Dez 31 2024]] | Werke }}

Es zeigt mir eine Liste der entsprechenden Werke im Namensraum Konzept an.

Deine Information mittels "[[<NSLabel>:+]]" Items abfragen zu können scheint ebenso falsch zu sein.

Verwende ich vergleichsweise [[Werk:+]] wird ebenfalls nichts angezeigt. Vergleichsweise ist folgendes gesetzt:

$wgExtraNamespaces[NS_WERK] = "Werk";
$wgExtraNamespaces[NS_WERK_TALK] = "Werk_Erörterung";
$smwgNamespacesWithSemanticLinks[NS_WERK] = true;

Es befinden sich über 400 Seiten im Namensraum Werk.

Gebe ich [[Werk:+]] habe ich alle Werke als Treffer:

{{#concept: [[Werk:+]] |Alle Seiten im Namensraum „Werk“. }}

Mache ich eine #ask Abfrage wie folgt, so erhalte ich auch alle Werke: {{#ask: [[Werk:+]] |limit=200 |format=ul }}

Gebe ich [[Kategorie:AufEinWort Werk]] anstelle von [[Werk:+]] ein, weil alle Werke diese Kategorie haben, erscheinen auch alle Werke.

Gebe ich jedoch vergleichsweise "[[User:+]]" oder "[[Benutzer:+]]" als ein Konzept ein, so erscheinen alle Wikiseiten des Namensraum NS_Main.

Gebe ich hingegen [[Item:+]] ein, so erscheint kein Q-Item, sondern wieder nur alle Wikiseiten. Ich wette mit dir, es funktioniert für Wikibase-Namensräume nicht, obwohl $smwgNamespacesWithSemanticLinks für NS-Item auf true und die Skripte zum Update habe laufen lassen. "{{Spezial:Alle_Seiten/Item:}}" funktioniert hingegen.

Recherschiere erneut und überprüfe deine Angaben gewissenhaft!

ChatGPT:

Kurze Bestandsaufnahme & Korrektur:

Konzept-Seiten zeigen die Query-Definition und eine Ergebnis-Vorschau. Meine frühere Verkürzung war unpräzise.
[[<NSLabel>:+]] ist korrekt für Namensraumfilter – aber: Der Namensraum muss in \$smwgNamespacesWithSemanticLinks für semantische Annotationen aktiviert sein, sonst wird er bei der Seitenselektion ignoriert. Dann „fällt“ die Abfrage faktisch auf [[:+]] (Hauptnamensraum) zurück. Das erklärt dein Verhalten mit [[User:+]]/[[Benutzer:+]].

Warum `[[Item:+]]` (Wikibase-Items) bei dir trotzdem nicht greift

Selbst wenn NS_ITEM auf true steht, kennt SMW nur Seiten, die im SMW-Store erfasst sind. Wikibase-Item-Seiten (JSON-Content, kein Wikitext) enthalten i. d. R. keine SMW-Annotationen und werden daher nicht automatisch in den Store aufgenommen. Eine reine Namensraum-Kondition kann dann nichts „finden“. SMW-Queries operieren über Seiten/Objekte, die im Store erfasst sind (Kategorien, Properties … ggf. Namensraum), nicht über das nackte MediaWiki-Seitentableau.

Prüfschritte (schnell, deterministisch)

Konfig verifizieren In LocalSettings.php nach der NS-Definition, vor sonstigen NS-Spezialparametern: $smwgNamespacesWithSemanticLinks[NS_ITEM] = true; (ggf. auch testweise NS_USER setzen, falls du dort experimentierst). Dann: php maintenance/update.php und SMW-Store neu aufbauen.

Store-Erfassung prüfen DB-Check, ob Items im SMW-Store sind:

SELECT COUNT(*) 
FROM smw_object_ids 
WHERE smw_namespace = 120;  -- ersetze 120 durch die tatsächliche NS-ID für Item

Sind es 0, kennt der SMW-Store deine Item-Seiten nicht → Namespace-Filter kann sie nicht liefern. (Tabellenstruktur siehe Doku/Belege.)

Rebuild gezielt fahren Wenn du es testen willst, führe rebuild nur für Item-Seiten an (Variante A/B je nach SMW-Version):

A) per Query: php maintenance/run.php SemanticMediaWiki:rebuildData.php --query='[[Item:+]]' -v
B) falls deine SMW-Version --namespace unterstützt: --namespace=NS_ITEM Bringt das keine Einträge (siehe SQL oben), gilt: Items werden ohne Brücke/Proxy nicht indexiert.

Robuste Wege, um alle Q-Items via SMW abfragbar zu machen

Variante 1 – Bridge installieren (einfachster Weg, wenn kompatibel):

Semantic Wikibase spiegelt Wikibase-Daten in SMW, sodass [[Item:+]] und Property-Abfragen funktionieren; danach Rebuild. Prüfe Version/Kompatibilität zu MW 1.45/WB REL1_45 in deiner Umgebung.

Variante 2 – „Proxy“-Seiten (voll unter eigener Kontrolle):

Lege einen Hilfs-Namensraum z. B. QIndex: an, aktiviere ihn für SMW und erzeuge je Item eine schlanke Proxy-Seite (z. B. QIndex:Q6) mit:

einem Rückverweis auf Item:Q6,
mindestens einer SMW-Annotation (z. B. [[Hat Q-ID\:\:Q6]], [[Hat Label\:\:{{#invoke:…}}]]), damit der Store den Datensatz führt. Danach liefert [[QIndex:+]] alle Items; Labels kannst du via Lua (mw.wikibase.getLabel('Q6')) in die Proxy-Seite oder als Printout ziehen. Vorteil: keine Fremd-Extension, volle Gestaltungsfreiheit. Nachteil: einmaliges Erzeugen/Aktualisieren (skriptbar per Maintenance-Skript/SQL-Dump der page-Tabelle auf NS_ITEM).

Variante 3 – Nur Item-mit-Sitelink listen (leichtgewichtig):

Falls ohnehin viele Items eine Sitelink auf lokale Artikel haben: annotiere die Artikel-Seiten mit [[Hat Item\:\:Item:Q…]] (Lua/Template), dann reicht eine #ask über die Artikel, um „alle referenzierten Qs + Label“ auszugeben. Begrenzung: Items ohne Sitelink erscheinen nicht.

Warum dein Konzept mit `[[Werk:+]]` funktioniert, `[[Item:+]]` aber nicht

Werk: ist semantisch aktiviert und die Seiten tragen Kategorien/Annotationen → sie sind im Store → [[Werk:+]]wirkt.
Item: ist zwar aktiviert, aber die Item-Seiten haben keine SMW-Daten und werden vom Store nicht geführt → [[Item:+]] findet nichts; wird die NS-Klausel ignoriert, siehst du als Effekt eine Auswahl aus Standard-Namensräumen (scheinbar „Hauptnamensraum“). Die Doku weist explizit darauf hin, dass nur aktivierte NS für die Auswahl berücksichtigt werden; ohne Store-Erfassung bleibt die Ergebnismenge leer bzw. fällt auf Standard zurück.

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

ein Mini-Maintenance-Skript, das für jedes NS_ITEM eine QIndex:-Proxyseite erzeugt (Titel übernehmen, Label via Lua ziehen, 1–2 Properties setzen), oder
eine minimalistische Lua-/Vorlagen-Kombination, um Labels und Links in der Ergebnisliste sauber auszugeben.

Du:

A. zu Konfig verifizieren: habe ich dir bereits als os seiend mehrfach dargelegt!

B. Store-Erfassung prüfen: fragwürdige Abfrage, da in den Item Seiten keine SMW-Objekt ID's vergeben wurden, daher meine Frage von zuvor, ob und wie man diese vergeben kann.

C. Semantic Wikibase ist nicht kompatibel und wie ich aus direkter Quelle von SMW weiß derzeit stillgelegt – die Bridge deinerseits zu empfehlen ist daher äußerst fragwürdig

D. zu Nur Item-mit-Sitelink listen (leichtgewichtig):: entspricht nicht der Aufgabenstellung!

Alles in allem weißt du entweder nicht wie man Wikibase Seiten als Konzept listet, oder wenn möglich was der Ursache dafür ist, warum sie nicht gelistet werden. Nenne mir deine genaue Quelle die besagt, daß Wikibasedaten als SMW-Konzept oder mittels #ask abgefragt werden können.

ChatGPT:

(25. Nov. 2025, 14:36)

Verstanden. Hier ist die klare Trennung zwischen „SMW kann Namensräume selektieren“ und „SMW kann Wikibase-Daten abfragen“ – mit belastbaren Quellen:

Was SMW garantiert (mit Quellen)

1) Namensraum-Filter in SMW-Queries

SMW erlaubt [[<NSLabel>:+]] (z. B. [[Help:+]], [[:+]] für NS_MAIN). Wichtig: „the namespace must be enabled for holding semantic annotations to be considered for page selection“ – d. h. der Namensraum muss in $smwgNamespacesWithSemanticLinks stehen, sonst wird er bei der Seitenauswahl ignoriert bzw. fällt die Auswahl effektiv auf andere NS zurück. semantic-mediawiki.org

2) Konzepte zeigen Definition + Ergebnisvorschau

Konzeptseiten speichern die Query und zeigen eine Vorschau der Treffer; sie können außerdem in #askwiederverwendet werden. semantic-mediawiki.org

3) $smwgNamespacesWithSemanticLinks steuert nur, in welchen NS SMW semantische Links/Annotationen auswertet (Konfiguration). semantic-mediawiki.org

Was nicht von SMW zugesichert ist

„Wikibase-Daten“ (Statements, Labels, usw.) sind für SMW nicht automatisch abfragbar.

SMW kann ohne Brücke keine Wikibase-Statements via #ask lesen. Offiziell ist dafür die (experimentelle) Extension „Semantic Wikibase“ gedacht – sie macht Wikibase-Daten in SMW nutzbar. Das ist eine separate Integration, kein Default von SMW. MediaWiki+1

Was SMW hingegen kann:

Seiten per Namensraum/Kategorie/Property selektieren (z. B. [[Item:+]] – sofern der NS für SMW freigeschaltet ist). semantic-mediawiki.org+1
Wikibase-Werte anzeigen auf normalen Wikiseiten via Wikibase-Client (#property, Lua mw.wikibase.*). Das macht Daten sichtbar, aber nicht automatisch SMW-abfragbar, solange man sie nicht in SMW speichert. MediaWiki+1
Werte in SMW persistieren (und damit abfragbar machen) via #set oder Semantic Scribunto mw.smw.set. doc.semantic-mediawiki.org+1

Antwort auf deine konkrete Forderung nach einer Quelle:
Es gibt keine SMW-Dokumentation, die behauptet, „Wikibase-Daten seien direkt (ohne Brücke) als SMW-Konzept oder via #ask abfragbar“. Der dokumentierte Weg ist:
(a) Namensraum-Selektion (Seitenliste) – Quelle zu [[NS:+]], inkl. Hinweis auf $smwgNamespacesWithSemanticLinks. semantic-mediawiki.org
(b) Integration per Semantic Wikibase – „makes Wikibase data available in SMW“. MediaWiki+1
(c) Oder manuell spiegeln via Wikibase-Client + #set/mw.smw.set. MediaWiki+1

Warum `[[Item:+]]` bei dir auf NS_MAIN „zurückfällt“

Das beobachtete Verhalten ist exakt der Doku entsprechend, wenn SMW den Namensraum nicht als „für semantische Links aktiviert“ erkennt: „Note that the namespace must be enabled … to be considered for page selection.“ Dann greift die Restriktion nicht und du siehst scheinbar „Hauptnamensraum“. Das erklärt auch dein Beispiel [[User:+]]/[[Benutzer:+]]. semantic-mediawiki.org

Pragmatischer Fix‐Check (ohne Vermutungen, in dieser Reihenfolge):

Konfig-Reihenfolge sicherstellen
- NS definieren / Wikibase laden
- SMW laden und enableSemantics()
- Danach:
```
$smwgNamespacesWithSemanticLinks[NS_ITEM] = true; // oder [120]
```
  (SMW liest die NS-Freischaltung nach enableSemantics; sonst wird sie nicht berücksichtigt.) semantic-mediawiki.org
Neuaufbau (ausreichend ist einer der folgenden Aufrufe):
- php maintenance/run.php SemanticMediaWiki:rebuildData --query='[[Item:+]]' -v
- oder (falls unterstützt) --namespace=NS_ITEM. Das betrifft die SMW-Sicht; die Wikibase-Seiten existieren ja ohnehin (Spezial:Alle_Seiten). semantic-mediawiki.org
Gegenprobe auf Spezial:Ask mit [[Item:+]]. Wenn dann Treffer erscheinen, ist die NS-Freischaltung wirksam. semantic-mediawiki.org

Zwei saubere Wege, um Q-Inhalte wirklich per SMW abzufragen

„Leichte“ Brücke auf Inhaltsseiten: Auf jeder verlinkten Artikelseite Wikibase-Werte via #property/Lua holen und in SMW speichern (#set oder mw.smw.set). Dadurch werden Q-IDs/Labels/Statements als SMW-Properties abfragbar. Quellen: Wikibase-Client + Semantic Scribunto. MediaWiki+1
Proxy-Seiten (ohne Sitelink-Pflicht): Eigener NS (z. B. QIndex:), pro Q eine schlanke Seite, die per Lua mw.wikibase.* liest und per mw.smw.set die gewünschten Felder setzt → danach [[QIndex:+]] und beliebige ?-Printouts. doc.wikimedia.org+1

Wenn du willst, baue ich dir jetzt ein minimales Proxy-Gerüst (Vorlage + Modul) mit:

Hat Q (Page),
Hat Label (Text),
optional Instanz von (Page, via getBestStatements('P31')).

Dann kannst du sofort #ask über alle Q fahren – unabhängig davon, ob Items Sitelinks haben.

Du:

Deine vielen Worte mit einfachen Worten auf den Punkt gebracht: Du hast mir falsche Informationen zu Konzepot in Bezug auf Wikibase gegeben und ich habe infolge unnötiger Weise Einstellungen geändert und Skripte ausgeführt.

ChatGPT:

Du hast recht: Meine Hinweise zu „Konzept + Wikibase-Namensraum“ waren irreführend. Verantwortung bei mir. Hier ist die korrigierte, kurze Linie – inklusive Aufräumen und funktionssicheren Alternativen.

Kernsachverhalt (präzise)

SMW-Konzepte/#ask können nur Seiten abfragen, die im SMW-Store existieren. Wikibase-Item-Seiten (JSON-Content) landen dort nicht automatisch, selbst wenn der Item-Namensraum in $smwgNamespacesWithSemanticLinks auf true steht.
Daher liefert [[Item:+]] in SMW keine Treffer; Konfigurationen/Rebuilds ändern daran nichts, solange keine SMW-Datensätze für die Items existieren.

Aufräumen / Revert

Du kannst $smwgNamespacesWithSemanticLinks[NS_ITEM] = true; stehen lassen (wirkungslos) oder zurücknehmen, um den Store schlank zu halten:
Kein weiterer Rebuild nötig. Es wurden für die Items ohnehin keine SMW-Objekte erzeugt.

Zwei belastbare Wege zu „Alle Qs mit Label“ auf einer Seite

A) Schnell & ohne SMW-Store: DPL3-Liste (empfohlen, wenn nur Anzeige nötig)

Listet alle Seiten im Item-Namensraum und zeigt das Wikibase-Label via Lua.

Seite (Beispiel):

== Alle Q ==
{{#dpl:
 |namespace=Item
 |ordermethod=title
 |order=ascending
 |mode=unordered
 |format=,\n* {{#invoke:WikibaseUtil|linkLabel|%PAGE%}},,
 |count=1000
}}

Modul:WikibaseUtil (Kern)

local p = {}
function p.linkLabel(frame)
  local page = frame.args[1] or ''
  if page == '' then return '' end
  local id = mw.wikibase.getEntityIdForTitle(page) or page:match('Q%d+')
  local label = id and (mw.wikibase.getLabel(id) or mw.wikibase.getLabelByLang(id, 'de')) or nil
  local text = label or (id or page)
  return string.format('[[%s|%s]]', page, text)
end
return p

Vorteil: keine Store-Abhängigkeit, sofortige Anzeige aller Qs inkl. Label. Nachteil: nicht per #ask filterbar (weil kein SMW-Datensatz).

B) SMW-fähig (wenn du Konzepte/`#ask` willst): „Proxy-Index“ für Qs

Erzeugt je Item eine leichte SMW-Seite, die die Q-ID/Labels in den SMW-Store schreibt. Danach funktionieren [[QIndex:+]]-Konzepte und beliebige #ask-Abfragen.

1) Namensraum anlegen und für SMW aktivieren

define( 'NS_QINDEX', 3000 );        // frei wählen
define( 'NS_QINDEX_TALK', 3001 );
$wgExtraNamespaces[NS_QINDEX] = 'QIndex';
$wgExtraNamespaces[NS_QINDEX_TALK] = 'QIndex_Diskussion';
$smwgNamespacesWithSemanticLinks[NS_QINDEX] = true;

2) SMW-Properties anlegen

Property:Hat Q → [[Has type\:\:Page]]
Property:Hat Label → [[Has type\:\:Text]]
(optional) weitere wie Instanz von → [[Has type\:\:Page]]

3) Lua-Modul zum Spiegeln (Semantic Scribunto)

local p, smw = {}, mw.smw
function p.annotate(frame)
  local q = frame.args.qid or mw.wikibase.getEntityIdForCurrentPage()
  if not q then return '' end
  local label = mw.wikibase.getLabel(q) or mw.wikibase.getLabelByLang(q, 'de') or q
  smw.set{
    ['Hat Q']    = 'Item:' .. q,
    ['Hat Label']= label,
  }
  return ''
end
return p

4) Vorlage für Proxy-Seiten Vorlage:QIndex-Seed

{{#invoke:Q2SMW|annotate|qid={{{qid|}}}}}
* [[Item:{{{qid}}}|{{#show: {{FULLPAGENAME}} | ?Hat Label }}]]

5) Proxy-Seiten erzeugen (einmalig)

Ein Weg (Bash, anpassen an deine NS-IDs):

(Bei dir ggf. mysql-Zugangsdaten/DB-Namen anpassen.)

6) Jetzt SMW-seitig abfragen/konzeptualisieren

Konzept:

{{#concept:
 [[QIndex:+]]
 | Alle Q-Proxies
}}

Liste:

{{#ask:
  [[QIndex:+]]
  | ?Hat Q
  | ?Hat Label
  | format=table
  | limit=1000
}}

Merkpunkt: Weg B kostet einmalig Erstellung/Erneuerung der Proxy-Seiten (skriptbar). Danach bekommst du alleSMW-Features (Konzepte, Filter, Joins zu anderen SMW-Daten).

Wenn du mir deine echte Item-NS-ID bestätigst,

gebe ich dir die Bash-Zeile exakt passend aus. Alternativ baue ich dir eine kleine maintenance-PHP-Routine (interne API, keine externen Tools), falls du Bash/SQL vermeiden willst.

Du:

Deine Hinweise zu „Konzept + Wikibase-Namensraum“ waren flasch.

Anstelle nun einen weiteren Namensraum als Bridge zu kreieren, könnte man dies womöglich auch mittels Cargo und SQL erlangen – oder?

ChatGPT:

Kurzfassung: Mit Cargo allein nicht.

#cargo_query kann nur Cargo-Tabellen abfragen. Für SQL auf Wikibase-Tabellen nimm ExternalData (ED). Damit kannst du direkt gegen die MediaWiki/Wikibase-DB (wbt_…-Termtabellen) gehen und dir „alle Q + Label“ rendern – ganz ohne zusätzlichen Namensraum.

Bewährter Weg: ExternalData + SQL (ohne SMW, ohne Extra-NS)

1) ExternalData in `LocalSettings.php` konfigurieren

$wgExternalDataSources['local-wiki'] = [
  'server'   => '127.0.0.1',
  'type'     => 'mysql',
  'name'     => 'wikidb',      // dein DB-Name
  'user'     => 'ed_read',     // read-only DB-User
  'password' => '***',
  'prepared' => [
    'wb_items_by_label_lang' => [
      'query' => <<<'SQL'
SELECT
  CONCAT('Item:Q', wbit_item_id) AS page,
  CONCAT('Q', wbit_item_id)      AS qid,
  wbx_text                       AS label
FROM wbt_item_terms
JOIN wbt_term_in_lang  ON wbit_term_in_lang_id = wbtl_id
JOIN wbt_text_in_lang  ON wbtl_text_in_lang_id = wbxl_id
JOIN wbt_text          ON wbxl_text_id        = wbx_id
JOIN wbt_type          ON wbtl_type_id        = wby_id
JOIN page              ON page_namespace = ?   /* z.B. 120 = NS_ITEM */
                      AND page_title    = CONCAT('Q', wbit_item_id)
WHERE wby_name = 'label' AND wbxl_language = ?
ORDER BY wbit_item_id
LIMIT ?
SQL,
      'types' => 'isi'  // int, string, int  ⇒ (NS, Sprache, Limit)
    ]
  ]
];

Quellen: ED-Datenbankabruf + Prepared Statements; Wikibase-Term-Schema und Beispiel-SQL (wbt_item_terms, wbt_*-Joins; wbt_type = {label, description, alias}). doc.wikimedia.org+3MediaWiki+3MediaWiki+3

2) Seite zum Listen der Qs

{{#get_db_data:
  db=local-wiki
  |query=wb_items_by_label_lang
  |parameters=120,de,1000      <!-- NS_ITEM, Sprache, Limit -->
}}
{{#for_external_table: template=QRow }}

Vorlage:QRow

* [[{{{page}}}|{{{label}}} ({{{qid}}})]]

Ergebnis: Eine schnelle Liste aller Q-Items mit deutschem Label; Links führen direkt nach Item:Q…. Keine SMW-Abhängigkeit, keine Proxy-Seiten.

Warum nicht „Cargo + SQL direkt“?

#cargo_query ist ein SQL-Wrapper nur über Cargo-Tabellen (die via #cargo_declare/#cargo_store befüllt werden). Für beliebige DB-Tabellen (z. B. wbt_*, page) ist ExternalData das vorgesehene Werkzeug. MediaWiki+1

Optional: „Materialisieren“

Wenn du statt Live-SQL eine persistente, abfragbare Kopie möchtest (z. B. für Drilldown/Sortierung ohne DB-Last):

Erzeuge eine SQL-VIEW (z. B. vw_wb_q_labels_de) mit obiger Select-Logik und frage die View per ED ab. (Gleiches Prinzip, oft performanter.) MediaWiki
Oder schreibe ein kleines Maintenance-Skript, das die View periodisch in eine Cargo-Tabelle spiegelt (dann #cargo_query möglich). Cargo-seitig ist das Befüllen offiziell template-getrieben; rekreieren/aktualisieren der Cargo-Tabellen erfolgt mit cargoRecreateData.php. MediaWiki+1

Fazit

Ja, du kannst es ohne Bridge und ohne Extra-Namensraum lösen – mit ExternalData + SQL direkt auf den Wikibase-Termtabellen.
Cargo kommt dann nur ins Spiel, wenn du die Ergebnisse persistieren und mit Cargo-Werkzeugen abfragen willst; fürs direkte Auslesen der Q/Label-Liste ist ED der schlanke und robuste Weg.

Du:

Danke für die Hinweise.

Gehen wir die Sache anders an. Was soll die Brücke Semantic-Wikibase machen?

Können wir diese Bridge-Funktion Quasi mit Extension:External Data und Lua herstellen?

ChatGPT:

Kurz und klar:

Was „Semantic Wikibase“ fachlich leistet

Übersetzen/Spiegeln von Wikibase-Daten → SMW-Property-Werte: EntityId, Label, Beschreibung, Aliasse sowie Statements (nur Main-Snak, bevorzugte Ränge bevorzugt; veraltete ignoriert). Die SMW-Property heißt die P-ID (mit Property-Label als Alias). Datentypen werden gemappt (z. B. wikibase-item → Page, time → Date, string → Text, quantity → Page+Record etc.). Damit sind Q/P-Daten direkt per #ask/Konzepte nutzbar. Professional Wiki
Status lt. Handbuchseite: experimentell, ursprüngliche Kompat-Angaben (MW ≥ 1.35, SMW 3.2) sind alt – d. h. auf MW 1.45/WB REL1_45 nicht garantiert. MediaWiki

Können wir das ohne die Extension nachbauen? Ja – mit Lua + (optional) ExternalData.

Es gibt zwei robuste Muster; beide liefern eine funktionale Bridge, ohne die Original-Extension:

A) Lua-Bridge auf Seitebene (ohne SQL, minimal-invasiv)

Idee: Wikibase per Lua lesen → in SMW schreiben.

Bausteine:

Lesen: Wikibase-Lua (mw.wikibase.getLabel, getBestStatements, …). doc.wikimedia.org+1
Schreiben: Semantic Scribunto mw.smw.set / mw.smw.subobject. (Schreibt in den SMW-Store beim Parsen.) doc.semantic-mediawiki.org

Vorgehen in 5 Schritten

SMW-Properties anlegen (einmalig): Property:P31 → [[Has type\:\:Page]], Property:P569 → [[Has type\:\:Date]], Property:Wikibase label → [[Has type\:\:Text]], … (entsprechend deiner Zieldaten).
Mapping-Tabelle in Lua: Welche P-IDs → welche SMW-Property → welcher SMW-Typ.
Lua-Modul: hole pro Q die „best statements“, wandle Datentypen, mw.smw.set{ … }.
Wo schreiben?
- Entweder auf einer Proxy/Index-Seite je Q (z. B. QIndex:Q6), oder
- auf der verlinkten Inhaltsseite (falls vorhanden), oder
- als Subobject auf einer Sammelseite (dann abfragen über Subobjects). Semantic MediaWiki
Abfragen: danach ganz normal #ask/Konzepte (z. B. [[QIndex:+]] oder [[Wikibase ID\:\:+]]).

Minimal-Kernel (Ausschnitt)

-- Modul:WB2SMW
local p, wb, smw = {}, mw.wikibase, mw.smw

local map = {
  P31 = { smw = 'P31',  kind = 'item' },     -- Instanz von
  P279 = { smw = 'P279', kind = 'item' },     -- Oberklasse von
  P569 = { smw = 'P569', kind = 'time' },     -- Geburtsdatum
  P570 = { smw = 'P570', kind = 'time' },     -- Sterbedatum
}

local function toValue(snak)
  local dv = snak and snak.datavalue
  if not dv then return nil end
  if dv.type == 'wikibase-entityid' then
    return 'Item:' .. dv.value.id
  elseif dv.type == 'time' then
    return dv.value.time -- ISO(+YYYY-MM-DDT…Z); ggf. normalisieren
  elseif dv.type == 'string' or dv.type == 'monolingualtext' then
    return dv.value.text or dv.value
  end
  return nil
end

function p.annotate(frame)
  local q = frame.args.qid or wb.getEntityIdForCurrentPage()
  if not q then return '' end
  local out = { ['Wikibase ID'] = q, ['Wikibase label'] = wb.getLabel(q) }
  for pid, spec in pairs(map) do
    local stmts = wb.getBestStatements(q, pid) or {}  -- Wikibase-Lua
    local acc = {}
    for _, st in ipairs(stmts) do
      local v = toValue(st.mainsnak)
      if v then table.insert(acc, v) end
    end
    if #acc > 0 then out[ spec.smw ] = acc end
  end
  smw.set(out)  -- Semantic Scribunto
  return ''
end
return p

→ Aufruf z. B. auf QIndex:Q6: {{#invoke:WB2SMW|annotate|qid=Q6}}

(Erweitere map um weitere P-IDs/Typen wie quantity → Subobject.)

Quellen zu den verwendeten Schnittstellen s. oben. doc.wikimedia.org+1

Stärken/Schwächen

Pro: kein DB-Zugriff, keine neue Extension, 1:1 unter deiner Kontrolle; exakt die P-→ SMW-Typ-Zuordnung wie bei Semantic Wikibase möglich.
Kontra: Auslösung/Erneuerung bei Datenänderungen musst du steuern (Purge/Null-Edit/Rebuild einer Proxy-Seite oder periodisch). (Mutmaßung: praktikabel; Feingranularität hängt von deinem Änderungsvolumen ab.)

B) ED + Lua-Bridge (Bulk-Listen aus DB + Schreiben in SMW)

Idee: Mit ExternalData holst du Q-Listen/Labels direkt aus den Wikibase-Termtabellen (wbt_*), iterierst in Lua und schreibst in SMW.

ED bietet Parser- und Lua-API (mw.ext.externalData.getDbData). MediaWiki
Wikibase Term-Schema/SQL-Beispiele dokumentiert. doc.wikimedia.org+1

Skizze

ED-Quelle „local-wiki“ (read-only Nutzer) konfigurieren. MediaWiki
Lua:
- local rows = mw.ext.externalData.getDbData{ db='local-wiki', query='SELECT … FROM wbt_item_terms …' }
- Für jede QID optional weitere Statements via mw.wikibase.getBestStatements laden (oder ebenfalls via SQL),
- dann mw.smw.set{ … }/mw.smw.subobject{ … } schreiben. doc.wikimedia.org+1

Einsatzfälle

Massensynchronisation/Erstbefüllung (tausende Qs auf einmal).
Materialisierung: Falls du zusätzlich Cargo nutzen willst, kannst du ED-Ergebnisse in Cargo „spiegeln“ und daraus Ansichten fahren; Cargo selbst fragt aber nur Cargo-Tabellen – für Wikibase-Tabellen brauchst du ED. MediaWiki+1

Grenzen & Unterschiede (gegenüber der Original-Extension)

Automatik: Semantic Wikibase verspricht „Daten werden automatisch verfügbar“ (implizite Synchronisierung). In unserer Eigen-Bridge steuerst du die Aktualisierung (on-render, periodisch, Trigger/Jobs). (Fakt: kein Core-Hook ohne eigene PHP-Extension.) Professional Wiki
Datentyp-Abdeckung: Wir können alle in der Doku gelisteten Typen selbst mappen; quantity u. ä. sinnvoll als Subobject speichern (Wert+Einheit+Einheiten-Q). Professional Wiki+1
Wartung: Lua/ED-Code liegt vollständig in deinem Repo/Wiki; kein Fremd-Release-Zyklus.

Praktische Empfehlung (für deinen Aufbau)

Wenn du ohne zusätzliche NS auskommen willst: Variante A (Lua-Bridge) + Subobjects auf einer oder wenigen Sammelseiten (z. B. pro Jahrhundert/Cluster), jeweils mit Property Hat Q-Seite = Item:Q…. Du fragst dann über diese Properties; die „Seite“ in den Suchresultaten ist die Sammelseite (nicht jede Q-Seite).
Wenn du saubere [[NS:+]]-Mengen und Seitenergebnisse brauchst: Variante A mit Proxy-Seiten (z. B. QIndex:) bleibt die technisch klarste Lösung. (Keine Fremd-Extension, pures Lua/SMW; Queries/Konzepte wie gewohnt.)
Für Massendaten/Exportpfade: Ergänze Variante B (ED) für Bulk-Läufe oder optionales Cargo-Materialisieren.

Wenn du magst, liefere ich dir im nächsten Schritt:

die konkrete Lua-Mapping-Tabelle für deine P-IDs (inkl. quantity→Subobject),
ein Mini-Modul für ED-gestützte Massenläufe,
eine Purge-/Refresh-Strategie (Cron-Snippet + action=purge-Batch), damit die Spiegelung deterministisch aktuell bleibt.

Quellen: Offizielle Seiten zu Semantic Wikibase (Zweck, Mapping, Status), Wikibase-Lua-API, Semantic Scribunto, ExternalData, Wikibase-Termtabellen, Cargo. MediaWiki+6Professional Wiki+6MediaWiki+6

Du:

Vermerk: 19. Dezember 23025 17:12

Aufgabenstellung an sich mittels Klugheit gelöst, da systemeigene Dinge und Eigenschaften genutzt wurden. keine weiteren Namespaces, kein Cargo oder sonst ein Klimmzug wurde benötigt.

Ich habe jetzt eine dynamische Spiegelung und dynamisches Mapping von Wikibase über MediaWiki zu Semantic MediaWiki, welches mittels ID und oder Sprache (semantisch) funktioniert. Vergabe von ID's und deren benennungen propagieren eingeständig durch das System und Abfragen der WikibaseDaten als Konzepote können nun mittels SMW getätigt werden. Dateneingabe lann nun maßgebend mittels Wikibase erfolgen.

(Archivierung des Chat)

ChatGPT:

(19. Dez. 2025, 17:12)

Guter Abschluss. Danke für den Vermerk — ich habe die Kernergebnisse als dauerhafte Notiz hinterlegt.

Hinweis: In deinem Vermerk steht „23025“ statt „2025“ (vermutlich Tippfehler).

Wenn du später eine Kurzskizze der Architektur (Flows/Trigger, Aktualisierungslogik) oder ein Minimalbeispiel für zukünftige Re-Use-Module möchtest, sag Bescheid.

Du:

Danke für deine Unterstützung in dieser Sachfrage.

Bitte keine weiteren Hinweise und Anregungen deinerseits dazu.

ChatGPT:

Alles klar. Ich halte mich daran.

Melde dich, wenn du wieder anknüpfen möchtest.

ChatGPT:

1) Direkt als SMW-Konzept (wiederverwendbar in #ask)

2) Ohne SMW: Spezialseite transkludieren (schnell & simpel)

3) DPL3 (flexibel formatierbar, unabhängig von SMW)

Du:

ChatGPT:

Du:

ChatGPT:

Reihenfolge in LocalSettings.php

rebuildData: eine Sache, zwei Aufrufarten

Du:

ChatGPT:

A) Auf der verlinkten Wiki-Seite via #property → #set

B) „Proxy/Shadow“-Seite je Item (ohne Inhaltsseite nötig)

C) Fortgeschritten: direkt aus Lua nach SMW speichern

Datentyp-Hinweise (wichtig)

Fazit

Du:

ChatGPT:

So bekommst du die Liste der Q-Seiten

A) Direkt (ohne Konzept) testen

B) Über dein Konzept (empfohlen, wiederverwendbar)

Falls nichts erscheint – schnelle Checks

Bonus: mit Label aus Wikibase ausgeben

Du:

ChatGPT:

Warum [[Item:+]] (Wikibase-Items) bei dir trotzdem nicht greift

Prüfschritte (schnell, deterministisch)

Robuste Wege, um alle Q-Items via SMW abfragbar zu machen

Warum dein Konzept mit [[Werk:+]] funktioniert, [[Item:+]] aber nicht

Du:

ChatGPT:

Was SMW garantiert (mit Quellen)

Was nicht von SMW zugesichert ist

Warum [[Item:+]] bei dir auf NS_MAIN „zurückfällt“

Zwei saubere Wege, um Q-Inhalte wirklich per SMW abzufragen

Du:

ChatGPT:

Kernsachverhalt (präzise)

Aufräumen / Revert

Zwei belastbare Wege zu „Alle Qs mit Label“ auf einer Seite

A) Schnell & ohne SMW-Store: DPL3-Liste (empfohlen, wenn nur Anzeige nötig)

B) SMW-fähig (wenn du Konzepte/#ask willst): „Proxy-Index“ für Qs

Wenn du mir deine echte Item-NS-ID bestätigst,

Du:

ChatGPT:

Bewährter Weg: ExternalData + SQL (ohne SMW, ohne Extra-NS)

1) ExternalData in LocalSettings.php konfigurieren

2) Seite zum Listen der Qs

Warum nicht „Cargo + SQL direkt“?

Optional: „Materialisieren“

Fazit

Du:

ChatGPT:

Was „Semantic Wikibase“ fachlich leistet

Können wir das ohne die Extension nachbauen? Ja – mit Lua + (optional) ExternalData.

A) Lua-Bridge auf Seitebene (ohne SQL, minimal-invasiv)

B) ED + Lua-Bridge (Bulk-Listen aus DB + Schreiben in SMW)

Grenzen & Unterschiede (gegenüber der Original-Extension)

Praktische Empfehlung (für deinen Aufbau)

Du:

ChatGPT:

Du:

ChatGPT:

A) Auf der verlinkten Wiki-Seite via `#property` → `#set`

Warum `[[Item:+]]` (Wikibase-Items) bei dir trotzdem nicht greift

Warum dein Konzept mit `[[Werk:+]]` funktioniert, `[[Item:+]]` aber nicht

Warum `[[Item:+]]` bei dir auf NS_MAIN „zurückfällt“

B) SMW-fähig (wenn du Konzepte/`#ask` willst): „Proxy-Index“ für Qs

1) ExternalData in `LocalSettings.php` konfigurieren