BEACONs im Jahr 2026?

Liebe alle,

in der 15. metadaten.community-Stunde ( 15. metadaten.community-Stunde - #4 von acka47 ) haben wir auch über BEACONs gesprochen.

Beim FID Philosophie steht für die laufende Förderphase ein BEACON-Findbuch (als Ersatz für das nicht mehr verfügbare findbuch.de) als Arbeitspaket auf der To-Do-Liste, das in Kooperation mit anderen FIDs entstehen soll bzw. entsteht. Entsprechend habe ich mich in den letzten Wochen mit den in Wikipedia hinterlegten BEACONs (vgl. Wikipedia:BEACON – Wikipedia ) und dem Format an sich ( Wikipedia:BEACON/Format – Wikipedia + BEACON link dump format ) beschäftigt.
Aktuell funktioniert unser BEACON-Findbuch als Prototyp/„early alpha“ über so eine Art Dreischritt: 1) Erzeugung einer Liste von (aktiven) BEACONs, 2) Aggregierung der BEACONs und am Ende 3) Abfragbarkeit der Aggregation.

Ich vermute, dass die o.g. Wikipedia-Seite/Liste die Einstiegsstelle für die meisten ist, die nicht bereits eine eigene Liste führen und entsprechend dieselben Hindernisse/Probleme jedes Mal neu bearbeitet werden. Einerseits ist eine Wikipedia-Seite natürlich schnell und einfach bearbeitbar bzw. erweiterbar, andererseits ist das immer potenziell nicht-so-wirklich-strukturiert.
Es gab wohl auch schon mal eine Diskussion, ob man die existierende Liste nicht auch (wo)anders nachhalten könnte (z.B. auf Wikidata). Das Ergebnis der Diskussion kann ich nur so grob erahnen/ableiten: die Liste befindet sich noch auf Wikipedia.

Trotzdem würde ich da gerne nochmal nachhaken, wie so allgemein die Erfahrungen und Vorgehensweisen (und Vorbehalte?) sind. Tobias hat auch schon eine Wikidata-Property für BEACONs gefunden: 15. metadaten.community-Stunde - #3 von TobiasNx (P13449).

Damit hier auch eine konkrete Frage steht: Wie nutzt ihr BEACONs in 2026 und was sind eure Meinungen und Erfahrungen zum Format?

Mir erscheint es als ein tolles dezentrales Mittel, um Normdatenverknüpfungen zu kommunizieren (5 von 5 Sternen!). Im „direkten Umgang“ mit BEACONs (AKA aggregieren) habe ich mich nicht nur einmal an den unterschiedlichen Interpretationen des Formats gestoßen. Fazit: Ich würd’s wieder machen (geht ja auch gar nicht anders), aber ich sehe Verbesserungspotenzial.

LG
Nils

PS: Falls Interesse besteht, kann ich auch noch eine Auswertung zur „inneren Beschaffenheit“ der etwas über 300 BEACONs teilen - also bspw. welche Header-Felder am meisten genutzt werden.

3 Likes

Super, dass BEACON mal wieder ins Gespräch kommt. Wir nutzen am IOS Regensburg BEACON für das Biographische Lexikon zur Geschichte Südosteuropas ( Biographisches Lexikon zur Geschichte Südosteuropas ). Seit das findbuch nicht mehr läuft, nutzen wir einen Agregator der LMU München (Prometheus). Dadurch verweisen wir von den Personenartikeln auf weiterführende Infos, z.B. für Tito ( Tito ) auf GND 118622935 Beacon Aggregator
Viele Grüße,
Hans

1 Like

Hallo Nils, vielen Dank für die Initiative!

Bei der Carl-Maria-von-Weber-Gesamtausgabe (und daran angelehnten Projekten) nutzen wir seit Jahren BEACONs und sind nach dem Ende von findbuch auf Open DtBio umgestiegen (vielen Dank an die Münchner Kolleg:innen!)

Ich halte das Format in Verbindung mit einem Aggregator-Such-Service noch immer für eine tolle Sache, da es so schön einfach in der Erzeugung und in der Benutzung ist.

Ein Schwachpunkt (von Dir genannt) ist die Registrierung von BEACONs, bzw. dass es keine “offizielle” Seite und/oder Prozess für die Angabe neuer/geänderter BEACONs gibt.

Eine weitere Herausforderung für einen solchen Service erscheint mir das Mapping von alten GNDs auf aktuelle. Viele ältere BEACONs nutzen ja GNDs, die inzwischen dedupliziert worden sind oder in anderer Weise neue IDs bekommen haben. Da braucht man dann ein Mapping zwischen all diesen GNDs, die alle (zu verschiedenen Zeiten) auf dieselbe Entität verwiesen haben.