Wikipedia Diskussion:BEACON

message: Gedächtnisstütze für PND und/oder BEACON-Files: http://www.ndb.badw-muenchen.de/eb_pnd.htm. -- Mathias Schindler 00:55, 6. Apr. 2010 (CEST)

message: * Fehlerhaftes TARGET
** Falsche URL (z.B. ADB-Register braucht "pnd" vor "{ID}") [wurde korrigiert]
** Falscher oder fehlender Platzhalter (z.B. {id} (Göttingen) oder $PND (Dresden) statt {ID})
Lösungen: Validierung des TARGET und Auflösung und Anzeige eines Beispiels im Beacon-Validator/-Aggregator
* FEED angeben, aber pflegen: Nach Umkonfiguration des Servers kommt dann beliebiger Content statt Beaocn-Datei oder HTTP-Fehlerstatus (kein aktuelles Beispiel)
* Probleme mit Datumsangaben
** REVISIT und TIMESTAMP angeben, aber veralten lassen, obwohl regelmäßig aktualisiert wird (Frankfurt)
Lösung: ?
** DATE statt TIMESTAMP angeben (ADB-Register, BSB)
:Lösung: Formale Validation
* Beacon-Datei mit Nachweisen zu Namenssätzen (Tn) der PND aufblähen (Frankfurt)
:Lösung: Inhaltliche Validation durch Abgleich mit dem PND-Datenbestand
* Mangels Konkordanz SWD-Nr. -> PND-Nr. desselben Datensatzes die individualisierten Personen aus bibliothekarischen Sacherschliessungen nicht nachweisen können (München, wohl generelles Problem von Aleph-Systemen)
:Lösung: Inhaltliche Validation (Aufbesserung, Umschreibung) durch Abgleich mit dem PND-Datenbestand
* Probleme mit der Syntax und Zeichenkodierung
** Beacon-Datei beginnt mit Leerzeile und damit leerem Header (München)
Lösung: Leerzeilen sollten vom BEACON-Parser ignoriert werden
** Beacon-Datei als UTF-8 abspeichern, BOM wegmachen, als Bytes einlesen und erneut als UTF-8 abspeichern (Münster)
** UTF-8-codierte Datei auf einen Webserver legen, der sie als ISO-8859-1 codiert deklariert (Münster): Das ist ein echtes Dilemma, denn stures Abspeichern macht die lokale Kopie der Datei verarbeitbar, beim automatisierten Harvesten hingegen zieht die Deklaration des Webservers und nur eine formatwidrig nicht UTF-8 codierte Datei wäre problemlos verarbeitbar.
** ISO-8859-1-codierte Datei auf einen Webserver legen, der keinen Zeichensatz deklariert
Lösung: Ggf. Zusätzliches Meta-Feld mit definierten Sonderzeichen z.B. #EUROSIGN: €
:Das BOM ist so ein Spezialzeichen, das Praxisbeispiel zeigt aber, dass daran isoliert herumrepariert wird, so dass man hinterher mit inkonsistenter Codierung dasteht, das ist noch schlimmer. -- Thomas Berger 17:11, 13. Apr. 2010 (CEST)
replies: text: BOM ist ein Spezialfall, da man es nicht direkt sehen kann. Du hast aber recht, dass jedes Kontrollzeichen in nachhinein geändert werden kann - nur sehe ich dann leider keine Möglichkeit, die Codierung zu validieren :-( -- Nichtich 18:13, 13. Apr. 2010 (CEST)
thread_title:  Was alles schiefgehen kann 

message: * Das Feld #TIMESTAMP angeben, möglichst genau dem Zeitpunkt entsprechend, an dem der Abzug erstellt wurde (auch wenn der zugrundeliegende Datenbestand signifikant älter sein sollte: der "Stand der Daten" kann im #DESCRIPTION-Feld vermerkt werden).
:Ausnahme evtl.: Wenn die Beacon-Datei jeweils dynamisch auf Anforderung generiert wird, sollte #TIMESTAMP nicht doch besser die letzte Änderung im Datenbestand reflektieren? -- Thomas Berger 11:23, 18. Apr. 2010 (CEST)
thread_title:  Best Current Practice 

message: zu PND/BEACON und BEACON, mir scheint es derzeit günstig, das hier zusammenzuhalten. -- Thomas Berger 01:09, 19. Apr. 2010 (CEST)
replies: text: Ja
* TIMESTAMP/REVISIT: "Unix-Timestamp" ist mehrdeutig: Sekunden seit 1970-01-01 oder "Mon Apr 12 21:20:33 CEST 2010". Am besten wäre wohl eine menschenlesbare Angabe wie im allgemeinen-Beacon-Format spezifiziert, allerdings unbedingt mit Angabe der Zeitzone (stets UTC), wie es beispielsweise etwa auch OAI-PMH spezifiziert: "2010-04-12T19:20:33Z".
* INSTITUTION ist oft unspezifisch, DESCRIPTION sehr geschwätzig. Um die konkrete Anwendung/Datenbank zu benennen, auf die die Beacon-Datei führt, gefällt mir das (inoffizielle) NAME-Feld der Göttinger Beacon-Dateien sehr gut.
* DESCRIPTION kann natürlich URLs (als Text) enthalten, evtl. benötigt wird aber ein Feld, das als Ersatz / Ergänzung zu DESCRIPTION auf eine Seite verweisen kann, die die Anwendung beschreibt oder auf das "reguläre" Benutzerinterface der Zieldatenbank verlinkt
* Besteht Bedarf, (die URL von) Icons (etwa http://www.lwl.org/westfaelische-geschichte/favicon.ico) oder Banner-artige(n) größere(n) Graphiken (etwa http://www.lwl.org/westfaelische-geschichte/portal/Internet/grafik/logo_wg.png) als Ergänzung von INSTITUTION / NAME zu transportieren? Wenn ja, muessten wohl Größenvorgaben gemacht bzw. Skalierungshinweise gegeben werden. -- Thomas Berger 11:38, 18. Apr. 2010 (CEST)

text: Ist "@" wirklich günstig? -- Thomas Berger 17:06, 13. Apr. 2010 (CEST)
replies: text: Das ist an die RDF-Turtle-Syntax angelehnt, warum nicht? -- Nichtich 18:11, 13. Apr. 2010 (CEST)

text: Bei mehrspaltigen Ergebnisangaben erscheint dann dort auch evtl. sprachspezifischer Text. Wird mit @ recht kompliziert. Alternativvorschlag: Eine Beacon-Datei ist immer ausschließlich in einer Sprache. Die Sprachangabe wird festgelegt mit z.B.
 #LANGUAGE de
Andere Sprachversionen können durch folgende Angabe(n) integriert werden:
 #ALTLANG en=http://beacon.abc.org/beacon_en.txt
 #ALTLANG fr=http://beacon.abc.org/beacon_fr.txt
Die jeweilige Resolver-URL kann dann auch einfach für unterschiedliche Sprachausgaben angegeben werden. --Arch2all 12:00, 13. Sep. 2011 (CEST)
replies: text: Wäre das für einen Nachnutzer, der die Daten zur Einbindung in eine mehrsprachige Umgebung benutzt, nicht eher umständlich? Schliesslich hätte er mehrere redundante BEACON-Dateien zum im Prinzip gleichen Angebot kohärent zu halten. Die Methode mit getrennten BEACON-Dateien hat allerdings den Vorteil, auch die Kommentare oder Trefferzahlen in den ID-Zeilen lokalisieren zu können ("3 livres d'étude", "Special collections building"), das in einem einfachen Format zu parallelisieren stelle ich mir schwierig vor. -- Thomas Berger 13:10, 13. Sep. 2011 (CEST)

text: Zeichen mit Wert oberhalb von 127 müssen durch die einsetzende Anwendung URL-encodiert werden (sofern sie vorkommen), Zeichen unterhalb von 127 dürfen nicht umcodiert werden: Das hat die bereitstellende Anwendung bereits in jedem Fall durchgeführt.
Das ist etwas gruselig, aber die BEACON-Datei soll ja möglichst einfach zu erstellen sein, notfalls per Hand. Ob (siehe Wikpedia) "/" als "/" genutzt wird oder "%2C" werden muss, kann nur in Kenntnis der Anwendung entschieden werden; da es sich nur um wenige Zeichen handelt, bekommt der Ersteller das notfalls auch mit Ersetzungsbefehlen in der Textverarbeitung hin. Nicht-7bit-ASCII-Zeichen korrekt zu encodieren erfordert jedoch höheres Kopfrechnen für eine nicht beschränkte Anzahl von Zeichen. Ich sehe natürlich das Problem, dass es keine Standardroutinen für das vorgeschlagene Verfahren gibt.
Alternativ müsste der Header ein Zusatzfeld mit einer Liste der Zeichen enthalten, die zwar normalerweise "protected" sind, hier aber nicht umcodiert werden dürfen: Das ist aber sehr technisch und damit auch un-BEACON-mässig, und ob Spatien als "%20", "_" oder "+" zu codieren sind, ist damit auch nicht erklärt.
-- Thomas Berger 02:14, 28. Apr. 2010 (CEST)

text: Unter http://ws.gbv.de/beacon/validator ist jetzt ein erster Validator (ohne inhaltliche Kontrolle) -- Nichtich 10:52, 14. Apr. 2010 (CEST)

text: Zum Experimentieren sind folgende Mappings bereitgestellt: ungültig gewordene PND-Nummern zu individualisierten Sätzen (ca. 68500 Identifier aus MAB 016) sowie  SWD-Nummern zu PND-Sätzen (ca. 303.000 Identifier aus MAB 028c). -- Thomas Berger 10:59, 19. Apr. 2010 (CEST)
thread_title:  Formatdiskussion 

message: * Sollte eine Beacon-Datei mit BOM und/oder Leerzeilen beginnen dürfen?
:Ja
* TIMESTAMP/REVISIT: "Unix-Timestamp" ist mehrdeutig: Sekunden seit 1970-01-01 oder "Mon Apr 12 21:20:33 CEST 2010". Am besten wäre wohl eine menschenlesbare Angabe wie im allgemeinen-Beacon-Format spezifiziert, allerdings unbedingt mit Angabe der Zeitzone (stets UTC), wie es beispielsweise etwa auch OAI-PMH spezifiziert: "2010-04-12T19:20:33Z".
* INSTITUTION ist oft unspezifisch, DESCRIPTION sehr geschwätzig. Um die konkrete Anwendung/Datenbank zu benennen, auf die die Beacon-Datei führt, gefällt mir das (inoffizielle) NAME-Feld der Göttinger Beacon-Dateien sehr gut.
* DESCRIPTION kann natürlich URLs (als Text) enthalten, evtl. benötigt wird aber ein Feld, das als Ersatz / Ergänzung zu DESCRIPTION auf eine Seite verweisen kann, die die Anwendung beschreibt oder auf das "reguläre" Benutzerinterface der Zieldatenbank verlinkt
* Besteht Bedarf, (die URL von) Icons (etwa http://www.lwl.org/westfaelische-geschichte/favicon.ico) oder Banner-artige(n) größere(n) Graphiken (etwa http://www.lwl.org/westfaelische-geschichte/portal/Internet/grafik/logo_wg.png) als Ergänzung von INSTITUTION / NAME zu transportieren? Wenn ja, muessten wohl Größenvorgaben gemacht bzw. Skalierungshinweise gegeben werden. -- Thomas Berger 11:38, 18. Apr. 2010 (CEST)
replies: text: Ist "@" wirklich günstig? -- Thomas Berger 17:06, 13. Apr. 2010 (CEST)
replies: text: Das ist an die RDF-Turtle-Syntax angelehnt, warum nicht? -- Nichtich 18:11, 13. Apr. 2010 (CEST)

text: Bei mehrspaltigen Ergebnisangaben erscheint dann dort auch evtl. sprachspezifischer Text. Wird mit @ recht kompliziert. Alternativvorschlag: Eine Beacon-Datei ist immer ausschließlich in einer Sprache. Die Sprachangabe wird festgelegt mit z.B.
 #LANGUAGE de
Andere Sprachversionen können durch folgende Angabe(n) integriert werden:
 #ALTLANG en=http://beacon.abc.org/beacon_en.txt
 #ALTLANG fr=http://beacon.abc.org/beacon_fr.txt
Die jeweilige Resolver-URL kann dann auch einfach für unterschiedliche Sprachausgaben angegeben werden. --Arch2all 12:00, 13. Sep. 2011 (CEST)
replies: text: Wäre das für einen Nachnutzer, der die Daten zur Einbindung in eine mehrsprachige Umgebung benutzt, nicht eher umständlich? Schliesslich hätte er mehrere redundante BEACON-Dateien zum im Prinzip gleichen Angebot kohärent zu halten. Die Methode mit getrennten BEACON-Dateien hat allerdings den Vorteil, auch die Kommentare oder Trefferzahlen in den ID-Zeilen lokalisieren zu können ("3 livres d'étude", "Special collections building"), das in einem einfachen Format zu parallelisieren stelle ich mir schwierig vor. -- Thomas Berger 13:10, 13. Sep. 2011 (CEST)
thread_title:  Offene Formatfragen 

message: Die einfache Beacon-Funktionalität nutzt #TARGET und Identifier, setzt aber u.U. einen dedizierten Redirect-Dienst voraus:
 [gvk.txt]
 #PREFIX: http://d-nb.info/gnd/
 #TARGET: http://ws.gbv.de/seealso/pnd2gso?format=redirect&id={ID}
 121827798|14
Das allgemeine Beacon-Format nutzt #TARGET u.U. überhaupt nicht:
 #NAME: Mathematics Genealogy Project
 #PREFIX: http://d-nb.info/gnd/
 11855090X|http://www.genealogy.math.ndsu.nodak.edu/id.php?id=7298
Dazwischen liegen Anwendungen, die zwar ebenfalls auf URL-Mustern basieren, aber nicht mit PND-Nummern:
 [gvkpndbeacon.txt]
 #PREFIX: http://d-nb.info/gnd/
 #TARGET: http://ws.gbv.de/seealso/pnd2gso?format=redirect&id={ID}
 #FEED: http://ws.gbv.de/beacon/gvkpndbeacon.zip
 121827798|14|http://gso.gbv.de/DB=2.1/REL?PPN=03531074X
 123033322|8|http://gso.gbv.de/DB=2.1/REL?PPN=060398744
 100000096|1|http://gso.gbv.de/DB=2.1/REL?PPN=076570819
Hier könnte eine Format-Erweiterung mit ALTernativ-#TARGET und -Identifiern eine Option sein, die Beacon-Datei kleiner zu halten und die Konkordanz der Identifier deutlicher zu machen:
 #PREFIX: http://d-nb.info/gnd/
 #ALTPREFIX: http://gso.gbv.de/{fingiert}/ppn/
 #TARGET: http://ws.gbv.de/seealso/pnd2gso?format=redirect&id={ID}
 #ALTTARGET: http://gso.gbv.de/DB=2.1/REL?PPN={ALTID}
 121827798=03531074X|14
 123033322=060398744|8
 100000096=076570819|1
Es ist also statt der bzw. als Ergänzung zur PND-Nummer die mit "=" dahinter notierte konkordante Identnummer für den Platzhalter {ALTID} im bei #ALTTARGET notierten Schema einzusetzen, um eine gültige URL zu erreichen. Gibt es in einer Zeile keine Alternativ-ID, so ist das #TARGET-Muster zu nutzen.
Dies könnte auch helfen, das unten diskutierte Problem der in manchen Katalogen ausschliesslich nachgewiesenen SWD-Nummern für Personendaten anzugehen (es folgt das Schema für eine veroderte Recherche nach PND- und korrespondierender SWD-Nummer in einem realen Katalog):
 #PREFIX: http://d-nb.info/gnd/
 #ALTPREFIX: http://d-nb.info/gnd/
 #TARGET: http://193.30.112.134/F/-?local_base=HBZ01&func=find-a&find_code=PND&request={ID}
 #ALTTARGET: http://193.30.112.134/F/-?local_base=HBZ01&func=find-a&find_code=PND&request={ID}&request_op=OR&find_code=SWD&request={ALTID}
 118607782=4052508-9
 121827798
 118540238=4021455-2
Mit Kenntnis der #ALTTARGET-URL könnten getrennten Beacon-Listen zu PND- und SWD-Nummern "extern" unter Zuhilfenahme der in der PND hinterlegten SWD-Nummern in dieses Konkordanzformat zusammengeführt werden und somit den zuverlässigen Zugriff auf gewisse Bibliothekskataloge erst möglich machen.
-- Thomas Berger 00:35, 19. Apr. 2010 (CEST)
replies: text: Zeichen mit Wert oberhalb von 127 müssen durch die einsetzende Anwendung URL-encodiert werden (sofern sie vorkommen), Zeichen unterhalb von 127 dürfen nicht umcodiert werden: Das hat die bereitstellende Anwendung bereits in jedem Fall durchgeführt.
Das ist etwas gruselig, aber die BEACON-Datei soll ja möglichst einfach zu erstellen sein, notfalls per Hand. Ob (siehe Wikpedia) "/" als "/" genutzt wird oder "%2C" werden muss, kann nur in Kenntnis der Anwendung entschieden werden; da es sich nur um wenige Zeichen handelt, bekommt der Ersteller das notfalls auch mit Ersetzungsbefehlen in der Textverarbeitung hin. Nicht-7bit-ASCII-Zeichen korrekt zu encodieren erfordert jedoch höheres Kopfrechnen für eine nicht beschränkte Anzahl von Zeichen. Ich sehe natürlich das Problem, dass es keine Standardroutinen für das vorgeschlagene Verfahren gibt.
Alternativ müsste der Header ein Zusatzfeld mit einer Liste der Zeichen enthalten, die zwar normalerweise "protected" sind, hier aber nicht umcodiert werden dürfen: Das ist aber sehr technisch und damit auch un-BEACON-mässig, und ob Spatien als "%20", "_" oder "+" zu codieren sind, ist damit auch nicht erklärt.
-- Thomas Berger 02:14, 28. Apr. 2010 (CEST)
thread_title:  Konkordanzformat 

message: #FORMAT: BEACON
 #PREFIX: urn:isbn:
 #ALTTARGET: http://de.wikipedia.org/wiki/{ALTID}
 #MESSAGE: Titel erwähnt in de.wikipedia.org
 #DESCRIPTION: Links auf Artikel in der Deutschsprachigen Wikipedia, die eine ISBN enthalten 
 9783777607368=Actinium|Actinium
 9783894726652=Ang_Lee|Ang Lee
 9783827405449=Cent_%28Musik%29|Cent(Musik)
 9783211782446=Abk%C3%BCrzungen/Gesetze_und_Recht|Abkürzungen / Gesetze und Recht
bzw. auch die laxere Form der letzten Zeile:
 9783211782446=Abkürzungen/Gesetze_und_Recht|Abkürzungen / Gesetze und Recht
Im allgemeinen Fall ist oft nicht klar, ob "/", ":" und andere geschützte Zeichen aus dem Identifier vor dem Einsetzen in das #TARGET-Muster URL-encodiert (%2C, %3A, ...) werden müssen oder keinesfalls dürfen: Das hängt von der Anwendung ab und kann bei "neumodischen" Identifiern ein arges Problem für das BEACON-Format darstellen. Hier im Konkordanzformat sind die Alternativ-Identifier spezifisch für die bereitstellende Anwendung und alles ist harmlos.
Ich schlage folgende Regelung für die Codierung der Alternativ-ID vor:
:Zeichen mit Wert oberhalb von 127 müssen durch die einsetzende Anwendung URL-encodiert werden (sofern sie vorkommen), Zeichen unterhalb von 127 dürfen nicht umcodiert werden: Das hat die bereitstellende Anwendung bereits in jedem Fall durchgeführt.
Das ist etwas gruselig, aber die BEACON-Datei soll ja möglichst einfach zu erstellen sein, notfalls per Hand. Ob (siehe Wikpedia) "/" als "/" genutzt wird oder "%2C" werden muss, kann nur in Kenntnis der Anwendung entschieden werden; da es sich nur um wenige Zeichen handelt, bekommt der Ersteller das notfalls auch mit Ersetzungsbefehlen in der Textverarbeitung hin. Nicht-7bit-ASCII-Zeichen korrekt zu encodieren erfordert jedoch höheres Kopfrechnen für eine nicht beschränkte Anzahl von Zeichen. Ich sehe natürlich das Problem, dass es keine Standardroutinen für das vorgeschlagene Verfahren gibt.
Alternativ müsste der Header ein Zusatzfeld mit einer Liste der Zeichen enthalten, die zwar normalerweise "protected" sind, hier aber nicht umcodiert werden dürfen: Das ist aber sehr technisch und damit auch un-BEACON-mässig, und ob Spatien als "%20", "_" oder "+" zu codieren sind, ist damit auch nicht erklärt.
-- Thomas Berger 02:14, 28. Apr. 2010 (CEST)
thread_title:  Noch ein Beispiel: 

message: * Formale Kontrolle des Headers: Feldnamen, Syntax der Werte (Zeitstempel, Mail-Adressen, Platzhalter), Pflichtfelder
* Formale Reparatur: Leerzeilen eliminieren, Zeilenumbrüche vereinheitlichen
* Kontrolle der Zeichencodierung (beim File-Upload können andere Ergebnisse herauskommen als beim automatisierten Heranholen über die FEED-Url...)
* Formale Kontrolle der Datenzeilen: Korrektheit der Identifier, "|"-Feldstruktur, dublette Identifier (Fehler, falls keine URI in der Zeile bzw. das Tupel dublett ist, Warnung sonst)
* Inhaltliche Kontroll- und Verbesserungsmöglichkeiten:
** Anhand einer (aus der PND ableitbaren) Konkordanz SWD-Nr. eines Personensatzes <-> PND-Nr. auch (gewisse) SWD-Nummern als Nicht-Identifier zu PND-Nummern "verbessern"
** Anhand der (in der PND satzweise hinterlegten) ungültigen PND-Nummern auf die aktuell gültige "umlenken" (erfordert erneute Untersuchung auf dublette Identifier)
** Anhand der Eigenschaft Tn/Tp der PND-Sätze die Nummern nichtindividualisierter Sätze ("Namenssätze" statt "Personensätze") monieren bzw. ausfiltern
-- Thomas Berger 17:23, 13. Apr. 2010 (CEST)
replies: text: Unter http://ws.gbv.de/beacon/validator ist jetzt ein erster Validator (ohne inhaltliche Kontrolle) -- Nichtich 10:52, 14. Apr. 2010 (CEST)

text: Zum Experimentieren sind folgende Mappings bereitgestellt: ungültig gewordene PND-Nummern zu individualisierten Sätzen (ca. 68500 Identifier aus MAB 016) sowie  SWD-Nummern zu PND-Sätzen (ca. 303.000 Identifier aus MAB 028c). -- Thomas Berger 10:59, 19. Apr. 2010 (CEST)
thread_title:  Anforderungen an einen Beacon-Validator 

message: Aus welchen Daten wird eigentlich die Commons-BEACON-Datei zusammengestellt? In den Commons konnte ich keine Angabe der PND entdecken. Sind das evtl. alle de.WP-Artikel mit PND, die auch über die Commons-Vorlage verfügen? Wie könnte man denn die restlichen, vielen, vielen Personen(kategorien) der Commons am besten einbinden? Ich wäre bereit, dort in größerem Ausmaß PND nachzutragen und die Kategorien so zu "taggen", wenn das gewünscht wäre. Allerdings sollte das für die bereits vorhandenen PND-Informationen dann erst einmal ein Bot erledigen. (Ich weiß aber nicht, inwieweit die Commons-Leute das gut finden; allerdings wäre die PND mit Link auf APPER-Tool ja durchaus ein Mehrwert, und im Notfall könnte man die Vorlage ja auch auf den Commons unsichtbar machen und nur im Quelltext die Daten hinterlegen.) --AndreasPraefcke ¿! 15:32, 20. Apr. 2010 (CEST)
replies: text: Deine Vermutung ist richtig: es geht über die Einbindung der Vorlagen Commons und Commonscat in de-Personenartikeln. Ich stimme auch zu, dass ein Taggen dort sinnvoll wär - und ein Bot das für die bisherigen übernehmen könnte. Da das aber eine recht große Aktion ist und ich absolut keine Ahnung von Commons-Policies habe, sollte das wohl dort irgendwo mal thematisiert werden und mit den dortigen Personen abgeklärt werden. Vor allem die Tatsache, dass die PND größtenteils für deutsche Nutzer interessant ist, ist evtl. ein Hinderungsgrund. Aber wie gesagt: das muss dort geklärt werden. --APPER\☺☹ 21:09, 20. Apr. 2010 (CEST)
replies: text: Richtig. Ich wollte nur erst die Grundlagen klären. Dass wir per Bot ja tausende von Library-of-Congress-Nummern auch ohne weiteren Aufwand einbinden können, wäre vielleicht ein Anreiz. Ich überlege mir mal einen Vorschlag bei den Commons. --AndreasPraefcke ¿! 22:57, 20. Apr. 2010 (CEST)
replies: text: commons:Commons:Village_pump#Authority data (PND, LCCN, VIAF etc.) --AndreasPraefcke ¿! 16:31, 21. Apr. 2010 (CEST)
thread_title:  Wikimedia Commons 

message: Ich hab mal eine BEACON-Datei für die in der Wikipedia vorhandenen Verweise auf das BBKL erstellt. http://www.andreas-praefcke.de/temp/BEACON-PND-BBKL.txt (hoffentlich stimmt das Format) Mittels einer selbstgebastelten Excel-Tabelle kann ich auch andere PND (ohne Wikipediaeintrag oder ohne BBKL-Vorlage in Wikipedia) schnell nachtragen und habe das mal für alle Personen "A bis Ad" getan. Ist diese Datei erwünscht und sinnvoll? Wenn ja, ergänze ich sie in nächster Zeit gerne. --AndreasPraefcke ¿! 15:37, 22. Apr. 2010 (CEST)
replies: text: Zugänglichmachung des BBKL ist meines Erachtens ein uraltes Desiderat (kann aber kein Zitat angeben ;-). Auf eine Angabe "#FORMAT: BEACON" im Header sollte wohl nicht verzichtet werden. Die Datei illustriert zwei Probleme mit dem allgemeinen BEACON-Format:
* #TARGET ist vorgeschrieben, aber hier sinnlos, da es keinen Resolver für die PND-Nummern gibt, sondern zu jedem Identifier ein individueller Link angegeben werden muss
* Die URLs folgen dennoch einem Muster "http://www.bbkl.de/{variabel}.shtml" das ausgenutzt werden könnte, um die Datei kompakter zu gestalten (siehe Abschnitt zu Konkordanzformat) -- Thomas Berger 01:09, 23. Apr. 2010 (CEST)
replies: text: Danke. Ich habe die fehlenden META-Felder jetzt angefügt. #TARGET habe ich, da Pflicht, eingefügt, aber leer gelassen. Ich mach mich dann in nächster Zeit mal an die Vervollständigung der Datei. Das kann natürlich eine Weile dauern, da noch über 11.000 Einträge übrig sind... --AndreasPraefcke ¿! 09:01, 23. Apr. 2010 (CEST)

text: Ja, das "Konkordanzformat" wäre wirklich sinnvoll. Die Datei wäre weniger als halb so groß und auch übersichtlicher. --AndreasPraefcke ¿! 00:25, 26. Apr. 2010 (CEST)
thread_title:  BBKL 

message: Mit welcher MIME-Angabe soll die BEACON-Datei denn am besten ausgeliefert werden? --Arch2all 11:55, 11. Sep. 2011 (CEST)
replies: text: Alle mit bekannten BEACON-Dateien werden als text/plain ausgeliefert. Es handelt sich ja um eine einfache Text-Datei und sie soll bei statischen Angeboten auch einfach so anbietbar sein: indem man eine entsprechende Text-Datei einfach auf den Server legt. Deshalb: text/plain. --APPER\☺☹ 14:18, 11. Sep. 2011 (CEST)
replies: text: Strenggenommen ist der Mime-Typ eine Komponente des Content-Type HTTP-Headers, im Fall von text/plain folgt oft noch "charset=...". Da gibt es manchmal einen unlösbaren Konflikt zwischen der Forderung "Beacon-Datei soll UTF-8 codiert sein" und der für Bereitsteller u.U. nicht beeinflussbaren Deklaration der ausgelieferten Daten als ISO-8859-1 durch den Webserver. Völlig konform und problemlos ist nur die folgende Konstellation: Datei UTF-8 codiert, Auslieferung mit dem Header "Content-Type: text/plain; charset=utf-8". -- Thomas Berger 15:50, 11. Sep. 2011 (CEST)
thread_title:  MIME-Typ 

message: Derzeit gibt es keine real existierende BEACON-Datei, die effektiv vierspaltig wäre, jedoch diverse Konstellationen dreispaltiger:
* "Fundstelle" / Ziellemma plus URL (26 Dateien, z.B. alle von Benutzer:AndreasPraefcke):
 101272359|423v: Der Kanzler|http://digi.ub.uni-heidelberg.de/diglit/cpg848/0842
* Zählung plus Lemma (2) / sonstig bemerkenswertes (1)
 115000178|1|Adam, Max
 100273971|17|Bernhard Sonnenberg
 100001394|63|076574415
Bei den "zweispaltigen" sieht es so aus:
* URL (1)
 118723642|http://www.zentralbibliothek.elk-wue.de/cms/startseite/literatursuche-kataloge/nachlaesse/g-k/knapp-albert/
* Lemma (2)
 143268430|Holtze (Holce), Joachim
* Zählung (12)
 134465210|660
Interessant ist dabei eigentlich nur der jeweils letzte Fall (dass es möglich sein soll, als letztes eine
URL anzugeben, steht ausser Frage).
Ich finde - wie schon mehrfach geäussert - das Konzept der "Zählung" in BEACON-Dateien nicht besonders prominent (hier immerhin 14 von 44 plus 37 "einspaltigen") und darüber hinaus die Idee, dass eine interessante Zählung aus einer unqualifizierten Zahl bestehen sollte, ziemlich kurz gedacht. Obwohl ich im vorigen Abschnitt versucht habe, Bedeutungsunterschiede zwischen den Annotationsmöglichkeiten "(differenzierte) Zählung" und "Ziellemma" herauszuarbeiten, bin ich eigentlich der Ansicht, dass ein einziges, völlig frei belegbares Annotationsfeld stets ausreicht, so dass auch das allgemeine BEACON-Format als "dreispaltig" festgezurrt werden könnte.
Als Desiderat sehe ich aber weiterhin das oben "Konkordanzformat" genannte, also irgendeine Möglichkeit, eine nicht-PND-Nummer (allgemein: irgendeine Identifier aus einem beliebigen System, der mit dem in der ersten Spalte notierten Identifier aus dem #PREFIX-System in Konkordanz gesetzt wird, das könnten auch PND-interne Umlenkungen etc. sein) bzw. sonstigen variablen URL-Bestandteil zu notieren, der in ein im Header anzugebendes Muster gestopft werden kann. Derzeit muss man entweder einen zusätzlichen Resolver aufsetzen oder die Datei mit den stereotypen URL-Bestandteilen aufblähen. Das letzte "dreispaltige" Beispiel oben ist so ein Fall (statt eines verständlichen Kommentars wird eine nützliche GBV-PPN exportiert, die dem Eingeweihten den Resolver zu umgehen hilft, aber wirklich nur dem Eingeweihten, denn es fehlen jegliche Zusatzinformationen). -- Thomas Berger 17:48, 13. Sep. 2011 (CEST)
thread_title:  ID-Zeielen: Spaltenzahl, Zählungen, Fremd-IDs 

message: Ich hätte gern eine klare Zusammenstellung, welche PND-Quellen
* a) im Appertool 
* b) im BEACON_Findbuch ausgewertet werden
Wenn man z.B. http://www.geschichtsquellen.de/repPers_00678.html findet, sollte man sofort feststellen können, wieso diese Quelle fehlt: (i) sie ist nicht bekannt, (ii) es gibt technische oder andere probleme mit der einbeziehung, (iii) apper & co. haben keine zeit/lust --FrobenChristoph 21:16, 24. Feb. 2012 (CET)
replies: text: [x] (iv) Zu dem Angebot ist keine PND/BEACON-Datei veröffentlicht (oder sonstwie bekannt). Mehr als  und  automatisiert beobachten ist mir bislang nicht eingefallen. -- Thomas Berger 22:35, 24. Feb. 2012 (CET)

text: Ob eine Quelle in mein Personendaten-Tool einbezogen ist, kann man unter  nachschauen. Aber natürlich wird eine BEACON-Datei benötigt, die es in diesem Fall anscheinend nicht gibt. --APPER\☺☹ 23:45, 26. Feb. 2012 (CET)

text: Der Vollständigkeit halber: Der Inhalt der SeeAlso-Webservices PND-AKS und "Toolserver-Supplement" wird auf ihren jeweiligen Basisseiten  und  aufgelistet, Details zum Ladestatus unter  bzw.  (Quelle: http://beacon.findbuch.de/). -- Thomas Berger 08:36, 27. Feb. 2012 (CET)
thread_title:  Kraut und Rüben 

message: Die Österreichische Nationalbibliothek nimmt "irgendwie" an der PND teil (siehe http://www.onb.ac.at/bibliothek/personennamendatei.htm ), aber ich finde im Katalog keinen Hinweis auf eine Benutzung der PND-Nummern, und eine BEACON-Datei gibt es ja auch nicht. Hat jemand Kontakt zur ÖNB und könnte mal nachfragen, ob da etwas möglich ist? --AndreasPraefcke (Diskussion) 10:59, 29. Mai 2012 (CEST)
thread_title:  ÖNB 

message: Mir ist heute ein Fehler bei den PND-Verlinkung von Wikisource aufgefallen:
* http://beacon.findbuch.de/seealso/pnd-aks?format=sources&id=117598712
* http://beacon.findbuch.de/seealso/pnd-aks?format=sources&id=116697164
* http://beacon.findbuch.de/seealso/pnd-aks?format=sources&id=116697172
Alle drei Links mit unterschiedlichen PNDs GNDs verlinken auf dieselbe Wikisource-Autorenseite Christian Moritz Rühlmann. Liegt sehr wahrscheinlich daran, dass alle GNDs im gesamten Artikel gesucht und gefunden werden und nicht, wie es vielleicht sein sollte, nur die eine aus der Personendaten-Infobox. --Das Robert      .... gibs mir! 12:47, 29. Mai 2012 (CEST)
replies: text: Hi. Das liegt an meiner BEACON-Datei () und du hast das Problem schon richtig erkannt. Hintergrund ist der, dass es ressourcenmäßig weit aufwändiger ist, die GND aus der Infobox zu lesen (für jeden Artikel muss der Quelltext vom Server geholt werden) als einfach die verlinkte GND zu bestimmen (steht in der Datenbank). Das ist natürlich in solchen Fällen leider unsauber, werde ich wohl überarbeiten müssen. Evtl. kann ich ein Zwischending finden (nur den Quelltext holen, wenn mehr als eine GND verlinkt), damit die Erstellung nicht zu aufwändig wird... --APPER\☺☹ 10:23, 30. Mai 2012 (CEST)
replies: text: Ok. Ich verstehe nur nicht so ganz, warum es Ressourcen-technisch aufwendiger ist. Im Grund wird doch Text nach der Infobox durchsucht und dann daraus die GND gezogen. Damit dürften weniger Ressourcen beansprucht werden, als wenn der gesamte Text nach einer 9 oder 10 stelligen Nummer durchsucht. Zudem gibt's eventuell das Problem, was passiert, wenn eine 9-stellige Nummer gefunden wird, die keine GND ist. Aber vielleicht sehe ich da Probleme, wo keine sind bzw. zu denen es bereits Lösungen gibt. ;) --Das Robert      .... gibs mir! 14:27, 3. Jun. 2012 (CEST)
replies: text: Derzeit wird nicht der Artikeltext angeschaut. Bei einigen Tausend Artikeln den Artikeltext von den Wikimedia-Servern zu holen und zu durchsuchen dauert einige Zeit (Minuten? Stunden?). Mediawiki (die Software hinter Wikisource) speichert aber alle Weblinks in einer Datenbank, auf die man schnell zugreifen kann. Im Prinzip lasse ich mir also Weblinks ausgeben, die mit d-nb.info/gnd/ anfangen - wenn es davon aber mehrere gibt, dann entsteht das Problem. Vermutlich wird die Lösung sein, den alten Weg für alle Artikel beizubehalten, bei denen es nur einen solchen Link gibt und bei den Ausnahmen mit mehreren solchen Links dann doch den Quelltext zu holen und manuell nachzuschauen... --APPER\☺☹ 16:51, 3. Jun. 2012 (CEST)
replies: text: Muss nochmal nachhaken. Die Links verweisen immer noch auf dieselbe Wikisource-Seite. --Das Robert      .... gibs mir! 19:58, 20. Sep. 2012 (CEST)
thread_title:  Fehler bei Wikisource 

message: Da das BEACON-Format etwas ungenau definiert und historisch gewachsen ist, habe ich nun mit einer genaueren Spezifikation begonnen und eine XML-Serialisierung hinzugefügt. Der aktuelle Entwurf enthält noch einige Lücken und steht als Snapshot in HTML bzw. in TXT zu verfügung. Letztendlich soll die Spezifikation irgendwann im Laufe des Jahres als RFC veröffentlicht werden. Der Quelltext ist in einem Github Repository verwaltet und wartet auf Ergänzungen, Korrekturen, Kommentare und Implementierungen: https://github.com/gbv/beaconspec / https://github.com/gbv/beaconspec/issues
-- Nichtich (Diskussion) 16:20, 30. Mai 2012 (CEST)
thread_title:  Endgültige Spezifikation von BEACON als RFC 

message: Hallo Leute,
Die MUGI stellt doch eigentlich schon selbst zweimal eine Beacon-Datei bereit (hier und hier). Dann könnten wir doch die nehmen, oder? Nicht dass ich was gegen Andreas' Arbeit hätte (die ist wie immer hervorragend ;o)), allerdings sind die vielleicht aktueller. Welche allerdings richtig ist, kann ich nicht sagen. Grüße, Das Robert      .... gibs mir! 15:39, 23. Jul. 2012 (CEST)
replies: text: Andreas hat glaube ich immer noch drei mehr... Aber apropos "stellt doch eigentlich schon selbst": Wo hast Du die Links denn her, ich habe sie auch nicht erg**geln können, nachdem ich wegen Deiner Meldung hier wusste, dass es sie gab? -- Thomas Berger (Diskussion) 23:11, 30. Jul. 2012 (CEST)
replies: text: Ich hatte die MUGI vor einiger Zeit angeschrieben, ob sie nicht das Verwalten ihrer Dateien übernehmen will, und sie hatte mir auch recht schnell die beiden Links zukommen lassen. Da das Ganze in Absprache mit Andreas ablief und er auch in CC gesetzt wurde, vermutete ich, dass er auch die Links bekam, weswegen ich meinte, er sich dann um die Einbindung kümmern würde, so dass ich mich nicht mehr drum gekümmert habe. Mir ist es nur vor Kurzem wieder in Sinn gekommen und war ein wenig verwundert, dass wir noch die externe von Andreas nutzen. Ok, vielleicht hätte ich das Ganze auch einfach besser kommunizieren sollen. ;) Naja ich hoffe, jetzt werden sie bald eingebunden. --Das Robert      .... gibs mir! 23:32, 30. Jul. 2012 (CEST)

text: Frag doch einfach mal direkt bei Andreas nach... --APPER\☺☹ 15:03, 31. Jul. 2012 (CEST)
thread_title:  MUGI 

message: Die Universitätsbibliothek Jena nutzt auch die GND: hier. Vielleicht sollte mal jemand Kontakt aufnehmen. --Das Robert      .... gibs mir! 11:39, 26. Sep. 2013 (CEST)
thread_title:  Universitätsbibliothek Jena 

message: Metagrid – das ist letztlich BEACON, nur ohne öffentliche Sichtbarkeit und freie Verwendbarkeit der Daten. Oder findet jemand einen Vorteil an diesem Konzept? --FA2010 (Diskussion) 12:49, 10. Jan. 2014 (CET)
replies: text: Nicht ganz, dieses Konzept wird im dort verlinkten Mini-PDF ja auch "dritter Weg" genannt: Vergleichbar scheint das eher der VIAF-Datenbank ohne VIAF zu sein: Es gibt wohl eine zentrale Datenbank, die die "Vernetzung" zwischen den individuellen Datenbanken mit ihren individuellen Identifiern realisiert und zudem (später?) die Pflege erlaubt, d.h. die einzelnen Institutionen können bei der Clusterung "ihrer" Daten nachhelfen. Inwieweit auch Personendaten zentral vorliegen oder zumindest recherchierbar sind bzw. ob auch Massenzuordnungen (etwa anhand der PND ;-) geleistet weren können, ist unklar. Der Charme des Ansatzes besteht darin, dass man sich nicht darüber ärgern muss, wenn man "seine" Personen nicht in einer Normdatei findet, und auch nicht irgendwie versuchen muss, sie dann dort unterzubringen. Man ordnet die Person einfach dem passenden Nachweis irgendeines Metagrid-Teilnehmers zu und schwupps ist sie vernetzt. -- Thomas Berger (Diskussion) 14:22, 10. Jan. 2014 (CET)
replies: text: Ja, aber man könnte ja in ebensolcher Weise auch BEACON-Dateien ohne Normdatei erstellen (sozusagen den eigenen Identifier als Normdatei-Eintrag verwenden). ---FA2010 (Diskussion) 18:59, 10. Jan. 2014 (CET)
thread_title:  Die Schweiz erfindet das Rad neu: Metagrid 

message: Neuer Abschnitt "Blogs": Angelegt und ein Beispiel eingetragen. Blogbeiträge werden, auch wenn sie wissenschaftlichen Anspruch haben, in der Regel nicht katalogisiert. Sie scheinen mir aber geeignet, am BEACON-Verfahren teilzunehmen. Hoffe damit, diese Sparte eröffnen zu können, und, falls nötig, auch die Diskussion darüber. (nicht signierter Beitrag von Harald Lordick (Diskussion | Beiträge) 20:40, 16. Mai 2015 (CEST)
thread_title:  Blogs 

message: Hallo Beacon-Mitstreiter,
ich habe heute einen technischen Vorschlag zur prominenteren Darstellung der Beacon-Datei in der WP gestellt. Siehe Wikipedia:Umfragen/Technische_Wünsche_2017/Lesen#Einbindung_der_Beacon-Datei_in_Personenartikeln. Konstruktive Vorschläge, Anmerkungen, Kritik ist gern gesehen. Grüße, --Das Robert      .... gibs mir! 10:51, 30. Mai 2017 (CEST)
thread_title:  FYI: Technischer Vorschlag für Beacon 

message: Danke für den Eintrag des Biographischen Handbuchs der Rabbiner. Leider scheint die Datenbank selbst gerade nicht zu funktionieren (http://www.steinheim-institut.de:50580/cgi-bin/bhr), aber es gibt die PDFs hier und man kann übrigens auch GNDs suchen per http://www.steinheim-institut.de/see-also/query.html?place=Lissa&kategorie1=GND&text1=118505777 und entsprechend. Reparator (Diskussion) 10:36, 17. Nov. 2017 (CET)
thread_title:  BHR 

message: wird gefunden auf https://beacon.findbuch.de/seealso/ts-resterampe?format=sources&id=131789422 --Historiograf (Diskussion) 19:51, 5. Feb. 2019 (CET)
thread_title:  http://www.best-istanbul-hotels.com/de/landesmuseumnet/ 

message: Die im März 2021 eingetragene BEACON-Datei "Personen in der DH(d) Konferenzbeiträge | Bibliografie" (Abschnitt Bibliographen, Nr. 27) wird bisher nicht vom BEACON-Findbuch ausgewertet. Was könnte der Grund dafür sein? Danke für eine Antwort und herzliche Grüße --Harald Lordick (Diskussion) 11:28, 25. Mär. 2022 (CET)
thread_title:  DH(d)-Bibliografie 

message: Anwendungen wie
http://beacon.findbuch.de/seealso/pnd-aks
http://beacon.findbuch.de/seemore/gkd-aks
http://beacon.findbuch.de/seemore/gnd-aks
damit nicht nutzbar.
Kennt jemand die Ursache? Evergreen Somerset (Diskussion) 9:42, 21. Apr. 2022 (CEST)
http://beacon.findbuch.de/ selbst läuft, aber das Zertifikat für https:// ist abgelaufen. Damit läuft die Einbindung in die meisten Seiten, die über https:// aufgerufen nicht mehr. Ich habe versucht, den Betreiber zu kontaktieren, aber keine der mir bekannten E-Mail Adressen ist funktionsfähig.
--78.55.39.198 12:31, 13. Mai 2023 (CEST)
thread_title:  http://beacon.findbuch.de nicht erreichbar 

message: Der Server ist leider erneut seit einiger Zeit offline. Diesmal scheint es aber mehr als ein abgelaufenes SSL-Zertifikat zu sein. Nameserveranfragen für beacon.findbuch.de fallen negativ aus. Kann jemand vielleicht den Betreiber kontaktieren oder ist über die Lage informiert?  Eine Denic-Abfrage zu findbuch.de bringt folgende Antwort:
Die Domain "findbuch.de" wurde am 03.02.2024 gelöscht und befindet sich derzeit in einer Karenzzeit (Redemption Grace Period - RGP).
Das hört sich gar nicht gut an. Hoffentlich ist es nur ein Domainwechsel und keine Einstellung des BEACON-Dienstes! 
--Arch2all (Diskussion) 14:37, 6. Feb. 2024 (CET)
replies: text: In Wikipedia_Diskussion:Normdaten#Beispiel_in_der_Einleitung_der_Projektseite_Normdaten_funktioniert_nicht hat sich der Betreiber gemeldet. --Wurgl (Diskussion) 16:23, 6. Feb. 2024 (CET)
thread_title:  beacon.findbuch.de offline!