Wikipedia Diskussion:BEACON

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)

Erfahrung aus der Praxis

-- Thomas Berger 22:44, 12. Apr. 2010 (CEST) -- Nichtich 16:19, 13. Apr. 2010 (CEST)

Was alles schiefgehen kann

• 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)

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)

Best Current Practice

• 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)

• Das Feld #REVISIT angeben, zumindest wenn die BEACON-Datei seltener als einmal wöchentlich erstellt wird

• Das Feld #EXAMPLES mit mindestens einem Identifier ausstatten, um schnell die Funktionsfähigkeit an einem typischen Beispiel testen zu können

• Zeitstempel (in #TIMESTAMP und #REVISIT) menschenlesbar angeben

• das Feld #CONTACT in der normierten Syntax name <name@domain.tld> angeben

• Angaben zum Umfang der eigenen Datenbank und der BEACON-Datei wenn überhaupt in das #DESCRIPTION-Feld setzen, nicht nach #MESSAGE

• Wenn zu einer Datenbank mehrere BEACON-Dateien bereitgestellt werden, die unterschiedliche "Aspekte" erschliessen, sollte auch das #DESCRIPTION-Feld dies reflektieren (vgl. den Vorschlag unten zu #NAME)

• Die #FEED-URL sollte einen HTTP-Header "Last-Modified" liefern, der dann mit If-Modified-Since abtestbar ist und überflüssiges Laden einer unveränderten Datei vermeiden hilft. Auch wenn die BEACON-Datei dynamisch aus einer Webanwendung generiert werden kann, ist es meist besser, sie regelmäßig selbst zu generieren und in einer statischen Datei abzulegen, deren Adresse dann im #FEED-Feld veröffentlicht wird.

• Wenn die BEACON-Datei dynamisch generiert wird, und (davon ist dann in der Regel auszugehen) kein HTTP-Header "Last-Modified" gesendet wird bzw. stets das aktuelle Datum, dann sollte die BEACON-Datei unbedingt einen #REVISIT-Header enthalten.

• Bei umfangreichen BEACON-Dateien den eigenen Webserver so konfigurieren, dass die Dateien an geeignete Clients transparent komprimiert übertragen werden (cf. mod_deflate von Apache, das über .htaccess auch per Verzeichnis aktiviert werden kann)

• Wenn eine (allgemeine) BEACON-Datei mehrere Nachweise zu einer PND-Nummer listet (also mehrere Zeilen mit abweichenden expliziten URLs), sollte in den betroffenen Zeilen eine "Beschreibung" stehen, damit nicht bei Weiterverarbeitung mehrere gleichlautende (#MESSAGE) Links mit unterschiedlichen Ziel präsentiert werden:

137311699|Kunibert, Bischof v. Köln (7. Jh.)|http://www.bbkl.de/k/kunibert_b_v_k.shtml
137311699|Kunibertus, Heiliger (660)|http://www.bbkl.de/k/Kunibertus.shtml

Formatdiskussion

zu PND/BEACON und BEACON, mir scheint es derzeit günstig, das hier zusammenzuhalten. -- Thomas Berger 01:09, 19. Apr. 2010 (CEST)

Offene Formatfragen

• 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)

• Wie könnte man Sprachvarianten (der Meta-Felder) in einer Beacon-Datei codieren?

Indem der META-Name um den Sprachcode erweitert wird:

#NAME@de Bibliothekskatalog
#NAME@en library catalog
#NAME@en-GB library catalogue

Ist "@" wirklich günstig? -- Thomas Berger 17:06, 13. Apr. 2010 (CEST)

Das ist an die RDF-Turtle-Syntax angelehnt, warum nicht? -- Nichtich 18:11, 13. Apr. 2010 (CEST)

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)

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)

• Semantisches Problem zu #PREFIX: Das Prefix http://d-nb.info/gnd/ gilt für alle Normdaten-Identnummern aus PND, SWD und GKD: Die Identifier der drei Normdateien waren seit jeher überschneidungsfrei vergeben worden, da die Trennung (und v.a. der redundante Simultan-Nachweis ein- und derselben Entität in mehreren Normdateien) als zu überwindender Zwischenzustand erkannt worden war. GKD, SWD, PND bzw. verstärkt noch die hier vor allem interessierende PND-Untermenge der individualisierten Personen sind also nur Sets innerhalb des grossen Identifierbestands "GND". Die Frage ist nun, ob in einer BEACON-Datei formal gekennzeichnet werden sollte, dass es sich um Daten/Identifier zu Personen handelt und nicht etwa um Namen, Sachbegriffe oder Verkehrswege. -- Thomas Berger 01:09, 19. Apr. 2010 (CEST)

Konkordanzformat

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)

Noch ein Beispiel:

#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)

Anforderungen an einen Beacon-Validator

• 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)

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

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)

Wikimedia Commons

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)

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)

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)

commons:Commons:Village_pump#Authority data (PND, LCCN, VIAF etc.) --AndreasPraefcke ¿! 16:31, 21. Apr. 2010 (CEST)

Zur Zeit wird das in Commons intensiv betrieben: dort heißt die Vorlage inzwischen commons:Template:Authority control. --AndreasPraefcke 12:31, 13. Sep. 2011 (CEST)

BBKL

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)

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)

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)

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)

Zu den Diskussionen

Hi. Derzeit gibt es hier viele Diskussionen zu Formaten und dabei geht alles durcheinander. Das BEACON-Format war als einfaches Format gedacht und wenn alles wie hier beschrieben umgesetzt würde, würde eine simple Implementierung schon sehr umfangreich sein. Das Konkordanzformat halte ich für sinnvoll.

Zu den anderen Sachen: Der Einfachheit halber ist es sehr wichtig, dass die Zeilenformate nicht bei jeder Anwendung eine andere Bedeutung haben - man verliert schnell den Überblick und dann gibt es eine Zeile, die zwei Bedeutungen haben kann... ein Graus ist mir:

137311699|Kunibert, Bischof v. Köln (7. Jh.)|http://www.bbkl.de/k/kunibert_b_v_k.shtml
137311699|Kunibertus, Heiliger (660)|http://www.bbkl.de/k/Kunibertus.shtml

