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.
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
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.
auch ich freue mich über die von Nils angestoßene Kommunikation hier. Und auch, dass sich nach Ausfall des BEACON-Findbuchs von Thomas Berger durchaus die eine und andere neue Aktivität entfaltet hat. Ich selbst habe mich prototypisch mit einem GND BEACON Hub befasst (bei Interesse: hier entlang GND BEACON Hub ), und würde mir gern erlauben, auf unser Text+ FAIR-February Meet-Up, bei dem die hier aufgeworfenen Themen definitiv eine Rolle spielen werden. Über Impulse dort würden wir uns also sehr freuen und dazu herzlich einladen. ( Anmeldung: https://events.gwdg.de/event/1351/page/406-1822026-fair-netzen )
Herzlich willkommen im metadaten.community-Forum, @Harald_Lordick ! Magst du für das Text+Meetup vielleicht unter Veranstaltungen einen Post anlegen? Wie das geht, steht unter Vorschlag für Veranstaltungen und Termine. Du kannst den gerne einfach mal anlegen. Ich schaue dann, ob alles stimmt und passe es ggf. an.
Hallo zusammen! An der BBAW nutzen wir auch schon lange BEACON-Dateien, auch (aber nicht nur) zur Vernetzung zwischen unseren eigenen Editionen (z.B. in der edition humboldt digital). Wird auch von den Bearbeiter:innen selbst sehr gerne genutzt und nachgefragt. Uns trieb das Problem eines fehlenden Aggregators auch schon um, daher haben wir letztes Jahr begonnen, einen zu entwickeln: “entityHub”. Er steht nun kurz vor dem Launch, wir legen grade letzte Hand an. Einen ersten Überblick gibts hier: entityHub – Berlin-Brandenburgische Akademie der Wissenschaften. Er wird nicht nur GND(-BEACONs) unterstützen, sondern auch VIAF, Wikidata und GeoNames.
Wir stellen ihn auch just diese Woche in einem Poster auf der DHd vor (hier gehts zum Abstract)! Wir würden uns sehr freuen mit Euch, @nils.geissler und @Harald_Lordick und sowieso allen am Thema Interessierten ins Gespräch zu kommen
für die Architekturdatenbank archINFORM.net nutzten auch wir BEACON über den findbuch.de-Service von Thomas Berger. Nachdem dieser leider eingestellt wurde, betreiben wir einen eigenen Aggregator (allerdings nur für ausgewählte, architekturrelevante Quellen). Die Einfachheit macht das BEACON-Format meiner Meinung nach auch heute noch attraktiv, insbesondere für kleinere Nischenanbieter. Als Register sehe ich Wikidata mit der bereits genannten Property P13449 als bestgeeignete Lösung. Über Qualifikatoren könnten noch weitere notwendige Detailinformationen (z.B. Aktualität und Umfang) mit angegeben werden. Über SPARQL-Abfragen ist es möglich für Aggregatordienste, etc die Informationen einfach und wohlstrukturiert auszulesen. Über die Wikidata-API können sogar automatisiert die Qualifikatorangaben erstellt/geändert werden (ein Aggregatordienst könnte z.B. nach jedem Durchlauf die Anzahl der Einträge und das Datum des letzten Updates einspeisen).
