In den letzten Wochen haben wir mit der Einbindung von Metadaten in Einzeltrefferanzeigen experimentiert. Unser Ziel war, das man die bibliographischen Daten eines Treffers möglichst komfortabel mit einem Klick in Literaturverwaltungssysteme wie Mendeley, Citavi, Zotero und RefWorks zu übernehmen können sollte. Alle vier betrachteten Systeme bieten dafür Browserplugins an, die Metadaten aus Webseiten im COinS-Format lesen können.
Medium: COinS
Context Objects in Spans (mehr und mehr), wie dieses Format aufgelöst heißt, erzeugen aus allen Datenfeldern eine URL, die in einem für den Endnutzer nicht sichtbaren <span>-Element als Titelattribut untergebracht wird (kann man auf https://generator.ocoins.info/ selbst ausprobieren)
Für meinen Blogartikel über Protoyping aus dem April 2011 käme dabei folgendes heraus
Zunächst zur besseren Lesbarkeit die gewählten Felder vor der URL-Enkodierung:
Key | Value |
ctx_ver | Z39.88-2004 |
rft_val_fmt | info:ofi/fmt:kev:mtx:dc |
rft.title | Prototyping – the old school way |
rft.creator | Wonke-Stehle, Jens |
rft.subject | Prototyping |
rft.description | Ein Bericht über die Nutzung von Papierprototypen zur Entwicklung des Rechercheportals ViFaPol. |
rft.date | 2011-04-20 |
rft.type | Generic |
rft.format | Text |
rft.source | https://projektakte.sub.uni-hamburg.de/user-studies/prototyping-the-old-school-way/ |
rft.language | Ger |
und nun als CoinS:
<span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc& rft.title=Prototyping+%E2%80%93+the+old+school+way&rft.creator=Wonke-Stehle%2C +Jens&rft.subject=Prototyping&rft.description=Ein+Bericht+%C3%BCber+die+ Nutzung+von+Papierprototypen+zur+Entwicklung+des+Rechercheportals+ViFaPol.& rft.date=2011-04-20&rft.type=generic&rft.format=text&rft.source= http%3A%2F%2Fprojektakte.sub.uni-hamburg.de%2Fuser-studies%2Fprototyping-the-old- school-way%2F&rft.language=ger"> </span>
Datenschema: Dublin Core
Wie man am Wert dc in der Zeile
rft_val_fmt info:ofi/fmt:kev:mtx:dc
erkennen kann, verwenden wir ein Dublin Core Metadatenschema. Alternativ wären für COinS auch Schemata rein für Monographien oder Artikel möglich gewesen, da wir aber einen einheitlichen Weg gehen wollten (Ein Schema für alle Dokumententypen), werden wir diese Unterscheidung über des „type“-Element treffen.
Der Krise beibringen, auf den Namen Chance zu hören…
In Zukunft wollen wir Mikroformate portalweit für die ViFaPol einführen. Als Testfall haben wir eDoc.ViFaPol, unseren auf OPUS 3.2 basierenden Dokumentenserver ausgewählt. Die Einbindung von COinS war erstmal kein Problem. Was uns aber Nerven gekostet hat, war das Testen der Darstellung der übermittelten Metadaten durch die Literaturverwaltungssysteme. Zunächst erschien es, als gäbe es große Abweichung und als würden einige Felder hartnäckig misinterpretiert (vor allem der Dokumententyp). Der Lösung sind wir dann durch systematischen Austausch von Teilen des Quelltextes der Einzeltrefferanzeigen näher gekommen: sowohl Mendeley als auch Zotero können über CoinS hinaus auch Daten aus <meta>-Tags im <head>-Berich von HTML-Seiten auslesen und bevorzugen diese vor später im Quelltext auftauchenden Auszeichnungen.
Beispiel:
<meta name=“DC.Creator“ content=“Wonke-Stehle, Jens“>
<meta name=“DC.Date“ content=“2011″>
<meta name=“DC.Format“ content=“text“>
<meta name=“DC.Source“ content=“https://projektakte.sub.uni-hamburg.de/ user-studies/
prototyping-the-old-school-way/“>
<meta name=“DC.Language“ content=“ger“>
<meta name=“DC.Title“ content=“Prototyping – the old school way“>
<meta name=“DC.Type“ content=“generic“>
Und nun?
Ein wenig Anpassung muss noch geschehen. Zudem deutet sich u. a. auf schema.org eine weitere Möglichkeit an: die Einbindung von Mikroformaten rein mit Mitteln von HTML5…
[…] Literaturverwaltungssystemen und Repositorien zu vereinfachen: Jens Wonke-Stehle schreibt im @kte20.09-Weblog über COinS und deren Implementierung in […]
[…] Der Testfall ist der OPUS-Server eDoc.ViFaPol. Wer sich dafür interessiert, erfährt bei @kte 20.09 […]