Da sieht jeder Mensch, was die URL ist, aber was bedeutet das andere und wo stehen die Anzahl Treffer, falls relevant? Das Format der PND-Zeilen ist bisher so, dass die einzelnen Parameter mit | getrennt werden, dabei sollten wir bleiben - auch dass der erste Wert eine PND ist, halte ich im PND-BEACON-Format für sinnvoll. Der zweite Parameter ist die Anzahl Treffer, auch dieser sollte IMMER angegeben werden, wenn die Treffer irrelevant sind, dann einfach leer lassen. Also: "123456789||weiteres...".

Weiterhin würde ich für alle weiteren Parameter ein allgemeines Variablenformat vorschlagen: also: "123456789||url=http://www.xyz.de/abc|name=Hans Meier". Diese "Variablen" kann man dann in bestimmten Feldern einsetzen: z.B. "#TARGET: {url}" oder "#MESSAGE: Eintrag für {name} im BBKL". Damit wäre natürlich auch das Konkordanzformat enthalten. Was haltet ihr von dem Vorschlag? Vergleich:

#TARGET: 
#MESSAGE: Eintrag im Biographisch-Bibliographischen Kirchenlexikon (BBKL)
100009603|Amos, Johann Baptist (1688-1777)|http://www.bbkl.de/a/amos_j_b.shtml
100010385|Alter, Franz (1749-1804)|http://www.bbkl.de/a/alter_f.shtml

neu:

#TARGET: http://www.bbkl.de/a/{k}.shtml
#MESSAGE: Eintrag zu {n} im Biographisch-Bibliographischen Kirchenlexikon (BBKL)
100009603||n=Amos, Johann Baptist (1688-1777)|k=amos_j_b
100010385||n=Alter, Franz (1749-1804)|k=alter_f

Mir ist bewusst, dass so in jeder Zeile wieder "n=" und "k=" angegeben wird, aber ich denke, dass dies das Parsing stark vereinfacht - natürlich wäre denkbar eine Zeile "#LINEFORMAT: n, k" oder sowas, aber wie gesagt: das Format sollte so einfach wie möglich bleiben! Was haltet ihr davon? Ist irgendeine der komplexeren Ideen von oben nicht umsetzbar? --APPER\^☺☹ 13:33, 12. Mai 2010 (CEST)

Klingt gut. Und wäre für mich natürlich keinerlei Problem, das in 1 Minute zu ändern. --AndreasPraefcke ¿! 13:47, 12. Mai 2010 (CEST)

Habe selbst ziemlich geflucht, als ich den Parser für die ID-Zeilen gemäß allgemeinem Beacon-Format gebaut habe: Zu erkennen, was ein Feld bedeutet, hängt ungut damit zusammen, was man für die benachbarten Felder bereits erkannt hat und daher ausschliessen muss.

Die Trefferzahl isoliert zu bevorzugen halte ich aber für problematisch: Oft ist sie irrelevant (Wikipedia) oder sie bietet sich zur Differenzierung an, selbst in Bibliothekskatalogen: "13 von, 20 über". Im Nachlassbereich bietet sich eine Differenzierung nach Materialarten an: "2 Bestände, 14 Werkmanuskripte, 700 Briefe" gegen "1 Erwähnung". {hits} ist also oft auch nur ein Freitext und keine glatte Zahl...

Andererseits sollte es eine Verabredung für gewisse "Kernelemente" geben: Wenn #MESSAGE nicht gegeben ist bzw. jemand bei der Verarbeitung darauf verzichten möchte, sie zu zeigen, sollten Vorzugs-Kürzel für gewisse Sachverhalte festgelegt sein:

• Art/Umfang/Ausmaß (also die {h[its]})
• Benennung ({n[ame]}?)
• individuelle Adresse ({u[rl]})

womit wir zusammen mit {i[d]} wieder bei den vier ausgezeichneten Feldern des allgemeinen Beacon-Formats wären. Gibt es noch mehr Kandidaten für optionale aber dennoch "zentrale" Elemente?

Eine Wiederholbarkeit, also mehrere "Spalten" mit demselben Kürzel halte ich für nicht notwendig -- Thomas Berger 15:41, 12. Mai 2010 (CEST)

Am Beispiel des Portraitkatalogs der UStB Köln gab es möglicherweise etwas zu lernen: Hier stehen die Nachweise stellvertretend für die Personen, weil die Beziehung "oft genug" 1:1 ist (manchmal mehrere Personen auf einem Portrait, manchmal mehrere Portraits derselben Person) und daher gibt es parallel zur Beschreibung auch die Web-Version des Beschriebenen: Katalognachweis und Image, im allgemeinen Fall mag man an Thumbnails denken.

#FORMAT: BEACON
#VERSION: 0.1
#MESSAGE: Portrait in der Sammlung der USB Köln
#PREFIX: http://d-nb.info/gnd/
#TARGET: http://beacon.findbuch.de/portraits/ps_usbk?format=redirect&id={ID}
#ALTTARGET: http://kug.ub.uni-koeln.de/portal/connector/permalink/portrait/{ALTID}/1/index.html
#IMGTARGET: http://portraitsammlung.ub.uni-koeln.de/digiarchive/portrait/{ALTID}/portrait_web.jpg
129416339=193|Kupferstich, 1721

Möglicherweise ist es verkürzt gedacht, dass BEACON primär zur Verlinkung auf die nachgewiesenen Ressourcen dient, die "Kernelemente" sollten aber so reich sein, dass die Information auch für dekorierte Links ausreicht, d.h. graphische Links wie in diesem Fall oder auch Logos. Die Text-Variante des Links kann dann ziemlich kanonisch als "title"-Attribut des Links oder "alt"-Attribut des Images untergebracht werden, wenn der BEACON-Verarbeiter Graphiken zeigen möchte.

Ich sehe dann eine weitgehende Parallelität zwischen den Elementen:

Funktion	individuell	schematisch	generisch
Linkziel	letzte Spalte / u[rl]=	#TARGET mit ID-Platzhalter	VERBOTEN?
Linktext	zweite/dritte Spalte / n[ame]=	#MESSAGE mit hits-Platzhalter	#DEFAULTMESSAGE
Graphik	[i]mage=	#IMAGE mit ID-Platzhalter	#DEFAULTIMAGE

