Basis für die hier dokumentierten Punkte war eine Diskussion auf dem DINI AG KIM Workshop am 11. April 2012.

Anforderungen

• Cross-Konkordanzen müssen öffentlich im Web zugänglich sein
• Die Cross-Konkordanzen müssen einen hohen Grad an Aktualität besitzen. Bei Änderungen wäre ein wöchentliches/monatliches Update wünschenswert.
• Die Institution, die die Cross-Konkordanten erstellt hat, muss deren Bereitstellung sowie Aktualität wahren.
• Zeitstempel für Erstellung jeder Konkordanz angeben

Vorgestellte Optionen

1. Etablierung eines zentralisierten Konkordanzmanagementsystems in dem alle Konkordanzen eingespielt und auf Plausibilität geprüft, kooperativ gepflegt und harmonisiert bereitgestellt werden
   • Wurde als nicht erstrebenswert eingeordnet
2. Separate Bereitstellung von Cross-Konkordanzen im Web durch die jeweilige Institution
   • Wurde als erstrebenswert eingeordnet
   • Als potentielle Plattform für die Registrierung und Hinterlegung der URL der Cross-Konkordanz wurde CKAN empfohlen

Mögliche Bereitstellungsarten

Bereitstellung im Beacon-Format

Vorteile

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

Bereitstellung als Linked Data

Vorteile

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

Nachteile

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

Offene Punkte

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