Seitenhistorie

...

• Einfache Darstellung, die entsprechend einfach zu verarbeiten ist
• Etabliertes Format mit weiter Verbreitung

Nachteile

• Pro Relationstyp muss separate Datei angelegt werden, da in BEACON immer nur eine Beziehungsart im Header definiert werden kann (Beispiel GND-DDC für die vier Determiniertheitsgrade müssen vier Dateien angelegt werden)

...

• Alle Konkordanzen zu einer Entität können auf einmal angegeben

Nachteile

• In Resource Description eingebettet und damit schwer zugreifbar solange kein SPARQL angeboten

...

• Ein Ansatz zur Kombination von Cross-Konkordanzen verschiedener Anbieter konnte nicht gefunden werden.
• Es fehlt ein Mechanismus um intellektuell festgestellte Fehlzuordnungen festzuhalten. Diese könnten insbesondere maschinellen Abgleichverfahren dazu dienen, auftretende Fehlzuweisungen nicht erneut auszuweisen.
• Widersprüchliche Aussagen in verschiedenen Cross-Konkordanzen können nicht aufgelöst werden.
• Es fehlt an einer Ausweisung der Qualität für Cross-Konkordanzen (intellektuell erschlossen durch Experten, Leihen etc., maschinell erschlossen)

Weitere Notizen

(Joachim Neubert, z.B. auch aufgrund nachgelagerter Kneipendiskussionen)

1. Aktualisierung gemappte Datensets

Bei großen Datensets, oder solchen, die ohne feste Versionen laufend aktualisiert werden, ist eine Aktualisierung durch Laden des jeweils aktuellsten Download Files oder durch stumpfes Crawling nicht möglich. Daher müssten solche Datensets einen Mechanismus bereitstellen, mit dem interessierte Parteien nach dem initialen Laden eines Dumps Aktualisierungen abrufen können. Dieser könnte z.B. in Atom-Feeds bestehen, wie sie die schwedische Nationalbibliothek und die Library of Congress benutzen (s. z.B. http://id.loc.gov/authorities/subjects - weitere Erläuterungen und Diskussionen dazu s.a. http://listserv.loc.gov/cgi-bin/wa?A1=ind1204&L=id): Das Format ist standardisiert, einfach zu verstehen, es gibt ensprechende Programmbibliotheken und Aggregatoren zur Verarbeitung etc. Mögliche Alternativen: OAI-PMH (eher bibliotheksspezifisch).

2. Übernahme von Mappings in die Zieldatensets

Nach dem das Mapping aktualisiert wurde (entweder auf einem eigenständigen System, oder auf dem Pflegesystem eines der beteiligten Datensets), müssten die neuen oder geänderten Mapping-Sätze in beide oder in das jeweils andere Zielsystem übernommen werden. Das kann über Push- oder Pullmechanismen geschehen: Wenn das Pflegesystem des Zieldatensets einen Updatemechanismus per Webschnittstelle bereitstellt (z.B. per SRU-Update), könnte das von dem System aus erfolgen, auf dem das Mapping gepflegt wird. In der Regel setzt das eine feingranulare Rechtevergabe auf dem Zielsystem voraus, da ja lediglich die Felder für das Mapping selbst, aber nicht die kompletten Datensätze aktualisiert werden dürfen.
Alternativ könnte das Mappingpflegesystem z.B. Beacon-Dateien mit den Mappings bereitstellen, mit die Zielsysteme Updates auf ihren Bestand fahren können (komplettes Ersetzen aller existierenden Mapping-Einträge auf dem Zielsystem?).

3. CKAN als Registry für Mappings/Crosskonkordanzen

CKAN.net/The Data Hub ist ein bereits breit genutztes Repository mit guter Softwareunterstützung, keine Eintrittsschwelle (jede/r kann selbst Eintragungen vornehmen), hoher Anreiz (aus diesen Daten wird die  generiert). CKAN bietet ein mächtiges API für eigene Auswertungen, Einbindung in Portalseiten etc.
Ansätze, separate Linksets/Mappings (auch in BEACON) in CKAN.net zu verzeichnen, gibt es bereits (z.B. http://thedatahub.org/dataset/pndbeacon). Eine Konvention, die beide verknüpften Datensets eindeutig bezeichnet und mit weiteren Metadaten eines Linksets verknüpft, scheint es auf CKAN.net noch nicht zu geben (nachfragen/diskutieren auf http://lists.okfn.org/mailman/listinfo/ckan-discuss).