Es gibt also in den Beacon-Zeilen Standardspalten für die volle Information, sind die leer, wird anhand von Standardelementen aus dem Beacon-Header und einer Platzhalter-Syntax eine Konstruktion versucht. Funktioniert auch dieses nicht (weil ein? über den/die Platzhalter referenziertes Element der Beacon-Zeile ebenfalls nicht vorliegt, kommen Default-Elemente aus dem Header zum Zuge.

Worüber ich mir noch nicht im klaren bin:

• welche Meta-Informationen zu den Images (Mime-Typ, Dimensionen, ...) sind nützlich (ich gehe allerdings davon aus, dass sie beim Erstellen einer BEACON-Datei nicht einfach ermittelbar sind und daher typischerweise fehlen werden, auch wenn das Format es "unterstützt").
• Evtl. macht es durchaus einen Unterschied, ob eine (individuelle) "Vorschau" oder ein (generisches) "Logo" (der bereitstellenden Institution) herauskommt, letzteres würde eine Applikation u.U. zusammen mit dem Text darstellen. "#DEFAULTIMAGE" sollte daher wohl nicht die Funktion eines noch einzuführenden Header-Elements "#ICON" (korrespondierend zu #INSTITUTION oder #NAME) übernehmen.

Man könnte die Sache auch so sehen: Tendenziell jeder Text aus dem Beacon-Header (#INSTITUTION, #CONTACT, ..., #MESSAGE(!) wird begleitet von optionaler URL und optionaler (URL einer) Graphik, [meinetwegen wird auch jede URL im Header (#FEED, #TARGET(!)) von einem optionalen Text begleitet], evtl. kann das durch Namensgebung der Header-Elemente oder durch eine kombinierende Syntax herausgearbeitet werden. Dass #TARGET und #MESSAGE eigentlich fast gleich heissen sollten ist natürlch etwas unintuitiv und un-BEACON:

#INSTITUTION: |n=Portraitsammlung der Universitäts- und Stadtbibliothek Köln
              |u=http://portraitsammlung.ub.uni-koeln.de/
              |i=http://portraitsammlung.ub.uni-koeln.de/images/openbib/favicon.ico
#TARGET: |u=http://kug.ub.uni-koeln.de/portal/connector/permalink/portrait/{j}/1/index.html
         |n=Portrait in der Sammlung der USB Köln
         |i=http://portraitsammlung.ub.uni-koeln.de/digiarchive/portrait/{j}/portrait_web.jpg
129416339|j=193|n=Kupferstich, 1721

-- Thomas Berger 09:52, 7. Jun. 2010 (CEST)

Wenn das einfache BEACON-Format nicht ausreicht, sollte es nicht immer komplizierter gemacht werden, sondern gleich auf eine XML, JSON, oder RDF-basierte Variante umgestiegen werden. Das Format ist jetzt schon kompliziert genug. -- Nichtich 14:03, 19. Okt. 2010 (CEST)

Eigentlich geht es in diesem Abschnitt (noch) gar nicht um ein Format, sondern um das Datenmodell von BEACON: Was könnte bereitgestellt werden (sollte transportierbar sein), um Bereitsteller (Branding!) und Nachnutzer (Klickibunti?) zusammenzubringen. Da scheint mir der derzeitige allgemeine BEACON-Entwurf bei der informellen Beschreibung noch nicht vollständig genug (#DESCRIPTION, #COMMENT), evtl. auch bei der formaleren (URL zu #INSTITUTION und zur Beschreibung der konkreten Datenbank, evtl. Transport von Logos), dafür ist der #xxxMESSAGE-Bereich m.E. überdifferenziert und zu sehr auf klassische Kataloge von Universalbibliotheken getrimmt. Im Auge behalten muss man ausserdem SeeAlso, als prototypisches Vehikel von BEACON-Daten zum Endnutzer: Die JSON-Struktur der OpenSearchSuggestions erlaubt exakt drei (aus BEACON-Daten durch den Webservice konfektionierte) Datenelemente zu transportieren, davon ist eines als der weiterführende Link recht stark festgelegt. -- Thomas Berger 14:35, 19. Okt. 2010 (CEST)

Sollen/dürfen auch nicht-PND-beacons in CKAN abgelegt werden? Ich hätte eine interessante (Bibliothekssigel (resp. ISILs) zu Wikipedia-URLs). -- PascalC 16:26, 5. Jul. 2011 (CEST)

MIME-Typ

Mit welcher MIME-Angabe soll die BEACON-Datei denn am besten ausgeliefert werden? --Arch2all 11:55, 11. Sep. 2011 (CEST)

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)

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)

GKD verwendbar ?

Dürfen in BEACON-Dateien auch GKD-Nummern (für Organisationen) verwendet werden? Der Resolver der Nationalbibliothek kommt ja jedenfalls damit zurecht (z.B. http://d-nb.info/gnd/18740-9 ) und in den WP-PND templates werden sie auch oft statt PNDs verwendet (gleiches Beispiel Deutsches_Archäologisches_Institut) --Arch2all 10:20, 12. Sep. 2011 (CEST)

Zunächst einmal richtet es keinen Schaden an, schlimmstenfalls fällt die Nummer als formal nicht korrekt auf und wird ignoriert. Günstigstenfalls wird nie jemand nach der Nummer fragen, weil die Anwendung im Bereich von Personendaten liegt, so gross ist der Unterschied also nicht. Nächstes Jahr, wenn die Normdateien stärker konvergiert sein werden, werden die Nummern noch weniger unterscheidbar sein (Im Hinblick darauf hat die DNB seit jeher darauf geachtet, dass die Nummern der diversen Normdateien sich nie überschneiden, eine unerwartete GKD-Nummer in irgendeinem Kontext kann also nie mit einer PND- oder SWD-Nummer verwechselt werden und unsinnige Resultate liefern). Und vielleicht gibt es ja irgendwann auch einmal Anwendungen für BEACON-Dateien im Körperschaftsbereich. In der Vorlage:Normdaten wird übrigens zwischen den Parameter PND=... und GKD=... differenziert, Körperschaftsnummern in der (veralteten) [[Vorlage::PND]] sind ein bekanntes Phaenomen, den Autoren ging es meist darum, auf egal welchem Weg einen Link zum Katalog der DNB zu erzwingen...

Am Beispiel von Architekturbueros sieht man, dass die Trennung zwischen Personen und Korporationen nicht für alle Anwendungen ideal ist, ich persönlich bin aber der Meinung, dass Anwender und Anwendungen trotz der obigen "Konvergenz" und aller sonstigen Ähnlichkeiten zischen den Konzepten auch in Zukunft eine Trennung zwischen Personen und Institutionen als Bestandteil ihrer Weltsicht beibehalten werden. Insofern sollte man die (interne) Kontrolle darüber, was was ist, nicht vorschnell aufgeben, auch wenn es die GND kaum noch interessiert. -- Thomas Berger 15:34, 12. Sep. 2011 (CEST)

Gut, interessanterweise steht im GND-Artikel, daß ab 2012 PND (und GKD+SWD) als eigenständige Datenbanken sogar gänzlich aufgelöst werden sollen. Und wenn es bei den Nummern keine Überschneidungen gibt, sollte das BEACON-Projekt vielleicht besser als GND (statt PND)-BEACON bekannt gemacht werden. So könnte man sogar noch den Schlagwortkatalog SWD mit integrieren ohne das Projekt jedesmal umbenennen zu müssen. --Arch2all 20:29, 12. Sep. 2011 (CEST)

Ich schließe mich dem oben Geschriebenen an. Für BEACON-Dateien spielt es meiner Meinung nach keine große Rolle, ob es nur PNDs, nur GKDs oder SWDs sind. Da man diese als Teile der GND unterscheiden kann, ist eigentlich eine "GND-BEACON" sinnvoll. Bei Seiten, die nur Infos zu Personen haben, werden halt nur BEACON-Dateien mit PNDs angeboten, aber archinform ist ja ein gutes Beispiel für eine Webseite, die Info-Seiten über Personen und auch Körperschaften hat. Ich halte es für kein Problem, das alles zu integrieren.

Wenn man sich die aktuelle Formatbeschreibung anschaut, sieht man auch, dass "#FORMAT: PND-BEACON" sowieso veraltet ist und durch die zwei Zeilen "#FORMAT: BEACON" und "#PREFIX: http://d-nb.info/gnd/" ersetzt wurde. Dadrin steckt ja implizit schon, dass auch GKDs und SWDs erlaubt sind (siehe PREFIX-Zeile). Das BEACON-Format ist noch in der Entstehung und ich vermute, dass die meisten, die die Dateien nutzen, diese Formatzeilen gar nicht auswerten. Ich finde das neue Format auch sinnvoller und es sollte - solange es noch wenige BEACON-Dateien gibt - darauf hingearbeitet werden, alte Formate zu entfernen.

Also aus meiner Sicht unterstützen BEACON-Dateien das heute schon, nur die Doku sagt das hier noch nicht, weil es halt bisher keinen Anwendungszweck gab. In dem Zusammenhang fänd ich auch eine Verschiebung der Seite zu WP:BEACON sinnvoll. --APPER\^☺☹ 21:33, 12. Sep. 2011 (CEST)

Ich habe BEACON-basierende Dienste auch zu ISBN und ISSN aufgesetzt, etwa [1] (ISBN, Beacon-Dateien zur internen Verarbeitung) oder http://beacon.findbuch.de/downloads/tictocs-issnbeacon.txt (ISSN). Innerhalb der GND wird es allerdings leicht problematisch: In der bibliothekarischen Sacherschliessung genutzte Personen haben sowohl eine PND- als auch eine SWD-Nummer, je nach Katalogisierungskontext darf nur die eine oder nur die andere Nummer genutzt werden. Um die Nummern miteiander zu identifizieren, benötigt man Kenntnis des entsprechenden Normsatzes, selbst viele Lokalsysteme von Bibliotheken können das nicht leisten. Demnächst wird auch noch eine genuine GND-Nummer hinzukommen, Altsätze werden also bis zu drei äquivalente Nummern tragen, plus noch ggfls. beliebig viele "Verlierernummern" aus Dublettenbereinigungen. Vermutlich wird irgendjemand dann eine BEACON-Waschmaschine aufsetzen, die eine BEACON-Datei auf die jeweils aktuellen Vorzugsnummern umsetzen kann.-- Thomas Berger 22:20, 12. Sep. 2011 (CEST)

Meine Interpretation von "#FORMAT: PND-BEACON" ist vor allem, dass nur das zweispaltige Format "ID|hits" erlaubt ist, nicht das allgemeine vierspaltige. Ob eine Nummer eine "echte" PND-Nummer ist, lässt sich kaum verifizieren, v.a. wo ja sowieso nie die volle PND die Anwendungsdomäne war, sondern das Subset der (individualisierten) Personensätze im Gegensatz zu den nichtindividualisierten Namenssäzten. Daher kann man "#PREFIX: http://d-nb.info/gnd/" als Namespace-URI verstehen, d.h. Format und Bedeutung der genutzten Identifier sind damit geklärt (Bibliothekarische Normdaten einer bestimmten Provenienz). Die Bedeutung der Beacon-Datei als solcher ist damit m.E. unbefriedigend festgelegt, A interessiert sich z.B. für Ressourcen zu Personen und fängt sich aus Versehen eine Datei ein, die nur Bauwerke (anhand ihrer SWD-Nummer als Subset der GND) nachweist. Da passiert natürlich nichts Schlimmes (zu keiner der Nummern wird er je sich selbst eine Frage stellen), aber A hätte von vorneherein auch die Finger von B's Datei lassen können. Die GND wird im Feld 079 Codierungen zum Entitätstyp ($b: Person, Name, Körperschaft, ...) tragen sowie dreistellige Codes zur weiteren Untergliederung ($v: Familie, "moderner" Name, Bauwerk, Verkehrsweg etc., vgl. [2]). D.h. einerseits wird durch die Einführung der GND formattechnisch mehr in einen Topf geworfen, andererseits differenzierter ausgesagt, was die jeweilige Entität ist. Vermutlich werden wir uns irgendwann eine geeignete Ontologie aussuchen müssen und ein (optionales) Header-Feld einführen, in der man das dann unterbringt. -- Thomas Berger 22:20, 12. Sep. 2011 (CEST)

Wo genau ist eigentlich das "allgemeine vierspaltige" definiert? Ich sehe derzeit immer mal wieder verschiedene Formate (vor allem dreispaltige) und habe vorhin auch die Format-Seite angepasst, um zumindest zum Teil den aktuellen Dateien gerecht zu werden, aber für das allgemeine Format habe ich leider noch keine Beschreibung gesehen.

Zur Unterscheidung von PND/GKD etc.: Ich halte es bei einer Seite wie archinform für nicht sonderlich sinnvoll, mehrere Dateien anzubieten (für PND, SWD, GKD...). Idealerweise sollte aber irgendwo abgelegt sein, welche Inhalte eine BEACON-Datei enthält. Da ja "falsche" Einträge kein Problem sind, reicht dazu meiner Meinung nach ein zusätzliches Meta-Feld, in dem auf irgendeine Weise abgelegt ist, mit welchen Inhalten zu rechnen ist. Eine Pro-Zeile-Festlegung ist m.E. nicht nötig. Also sowas in der Art "#ENTHÄLT: Personen, Körperschaften"... aber natürlich irgendwie formaler (und sprachunabhängig bzw. englisch). Auf Seiten wie dieser, auf denen Listen von BEACON-Dateien gepflegt werden können zusätzlich Freitextinfos abgelegt werden. Für die Zukunft (wenn es sehr viele BEACON-Dateien gibt), wäre aber ein automatisch lesbares Format sinnvoller. Sodass man dann filtern kann "BEACON-Dateien, die Personen enthalten". --APPER\^☺☹ 22:57, 12. Sep. 2011 (CEST)

Zum vierspaltigen Format: Benutzer:APPER/BEACON/Format#ID-Zeilen (der letzte Kasten in dem Abschnitt: "Sondersammlung" ist übrigens ein ungünstig doppelbödiges Beispiel ("wo sind die Treffer" ist nahe an "was sind das für Treffer": 3 Briefe, 5 Bauwerke), einige Beacon-Dateien führen z.B. den in ihrer Anwendung genutzten Namen der Person auf und ich sehe den Bedarf, das keineswegs mit der Spalte "Treffer in engerem oder weiterem Sinne" zu verschmelzen)

Zu archINFORM: Ack. Derzeit bereits sollte das #DESCRIPTION-Feld Raum genug bieten um zu beschreiben, dass (und auf was) zu Personen und Körperschaften der Zugriff ermöglicht wird. Ein Problem sehe ich eher für alle anderen Dateien, die beim Übergang von "PND-BEACON" zu "BEACON" ihre Header daraufhin überprüfen müssen, ob hinreichend klar wird, dass es um Personen geht und nicht um andere GND-Entitäten (Häh?). Das "irgendwie formaler" hatte ich mit Ontologie gemeint, #ENTHÄLT / #CONTENTS ist gefährlich, da schreibt dann spätestens der zweite "Bereich Gartenbau" hinein, weil zufällig aus dem Namen der Sammlung bereits klar ist, dass es sich um eine Sammlung von landwirtschaftlichen Geräten handelt und der Drang, jedes optionale Feld so zu (um-)interpretieren, dass es ausgefüllt werden kann, ist erfahrungsgemäss sehr stark.

Das #DESCRIPTION-Feld der archINFORM-Beacondatei wurde jetzt von mir entsprechend ergänzt. --Arch2all 14:58, 16. Sep. 2011 (CEST)

Noch eine Anmerkung: "PND" ist in den diversen nichtbibliothekarischen Communities inzwischen eine ziemlich bekannte "Marke". Wir sollten den Begriff nicht leichtfertig aufgeben und lieber beobachten, wie sich der Sprachgebrauch nächstes Jahr entwickelt, wenn die GND Realität geworden ist. -- Thomas Berger 23:50, 12. Sep. 2011 (CEST)

ID-Zeielen: Spaltenzahl, Zählungen, Fremd-IDs

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)

Kraut und Rüben

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)

[x] (iv) Zu dem Angebot ist keine PND/BEACON-Datei veröffentlicht (oder sonstwie bekannt). Mehr als [3] und [4] automatisiert beobachten ist mir bislang nicht eingefallen. -- Thomas Berger 22:35, 24. Feb. 2012 (CET)

Ob eine Quelle in mein Personendaten-Tool einbezogen ist, kann man unter [5] 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)

Der Vollständigkeit halber: Der Inhalt der SeeAlso-Webservices PND-AKS und "Toolserver-Supplement" wird auf ihren jeweiligen Basisseiten [6] und [7] aufgelistet, Details zum Ladestatus unter [8] bzw. [9] (Quelle: http://beacon.findbuch.de/). -- Thomas Berger 08:36, 27. Feb. 2012 (CET)

Beispiele für SWD und GKD

Ich sehe hier viele Beispiele mit PNDs, also mit biographischen Inhalten. Leider konnte ich noch kein Pendant mit Schlagwörtern oder Körperschaften finden und suche Datenbanken, die mithilfe einer Beacondatei ihre Schlagwörter ausgeben. Bei archInform ist es für mich beispielsweise nicht erkennbar, ob es so gehandhabt wird. Oder ganz simpel formuliert: Wo finde ich Datenbanken, die SWD und GKD nutzen? --82alex 21:04, 27. Feb. 2012 (CET)

Die simple Frage ist die Grundlegende: Die SWD, insbesondere ihr Kern aus Sachschlagworten (also Personen, Werke, Körperschaften, Geographika beiseite), ist vor allem in großen Universalbibliotheken verbreitet, auch wenn Museen sich (für Objektdokumentation) ab und zu interessiert zeigen. Akzeptanzprobleme sind da bereits vom Ansatz her eingebaut, denn gerade spezialisierten Institutionen ist die SWD möglicherweise nicht differenziert genug und mit Rücksicht auf ihre Nutzer orientieren sie sich ohnehin eher an Fachthesauri. Die SWD hat einiges an Werken (auch wenn sie Bauwerke gerne als Körperschaft auffasst), das hängt aber stark vom Fach ab: Für Musikwerke gibt es traditionell eine Einheitstiteldatei des DMA, die Hürden für literarische Werke oder solche der bildenden Kunst sind recht hoch (typischerweise muss erst eine Monographie darüber geschrieben worden sein, damit eine Universalbibliothek das Schlagwort benötigt). Die in der BEACON-Datei von archinform mit "4" oder "7" beginnenden Nummern sind solche von SWD-Sätzen.

Die GKD, ursprünglich eine Hilfsdatei der Zeitschriftendatenbank (die meisten Zeitschriften haben institutionelle Herausgeber) ist auch für Graue Literatur extrem nützlich. Museen und Galerien als Akteure im Kunstbetrieb sind z.B. in der GKD recht gut abgedeckt (wegen der Begleitpublikationen zu Ausstellungen) und einige Kunst- und Museumsbibliotheken dürften die GKD für ihre Erschließungen extensiv nutzen. Strenggenommen sind auch die einzelnen Ausstellungen als "Events" Objekt der GKD, da ist die Abdeckung aus verschiedenen Gründen eher gering. Über die Integration des DMA sind viele Klangkörper und Bands in die GKD gekommen, außerhalb der GKD gibt es noch eine Normdatei zu Plattenlabeln (normierte Verlagsdateien hingegen sind ein seit jahrzehnten diskutiertes aber nie realisiertes Desdierat bei den Bibliotheken). Musikduos oder Architekturbüros (selbst wenn sie unter persönlichen Namen agieren) sind normalerweise in der GKD (hier ist die Lage also ganz anders als bei Autorenduos mit oder ohne Pseudonym), bei archinform dürften insbesondere alle Nummern, die nicht mit "1", "4" oder "7" beginnen, Architektennachweise aus der GKD sein.

Es gibt also tatsächlich einige Bereiche, wo auch die Normdaten jenseits der PND eine interessante Breite abdecken und eine über den Nutzen bei der Katalogisierung von Büchern hinausgehende identifizierende Bedeutung haben. Da könnten also nichtbibliothekarische Einrichtungen "andocken", so wie es bei der PND geschehen ist. Bekannt ist mir da allerdings nichts, Kandidaten wären Datenbanken zur Dokumentation des zeitgenössischen Kulturbetriebs, etwa im Umfeld von european-art.net (auf "Partner" klicken), oder Musikalienprojekte (die DINI-AG-KIM etwa hat maschinell ein Mapping GKD -> NusicBrainz erstellt, auf derselben Seite übrigens auch ein Mapping SWD -> GeoNames). -- Thomas Berger 09:24, 28. Feb. 2012 (CET)

Vielen Dank. Mir geht es speziell um Editionen aus dem historischen Bereich. Nimmt man als Schlagwort beispielsweise den "Versailler Vertrag", könnte man doch dort wunderbar die SWD 4063141-2 einbauen. Werden nur spezielle Paragraphen benötigt, können diese eine eigene SWD-Nummer zugewiesen bekommen, oder? Wenn ich das richtig verstanden habe, sollte es über eine SWD-Beacondatei bzw. ihrer graphischen Ausgabe anschließend möglich sein, unterschiedliche Editionen zu vernetzen. --82alex 13:18, 28. Feb. 2012 (CET)

Ganz und gar nicht: Das Schlagwort wird traditionell vergeben, wenn der Vertrag Thema ist (Literatur über Genese, Rezeption, Folgen, Verwandtes, Verschiedenes...). Heutige Editionen sind allerdings selten unkommentiert und isoliert, viele Bibliotheken sind findig genug, dafür die Schlagwortkombination "Versailler Vertrag" / "Quelle" zu vergeben: Dann sind aktuelle Editionen immerhin dabei, Nicht-Editionen lassen sich aber nicht ausgrenzen () (weitere Probleme am Rande: das separat angesetzte SW "Saarstatut <1919>" als Teil(?) davon; SWD-basierte Verschlagwortung geht i.A. nicht weiter als bis in die späten 1980er Jahre zurück; Aufnahme als (zu kleiner), "unselbständiger" Teil in größeren Editionsprojekten). Um Werke selbst zu identifizieren, dient der Einheits(sach)titel (EST), in diesem Fall ist das anscheinend das im SWD-Satz nicht einmal erwähnte "Conditions de paix des puissances alliées et associées": Damit findet man auch im DNB-Katalog allerhand, Einschlägiges, das ohne das Wort "Versailles" auskommt (etwa die Volksausgabe. Beim Admiralstabsdruck ist der EST allerdings "Conditions of peace" :-(). Zukünftige bibliothekarische Regelwerke wollen die diversen Ausgaben von Werken stärker zueinander bringen (Stichwort FRBR) und vermutlich wird dann recht schnell eine internationale Einheitstiteldatei aufgebaut werden. Die kann man sich dann durchaus als Normdatei vorstellen, und anders als bei den jetzigen Einheitstiteln, die in den Bibliotheksdaten nur Zeichenketten als bessere Fußnote sind, dürfte da zeitgleich eine Infrastruktur mit Identifiern und Resolvern entstehen. Derzeit kann man nur auf WorldCat verweisen (dort wird - wegen der Vielzahl der integrierten Kataloge - massiv maschinell an der Zusammenführung von Ausgaben gearbeitet) oder auf LibraryThing, wo die Benutzer selber Ausgaben zusammenführen (für Quelleneditionen passt die Zielgruppe leider nicht, ich habe gerade mal einen Treffer gefunden). Die Schlagwortsätze zu Werken als Thema dürften in Zukunft hoffentlich ebenfalls in diese Einheitssachtiteldatei integriert werden. D.h. das eine der oben bei der SWD-Nutzung angesprochenen Probleme, dass Identifier nicht unbedingt zwischen "von" und "über" bzw. hier zwischen "Ausgabe" und "Kommentar" unterscheiden, wird sich nicht unbedingt auflösen: Aber a priori zu entscheiden, dass das Zusammenführen von Ausgaben legitimer Zweck ist und das Zusammenführen von Sekundärliteratur hingegen nichts gilt und dafür bitteschön andere Identifier erfunden werden müssen, wäre ziemlich weltfremd und dreist. -- Thomas Berger 15:29, 28. Feb. 2012 (CET)

Zur Verdeutlichung etwas Theoriefindung: Es geht nicht um "SWD ist falsch, EST ist richtig", die Abschaffung der Dichotomie durch Konvergenz der Normdateien wird das Dilemma noch verschärfen, dass die Aussage "Diese Ressource steht in Zusammenhang mit dem Versailler Vertrag" die Motivation des Aussagenden ("... weil sie ein ihn kommentierender (juristischer, sozialwissenschaftlicher, historischer,) Aufsatz ist", "... weil sie (Biographie, Lexikoneintrag, ... ) eine(r) daran beteiligten Person ist", "... weil seine Allegorisierung (eines der) Element(e) ihrer ikonographischen Beschreibung ist") nicht transportiert. Eine solche Aussage als "Zeile" einer BEACON-Datei reflektiert immerhin schon den(?) Kontext, in den der Bereitsteller durch seine Aktivitäten (Sammeln, dokumentieren, Bibliographieren, ..., jeweils aufgrund formaler, inhaltlicher, ... Kriterien) "seine" Ressourcen stellt und der sich aus den Header-Zeilen zu "Institution". oder "Name" (der Datenbank, der Sammlung, des Projekts) oft erahnen lässt. Der "Message"-Header (oder ebenfalls "Institution" bzw. vor allem "Name") hingegen erlaubt u.U. weitere Rückschlüsse auf eine eventuell gemeinsame (formale oder inhaltliche) Natur der beschriebenen Resourcen ("in Deutschland erschienene Literatur zu", "juristische Literatur des 20. Jhd.", "Biographie", "Karikaturen in Presseerzeugnissen", "Ausgaben und Editionen", "Materialien zur Ortsgeschichte", "x Autographen, y Bestände")

Ein Nutzer von BEACON-Dateien (also jemand, der eine oder mehrere auswertet und die Resultate in Form von Links in sein eigenes Angebot "einbindet") vollzieht praktisch eine De- und partielle Rekontextualisierung der bezeichneten Ressourcen, ganz einfach weil er nur Angebote zu Identifiern anbieten kann, die er selber kennt und zu denen es in seinem Angebot eine Ressource gibt (irgendwo müssen die einzubindenen Links ja plaziert werden, dafür braucht es mindestens den Anzeigekkontext eines Registereintrags o.ä.). Die Eingrenzung auf "passende" Ressourcen ist oft gar nicht erwünscht und erfordert "redaktionelle" Auswahl zumindest der einzubindenen BEACON-Dateien, im Extremfall sogar eine Sichtung aller einzelnen Ressourcen (das wäre dann die bewusste "Übernahme" einzelner Verlinkungen und eine vollständige Rekontextualisierung). BEACON-Dateien, die "völlig daneben" liegen machen glücklicherweise keine Mühe, wenn die in einer Datei aufgelisteten Identifier keine Schnittstelle zu denen "meiner" Sammlung haben, wird sie im Rahmen meines Angebots auch niemals wirksam werden.

Im konkreten Fall ist es nach meiner Einschätzung nun so, dass BEACON-Dateien mit SWD-Identifiern als Nachnutzung/Extrakte bereits exisiterender Datenbanken nur aus dem Bereich der Bibliothekskataloge zu erwarten sind. Dort wird "SWD" aber auf eine bestimmte, einheitliche Art und Weise genutzt, mit Gewissheit kann man (seit 198x erworbene) Literatur über juristische Verträge erwarten, mit etwas Glück auch zusätzlich (seit 198x erworbene) Ausgaben und Editionen derselben. "EST"-Identifier gibt es derzeit außerhalb der Musikalien nicht und - da die Normdatei erst seit drei Jahren überhaupt sichtbar und recherchierbar ist - vermutlich gibt es außerhalb der DNB keine Anwendung, die die Identifier einsetzt. Das heisst, selbst wenn es zu jeder existierenden Datenbank SWD- und EST-BEACON-Dateien gäbe, wäre der Nutzen - und sei es nur als Steinbruch für eine eigene Datensammlung - für ein Projekt "Editionen historischer Verträge" außerordentlich gering: Viel eigentlich Vorhandenes wird fehlen (und kann auch nicht durch einfaches Verfolgen hypothetischer Links auf "ähnliches" in den Zielsystemen ermittelt werden), dagegen wird (zwangsläufig durch unterschiedliche Motivation bei Bereitsteller und Auswerter) sehr viel "unbrauchbares" dabei sein.

Wenn aber umgekehrt eine Art "Bibliographie historischer Verträge" entsteht, dann können SWD-Identifier durchaus ein legitimes Werkzeug der Erschließung sein (auch wenn das strenggenommen nicht vorgesehen ist, weil "der" Zweck der SWD die Umsetzung eines speziellen Erschließungsregelwerks (RSWK) ist und diese Nutzung in diesem Kontext nicht regelgerecht ist: Ich glaube nicht dass es möglich ist, ein System von Identifiern für einen bestimmten Nutzungszweck zu reservieren), vorausgesetzt, die SWD ist geeignet (weil Verträge dort erstens Entitäten sein können und zweitens darin auch bereits genügend viele Verträge vorkommen, so dass sich die Beschäftigung damit lohnt, denn das allfällige Ergänzen (oder Ergänzen lassen) Fehlender ist ein mühsames Geschäft... -- Thomas Berger 12:45, 29. Feb. 2012 (CET)

ÖNB

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)

Fehler bei Wikisource

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)

Hi. Das liegt an meiner BEACON-Datei ([10]) 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)

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)

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)

Muss nochmal nachhaken. Die Links verweisen immer noch auf dieselbe Wikisource-Seite. --Das Robert .... gibs mir! 19:58, 20. Sep. 2012 (CEST)

Endgültige Spezifikation von BEACON als RFC

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)

MUGI

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)

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)

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)

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

Habe keinerlei Problem damit, bitte selbstverständlich die offiziellen nehmen und meine rausnehemen. Wenn so etwas klappt, dann ist die Mission erfüllt. Ich bin doch ein notorisch schlechter Mailleser... --AndreasPraefcke (Diskussion) 21:20, 1. Aug. 2012 (CEST)

Neue Übersicht?

Das Projekt wächst und gedeiht prächtig, was mich außerordentlich freut. Dadurch leidet aber die Übersichtlichkeit etwas unter den vielen Projekten. Könnten wir (also AndreasPraefcke oder Gymel ;-) ) eine separate Übersichtsseite in tabellarischer Form oder als Datenbank über alle teilnehmenden Projekten erstellen? Folgende Infos wären hilfreich:

• Link zur Beacon-Datei
• Beispiellink
• Ansprechpartner (!) mit E-Mail (vielleicht kann das auch direkt in die Beacon-Datei?)
• Datum des "Beacon-Eintritts"
• Anzahl der Datensätze
• Art der Institution (Archiv, Personendatenbank, etc.)
• Art der Beacon-Bereitstellung (offiziell/direkt, inoffiziell/indirekt)
• Anmerkungsfeld

Dann müsste nicht jedes Mal hier ein neuer Edit durchgeführt werden, wenn sich die Zahl der Einträge verändert hat, und man kann stattdessen diese Seite für Koordination, Optimierungen, Debugging etc. nutzen. --Das Robert .... gibs mir! 20:55, 26. Mär. 2013 (CET)

Die Anzahl der Beiträge ist ja nicht ständig zu aktualisieren, sondern soll nur eine grobe Idee geben, ob eine Datei 50 oder 500.000 Einträge hat. --FA2010 (Diskussion) 21:11, 26. Mär. 2013 (CET)

Die Anforderungen sind nicht abwegig – als Anforderung an das BEACON-Format, also die Header in BEACON-Dateien (bis auf das Datum der Erstveröffentlichung vielleicht). Die Tücke steckt allerdings im Detail: Ansprechpartner gibt es mehrere (Institution, inhaltlich Verantwortliche, BEACON-Ersteller, Hoster, ...), "Datensätze" ist als Konzept für bestimmte Ressourcen evtl. noch nicht einmal tauglich, bei "Art" ist fallweise eines oder mehreres aus Institution, konkrete Datenbank, von der BEACON-Datei getroffener Ausschnitt interessant, bei Erstellung / Bereitstellung gibt es viele möglicherweise interessante Fakten, eine "Anmerkung" ist jedenfalls nicht verkehrt. Die derzeitige Gliederung nach der überwiegenden formalen Natur der Nachweise in den Zieldatenbanken ist grob genug, um halbwegs trennscharf zu sein und sie hat den Charme echten Mehrwerts, denn für solche Quellengattungen gibt es wohl keinen Thesaurus/Vokabular/Ontologie und selbst wenn wäre es illusorisch anzunehmen, dass die entsprechenden Terme von den allen Erstellern konsistent in alle jeweiligen BEACON-Dateien eingetragen werden würden. -- Thomas Berger (Diskussion) 21:38, 26. Mär. 2013 (CET)

@FA2010: Aber dennoch wird es gemacht ;) Generell wäre doch eine schöne Übersicht schön und hilfreich und letztlich ließe sich doch eine solche maschinell recht schnell anfertigen, oder?

@Thomas: Die Erstveröffentlichung habe ich nur aus Gründe der Neugierde genannt ;) und mit "Datensätze" meinte ich einfach lediglich die bereitgestellten Beiträge (unabhängig von ihrem Konzept). Da ja wir der Initiator des Beacon-Projekts sind, ist es doch an uns, dieses jetzt zu normieren (bevor es zu spät ist). Somit könnte aus dem "halbwegs trennscharfen" System ein trennscharfes werden. Womit wir bei den Ansprechpartnern wären: Dazu müssen wir nur eindeutig definieren, was ein Ansprechpartner für Technik/Host/Inhalt ist (dann gibt es eben im Header ein #CONTACT_CONTENT:, #CONTACT_HOST: etc.). Und wenn es nicht möglich ist, all diese Informationen möglichst trennscharf in den Header zu packen, macht sich eine externe Datenbank gut, was wiederum der von dir angesprochenen Artenvielfalt von Bereitstellung und Quellengattungen zu Gute kommt. Aber letztlich geht es mir hier erst einmal nicht um eine Normierung des Beacon-Formats (das ist ein ganz anderes Thema), mir geht es lediglich um eine bessere, sich ständig aktuell haltende Übersicht, schon alleine um der Außenwirkung willen. --Das Robert .... gibs mir! 22:46, 26. Mär. 2013 (CET)

Zur Normierung siehe Beitrag von Nichtich weiter oben, wovon ich allerdings nur http://d-nb.info/gnd/4129465-8 verstehe. --FA2010 (Diskussion) 13:43, 27. Mär. 2013 (CET)

Universitätsbibliothek Jena

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)

Die Schweiz erfindet das Rad neu: Metagrid

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)

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)

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) PS: Metagrid erinnert auch ein bisschen an die Interwiki-Links, wenn Wikidata nicht frei einsehbar wäre.

Sei es wie es will, aber eines ist doch unstrittig: Metagrid sollte aus seinen Daten BEACON-Dateien generieren und bereitstellen, soweit die Projekte das nicht selbst tun. Vor allem für alle Relationen GND -> x. --FA2010 (Diskussion) 19:11, 10. Jan. 2014 (CET)

Wikidata

Ich habe vorgeschlagen, dass Wikidata automatisiert BEACON-Dateien zur Verfügung stellt. Hier ist der "Bug" report: https://bugzilla.wikimedia.org/show_bug.cgi?id=60366 Ich bitte um Kommentare bzw. Votes. --AndreasPraefcke (Diskussion) 10:47, 23. Jan. 2014 (CET)

Das ist von Benutzer:Magnus Manske vor einiger Zeit implementiert worden und als http://tools.wmflabs.org/wikidata-todo/beacon.php verfügbar.

Zudem hat Magnus eine Art Universal-Resolver für Wikidata aufgesetzt, mittels Identifiern aus frei wählbaren Systemen können URLs konstruiert werden, die beim Aufruf auf das entsprechende Wikidata-Item weiterleiten: http://tools.wmflabs.org/wikidata-todo/resolver.php und Beispiel für GND(=P227)-Nummer 4206818-6. Die Möglichkeit, dies durch Angabe eines weiteren Parameters mit einem (bzw. einer Liste von) Sprach- bzw. Wikimedia-Projektkürzel direkt auf Artikel weiterleiten zu lassen ist noch Desiderat. -- Thomas Berger (Diskussion) 01:28, 15. Jan. 2015 (CET)

Google Books

War mir nicht bekannt, dass Google Books über eine Sitemap verfügt (http://archiv.twoday.net/stories/714908483/). Lässt sich das für BEACONs nutzen? Oder ist es überhaupt sinnvoll, in diese Richtung zu überlegen, da eigentlich alle Nicht-Google-Projekte Probleme haben, neben GB wahrgenommen zu werden?

Unterhalb von "Biography" scheinen in den verschiedenen Abteilungen zusammen etwa 100 Bücher aufgeführt zu werden, wo mag der Rest sein? -- Thomas Berger (Diskussion) 21:37, 10. Mär. 2014 (CET)

Hab' noch nicht nachgezählt;) Aber unter http://books.google.com/sitemap/Sitemap/Unclassified.html scheint sich einiges zu verbergen...

Blogs

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))

FYI: Technischer Vorschlag für Beacon

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)

BHR

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)

http://www.best-istanbul-hotels.com/de/landesmuseumnet/

wird gefunden auf https://beacon.findbuch.de/seealso/ts-resterampe?format=sources&id=131789422 --Historiograf (Diskussion) 19:51, 5. Feb. 2019 (CET)

DH(d)-Bibliografie

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)

http://beacon.findbuch.de nicht erreichbar

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)

beacon.findbuch.de offline!

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)

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)