Jakoblog — Das Weblog von Jakob Voß

Some thoughts on IIIF and Metadata

Yesterday at DINI AG Kim Workshop 2017 I Martin Baumgartner and Stefanie Rühle gave an introduction to the International Image Interoperability Framework (IIIF) with focus on metadata. I already knew that IIIF is a great technology for providing access to (especially large) images but I had not have a detailed look yet. The main part of IIIF is its Image API and I hope that all major media repositories (I am looking at you, Wikimedia Commons) will implement it. In addition the IIIF community has defined a „Presentation API“, a „Search API“, and an „Authentication API“. I understand the need of such additional APIs within the IIIF community, but I doubt that solving the underlying problems with their own standards (instead of reusing existing standards) is the right way to go. Standards should better „Do One Thing and Do It Well“ (Unix philosophy). If Images are the „One Thing“ of IIIF, then Search and Authentication are different matter.

In the workshop we only looked at parts of the Presentation API to see where metadata (creator, dates, places, provenance etc. and structural metadata such as lists and hierarchies) could be integrated into IIIF. Such metadata is already expressed in many other formats such as METS/MODS and TEI so the question is not whether to use IIIF or other metadata standards but how to connect IIIF with existing metadata standards. A quick look at the Presentation API surprised me to find out that the metadata element is explicitly not intended for additional metadata but only „to be displayed to the user“. The element contains an ordered list of key-value pairs that „might be used to convey the author of the work, information about its creation, a brief physical description, or ownership information, amongst other use cases“. At the same time the standard emphasizes that „there are no semantics conveyed by this information“. Hello, McFly? Without semantics conveyed it isn’t information! In particular there is no such thing as structured data (e.g. a list of key-value pairs) without semantics.

I think the design of field metadata in IIIF is based on a common misconception about the nature of (meta)data, which I already wrote about elsewhere (Sorry, German article – some background in my PhD and found by Ballsun-Stanton).

In a short discussion at Twitter Rob Sanderson (Getty) pointed out that the data format of IIIF Presentation API to describe intellectual works (called a manifest) is expressed in JSON-LD, so it can be extended by other RDF statements. For instance the field „license“ is already defined with dcterms:rights. Addition of a field „author“ for dcterms:creator only requires to define this field in the JSON-LD @context of a manifest. After some experimenting I found a possible way to connect the „meaningless“ metadata field with JSON-LD fields:

{
  "@context": [
    "http://iiif.io/api/presentation/2/context.json",
    { 
      "author": "http://purl.org/dc/terms/creator",
      "bibo": "http://purl.org/ontology/bibo/"
    }
  ],
  "@id": "http://example.org/iiif/book1/manifest",
  "@type": ["sc:Manifest", "bibo:book"],
  "metadata": [
    {
      "label": "Author",
      "property": "http://purl.org/dc/terms/creator",
      "value": "Allen Smithee"
    },
    { 
      "label": "License",
      "property": "http://purl.org/dc/terms/license",      
      "value": "CC-BY 4.0" 
    }
   ],
   "license": "http://creativecommons.org/licenses/by/4.0/",
   "author": {
     "@id": "http://www.wikidata.org/entity/Q734916",
     "label": "Allen Smithee"
   }
}

This solution requires an additional element property in the IIIF specification to connect a metadata field with its meaning. IIIF applications could then enrich the display of metadata fields for instance with links or additional translations. In JSON-LD some names such as „CC-BY 4.0“ and „Allen Smithee“ need to be given twice, but this is ok because normal names (in contrast to field names such as „Author“ and „License“) don’t have semantics.

Gibt es Diskurse in Metadaten?

Im Libreas Weblog (wahrscheinlich unfreiwillig eines der Instanzen von #newLIS) haben Ben Kaden und Karsten Schuldt eine zwischen ihnen geführte Debatte zu folgender Forschungsfrage zusammengefasst:

Wie viel oder wie wenig Diskurs findet sich in Metadaten beziehungsweise Netzwerken von Metadaten Und was davon kann wie informationswissenschaftlich ausgewertet werden?

Grundsätzlich begrüße ich es sehr wenn die beiden ihre ausführlichen Informations-wissenchaftlichen Beiträge zusammenzufassen. Noch mehr begrüße ich Auseinandersetzungen mit Begriffen von Daten und Metadaten. Ich hoffe, deshalb, dass ihre Forschung nicht nur im Diskurs weiterlebt, sondern sich auch als Ergebnis in einer Beantwortung der Forschungsfrage niederschlägt. In ihrem Blogartikel äußern die beiden Autoren fünf Grundannahmen, von denen ich die ersten vier teile. Die fünfte Grundannahme, dass die „Bibliotheks- und Informationswissenschaft […] vorrangig eine befragende und beschreibende Wissenschaft“ sei, teile ich nicht. Ich befürchte stattdessen, dass die beiden beim Fragen und Beschreiben stehen (bzw. in Bewegung) bleiben. Nach meinem Eindruck ziehen sie es vor, darüber zu diskutieren, „was eine Bibliotheks- und Informationswissenschaft sein soll“ statt die eingangs gestellt Forschungsfrage zielgerichtet zu beantworten.

Mich interessieren jedenfalls Antworten auf die Frage nach Diskursen in Metadaten. Hier nur einige Anregungen:

(1) Zunächst ist es notwendig die Kernbegriffe Diskurs und Metadaten zu definieren.

(2) Interessant am Konzept der Metadaten sind zwei Aspekte: ihre beschreibende Funktion und ihre digitale Struktur.

(3) Hilfreich ist wie so oft der Blick über den Tellerand auf verwandte Phänomene. Aus der Forschungsfrage ergeben sich unter anderem folgende vorläufige Teilfragen:

1. Wie viel oder wie wenig Diskurs findet sich in (reinen) Beschreibungen?

2. Wie viel oder wie wenig Diskurs findet sich (reinen) Strukturen?

Für die Aufgabenstellung eine Master- oder die Ausgangslage einer Doktorarbeit sollte das genügen. Vielleicht lässt sich die Frage zumindest teilweise auch bereits in Form eines Fachartikels beantworten.

Metadaten – Versuch einer Kurzdefiniton

Obgleich ich dem Lexikon der Bibliotheks- und Informationswissenschaft (LBI) von Anfang an mit gemischten Gefühlen gegenüber stand – das Vorhaben eines gedruckten Lexikons ist anachronistisch und verspielt eine Chancen, die deutschsprachige Bibliotheks- und Informationswissenschaft als auf der Höhe der Zeit darzustellen – habe ich als Enzyklopädist inzwischen einige Artikel übernommen. Ich muss zugeben, dass die Beschränkungen des LBI auch einen gewissen Reiz haben. Vor allem ist die Länge der Artikel vorgegeben, so dass es darauf ankommt, einen Begriff in seiner Gänze auf das Wesentliche zu reduzieren. Der Begriff „Metadaten“, für den nächste Woche Abgabefrist ist, fällt mit bis zu 4.000 Zeichen in die umfangreichste Kategorie. Ich habe mit der Geschichte des Begriffs begonnen und versucht, das Wesentliche in diesem Umfang zusammenzufassen. Da sich die Bedeutung eines Begriffs erst aus seinen Relationen zu anderen Begriffen ergibt, habe ich auf möglichst viele andere, verwandte Einträgen des LBI verwiesen. Im Laufe der Diskussion vorgenommene Änderungen sind orange markiert.

Bei Google Books Ngram kann man schön den Anstieg der Verwendung des Begriffs nachvollziehen: Der deutlich zu erkennende Knick 1995 ist auf die Dublin Core Initiative zurückzuführen. Nun aber die Definition in ihrer aktuellen Form:

Über Korrekturen, Ergänzungen, Kritik und vorschläge für ein bis drei Literaturangaben würde ich mich freuen.

P.S.: Bei Mendeley habe ich eine Bibliographie mit Encyclopaedias of Library and Information Science erstellt. Im Terminosaurus Rex gibt es leider keinen Eintrag „Metadaten“.

XML Schema vs. Library APIs (OAI-PMH/SRU/unAPI…)

Much of our work at GBV library network has to do with record formats and APIs. We harvest or get metadata records in a wide range of formats (with many different interpretations and misconstructions of these formats), convert records to a wide range of formats (with many special request how to interpret this formats), and provide records through various APIs. Some of these APIs allow you to select different record formats, for instance OAI-PMH (first published 2001), SRU (2003), and unAPI (2006). These APIs are based on HTTP for transport and XML for encoding of the records. There are also older APIs and encoding formats like Z39.50 and newer APIs like pure Linked Data and SPARQL for RDF. unAPI also supports non-XML formats, but in this article I will concentrate on XML-based formats.

The basic question (that I deal with since years) is „what exactely is a format and how do you refer to it?“. All three APIs provide a method for listing of all formats that are supported by a particular server. unAPI provides a „list of object formats“. Each format has a „name“, a „type“ (which must be an official Internet media type), and an optional documentation URL („docs“), which may refer to some human-readable documentation, or to an XML Schema (XSD) file. Here are three examples:

<format name="oai_dc" type="application/xml"
  docs="http://www.openarchives.org/OAI/2.0/oai_dc.xsd" 
/>
<format name="pubmed" type="application/xml" 
  docs="http://www.nlm.nih.gov/bsd/licensee/elements_descriptions.html"
/>
<format name="mods" type="application/xml"
  docs="http://www.loc.gov/standards/mods/" 
/>
<format name="marcxml" type="application/xml" 
  docs="http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd"
/>

To avoid the uncertainty whether „docs“ references a formal schema or a plain document, there should have been a „schema“ attribute (first problem). To refer to a format in an unAPI request, you use the format’s „name“. In OAI-PMH you refer to a format by its „metadataPrefix“. You can get a list of supported formats with the ListMetadataFormats request. In addition to the „metadataPrefix“ each format has the location of an XML Schema („schema“) and an XML Namespace URI („metadataNamespace“). In theory the latter is dispensable, because each XSD document declares a namespace URI in its „targetNamespace“ attribute: Given a format with a schema that defines namespace „http://example.org/“ like this

<xs:schema targetNamespace="http://example.org/">

I would expect records in this format to use this namespace, at least for the XML root element:

<record xmlns="http://example.org/">

The OAI-PMH specification does not explicitly say that the „metadataNamespace“ must match the namespace in the schema file „schema“. What does it mean if they differ? (second problem).

In SRU a format is known as „schema“. A list of supported formats is contained in an explain request. Each schema has an optional „title“, a „name“ (used to refer to schemas in the „recordSchema“ HTTP parameter when doing a search query), an „identifier“, and an optional „location“. The „identifier“ contains an additional URI, and the „location“ contains a link to an XML Schema file or to some human-readable documentation (like the „docs“ attribute in unAPI). There is a list of known schemas at the SRU page, for instance:

Note that one name (for instance „mods“) can refer to several schemas, but one particular SRU server can only provide one particular format under this name. The additional identifier neither refers to a particular XML Schema (Third problem). The identifier may only give a hint which particular version or interpretation of a format is provided.

Does anyone really need this diverse methods to refer to formats? I found in practice you cannot rely on the claimed format anyway, unless you can automatically validate it. That’s what XML Schema can be used for. I don’t say that XML Schema is the best or only method to formally describe an XML-based format (personally I much bettter like RELAX NG), but if there is an XML Schema – shouldn’t this schema be enough to identify the format?. Is there really a need of four independent identifiers to refer to an XML-based format? In the worst case we have:

• Schema Name (e.g. mods)
• Schema Location (e.g. http://www.loc.gov/standards/mods/v3/mods-3-3.xsd)
• Schema Identifier (e.g. info:srw/schema/1/mods-v3.3)
• Schema Namespace (e.g. http://www.loc.gov/mods/v3)

This is bad design, because you cannot say which of the four is the right one and how they relate to each other. A clean solution would only have two identifiers for XML-based formats:

• The local name, which is only unique for a particular API and a particular server
• The global schema Location, which is a cool URI that resolves to an XML Schema file.

The Schema Namespace is included as „targetNamespace“ in the XML Schema, and the Schema Identifier is delusion anyway. Either you can identify a format by a formal schema (that can also be used to validate records) or you just cannot guarantee which format your records will be in. Sure you can give some hints by linking to documentations, examples, and guidelines. But adding more identifiers is a fakery of control. You are still allowed to provide more specific formats, variants, application profiles, and interpretations under different names. But these formats don’t get more clear or usable if you give them a „Schema Identifier“. Does anyone uses SRU’s Schema Identifiers anyway? I think for XML we can better live with XML Schemas that the XML namespaces can be extracted from. An application can identify a format by its schema location, by the XML namespace, and/or by other information contained in the schema. Additional pointers to human-readable documentation are great. But don’t confuse description with identification if you need to refer to a data format.

P.S. At Code4lib mailing list Rob Sanderson pointed to our discussion we had about the same topic in 2009, and one of my earlier postings on XML4Lib also deals with SRU and namespaces.

Die Citation Style Language (CSL) als Metadatenformat

Auf der Code4Lib Mailingliste hat Tim Spalding vor einigen Tagen die Idee aufgeworfen, die angekündigten Twitter Annotations zur Übertragung von bibliographischen Daten zu verwenden. Die Beteiligten waren alle der Meinung, das bibliotheksspezifische Formate wie MARC und MODS unpassend sind; BibTeX scheidet ebenfalls aus.

Nach der Überlegung, dass Identifikation und Beschreibung zwei klar abzugrenzende Aufgaben von bibliographischen Daten sind, habe ich mir mal genauer die Citation Style Language (CSL) angeschaut. CSL wird unter Anderem in den Literaturverwaltungsprogrammen Zotero und Mendeley benutzt, um Literaturangaben in unzähligen Zitationsstilen ausgeben zu können. Die Grundidee von CSL ist, Zitationsstile als CSL-Styles zu definieren, mit denen dann ein CSL-Prozessor aus bibliographischen Datensätzen schön formatierte Literaturangaben und Bibliographien erstellt. Der am weitesten fortgeschrittene CSL-Prozessor ist citeproc-js. Er ist in JavaScript geschrieben und wurde als Modul aus dem Programmcode von Zotero herausgelöst, so dass er auch unabhängig verwendet werden kann (allerdings bislang noch nicht mit allen JavaScript-Interpretern).

Die Idee ist nun, das CSL-Eingabeformat als Metadatenformat für bibliographische Daten in Twitter-Annotationen zu verwenden. Im Code4lib-Wiki habe ich mal zusammengefasst, was ich zur Spezifikation des CSL-Eingangsformat gefunden habe. Das Metadatenformat ist ziemlich einfach aufgebaut und soll sich dem Entwickler Frank Bennett nach in einer kommenden Zotero-Version auch einfacher aus dem Programm exportieren lassen.

Zur Vermeidung des Umwegs über Zotero fehlen nur Exportmöglichkeiten von CSL-Eingangsdaten aus Bibliothekskatalogen. Deren Titel könnten dann automatisch mit CSL in hunderten von Zitierstilen exportiert werden. In Beluga wird dazu übrigens bislang refbase verwendet, das ebenso wie der CSL-Prozessor citeproc-js als Open Source verfügbar ist. Für die Wikimedia-Projekte bietet sich das Format ebenso an – so könnten die Leser auswählen, welchen Zitationsstil sie bevorzugen und Literaturangaben aus Wikipedia-Artikeln direkt in ihre Literaturverwaltung übernehmen.

KIM-Session zu Metadaten auf dem Bibliothekstag 2008

Der Vortrag zu „Strukturierten Metadaten in Wikipedia“ auf dem Bibliothekstag 2008 ist gut angenommen worden. Fragen kamen vor allem zu ISBN, PND und Personendaten. Leider konnte ich wahrscheinlich nicht ganz rüberbringen, dass dies nur Beispiele für Metadaten aus Wikipedia sind und dass die Verknüpfung und Weiternutzung von Metadaten insgesamt zunimmt; Wikipedia ist hierbei nur ein wesentlicher Nucleus. Vielleicht hätte zum Verständnis noch der Einführungsvortag von Bernhard Haslhofer zum Semantic Web geholfen, der leider krankheitsbedingt ausfallen musste. Der Vortrag „Metadaten im digitalen Workflow“ von Jens Klump aus Potsdam hat mir gefallen, ich vermute nur, dass er für viele Besucher schwer zu verstehen war – Metadaten sind halt auch ein etwas trockenes Thema, schon verwunderlich, dass die Session mit schätzungsweise 100 Personen so gut besucht war. Bei dem Vortrag von Steffen Lamparter über „Metadaten in Service Registries“ konnte ich zunächst bei einigen grundlegenden Punkte zustimmen (Trend zu immer mehr Produzenten von Inhalten und Metadaten, fortschreitende Automatisierung, immer mehr Dienste etc.), aber als er später zu Ontologien kam, wurde es etwas zu unkonkret und praxisfern. Die Einschätzung liegt vielleicht auch an meiner generell skeptischen Haltung gegenüber Ontologien. Abschließend widmeten sich Tom Baker und Stefanie Rühle der Frage „Kann Zertifizierung der Modellkonformität helfen“ und knüpften damit an den Einführungsvortrag von Mirjam Keßler über das KIM-Projekt an.

Wikisource im DFG-Viewer dank Schnittstellen

Der DFG-Viewer ist eine relativ neue Webanwendung zur Anzeige von Digitalisaten. Das von der Deutschen Forschungsgemeinschaft geförderte Projekt soll bei der Etablierung von Standards für Digitalisierungsprojekten helfen – und macht das dank Webservices und offener Standards schon recht gut.

Angestoßen von einem Hinweis auf die Sammlung Ponickau an der ULB Sachsen-Anhalt und eine anschließende Diskussion um die andauernden Verwirrungen bezüglich URI, URN, URL Identifikatoren und Lokatoren, habe ich mir den DFG-Viewer etwas näher angesehen. Die Darstellung sieht nicht ganz so cool aus, wie bei The Open Library, dafür gibt es offene Schnittstellen. Digitalisate können dem Viewer per OAI oder direkter URL im METS/MODS-Format übergeben werden. Die einzelnen Seiten eines digitalisierten Buches und dessen innere Struktur (Gliederung) lassen sich dann durchblättern. Eine Volltextsuche ist anscheinend noch nicht implementiert und es fehlt eine eigene Zoom-Funktion; bislang ist es nur möglich zwischen verschieden großen Auflösungen zu wechseln, falls diese vom Repository ausgeliefert werden.

Ein Exemplar des auf INETBIB als Beispiel genannten Buches mit der VD17-Nummer 32:623995L ist in Halle digitalisiert vorhanden. Die Metadaten des Digitalisates können per OAI in METS/MODS abgerufen werden. Ãœbergibt man nun dem DFG-Viewer die URL, kann das Digitalisat im DFG-Viewer betrachtet werden. Im Moment ist noch ein Schritt Handarbeit notwendig, da im DFG-Viewer ein falscher (?) OAI-Server für Halle eingetragen ist, aber grundsächtlich funktioniert das Mashup. 🙂

Statt spaßeshalber eine METS-Datei mit Pornobildchen zusammenzustellen, um sie im DFG-Viewer anzeigen zu lassen, habe ich mir ein zufälliges Digitalisat von Wikisource vorgenommen. In Wikisource gibt es für jedes Digitalisat eine Indexseite, auf der einige Metadaten und die Seiten der digitalisierten Vorlage aufgelistet sind. Aus dieser Seite kann eine METS/MODS-Datei erzeugt und an den DFG-Viewer geschickt werden. Zwei bis drei Stunden später steht ein einfaches Perl-Skript, dass aus der Index-Seite in Wikisource eine METS-Datei erzeugt. Und so sieht es im DFG-Viewer aus (Draufklicken=größere Ansicht):

Das ganze ist nur ein schnell gehackter Proof-of-concept. Eine stabile Verwendung der Metadaten aus Wikisource sollte aus einer OAI-Schnittstelle bestehen, die METS/MODS liefert (und MABXML für ZVDD). Falls jemand Interesse hat (Bachelor/Diplomarbeit, eigenes Projekt etc.), biete ich gerne meine Unterstützung an – umsetzen muss er es jedoch erstmal jemand anderes da ich nicht dauernd nur neue Projekte anfangen kann. 🙁

Was ist Semantisches Tagging?

In Anschluß an den sehr fruchtbaren Workshop Social Tagging in der Wissensorganisation (Program und weitere Berichte von Mandy Schiefner, bei Joachim Wedekind und Johannes Moskaliuk) schreibe ich grade an einem Artikel über „Semantic Tagging“. Im Zusammenhang mit Social Tagging wurde das Thema Semantic Web zwar immer wieder genannt und die Beiträge dazu im letzten Panel waren alle interessant; wie den nun konkret beide Welten zusammenkommen sollen, blieb aber abgesehen vom Vortrag von Rolf Sint und Georg Güntner von Salzburg Research) über das Terminologie-Modul im Projekt LIVE etwas vage – vielleicht liegt das auch an meiner Technik-zentrierten Sicht, auf Implementierungen und Spezifikationen.

So wie ich das LIVE-Projekt verstanden habe, sollen bei der Olympiade 2008 sportliche Ereignisse „live“ verschlagwortet werden, wobei freie Tags zeitnah mit Hilfe eines Thesaurus-Editors in die „Ontologie“ eingearbeitet werden; das ganze basiert auf SKOS und ist damit weitgehend Semantic-Web-kompatibel – und ein Beispiel für Semantic Tagging. Mit Social Tagging hat das Projekt allerdings nur noch wenig zu tun. Falls sich dennoch normale Nutzer am Tagging der PR-Olympiade beteiligen dürfen, hier mal ein Vorschlag für die Tag-Cloud:

Aber zurück zum Semantischen Tagging: Die Bezeichnung ist eigentlich schon aus der Linguistik besetzt; dort wird unter Semantic Tagging die Erkennung und Auszeichnung von Namen und syntaktischen Strukturen in einem Text verstanden. Ein sehr einfaches Beispiel aus dem Web sind semantische HTML-Tags wie em, strong und cite; eine andere Form semantischen Taggings im Web, die eher in Richtung Auszeichnung von Daten geht, sind Mikroformate. Von dort lässt sich zwar wieder der Bogen zum Semantic Web spannen, aber eigentlich ist semantisches Tagging im Linguistischen Sinne etwas anderes: Gegeben ist ein Text, in dem einzelnen Bestandteile wie Subjekt, Objekt, Nebensatz, Personennamen etc. als solche markiert werden. Beim Social Tagging werden dagegen freie Tags an einen gesamten Text (oder ein anderes Objekt) angehängt, um seinen gesamten Inhalt zu beschreiben. Irgendwo sollte sich deshalb zwischen Semantischem Tagging innerhalb eines Textes und Semantischem Tagging als (Social) Tagging mit expliziter Semantik eine Grenze ziehen lassen.

Dachte ich. Bis ich entdeckt habe, was die Nachrichtenagentur Reuters Ende Januar online gebracht hat: Mit der kostenlosen Web-API „Calais“ lassen sich Texte analysieren, indem Reuters Namen, Orte, Zahlen und andere Angaben extrahiert (siehe API-Dokumentation) und mit RDF auszeichnet. [via Taxonomy Watch] Ob die gefundenen Entitäten auch gleich mit URIs versehen werden oder ob nur ausgezeichnet wird, dass es sich beispielsweise um einen Firmennamen handelt, habe ich noch nicht rausgefunden – in jedem Fall dürften die extrahierten Terme gute Vorschläge für semantisches Tagging abgeben. Zum Ausprobieren kann dieses Formular verwendet werden.

Ach herrje – Ich weiß manchmal nicht, ob ich begeistert sein soll, in welch spannender Weise sich das Web zur Zeit weiterentwickelt oder ob ich daran verzweifeln sollte, wie komplex und schnell das alles geht. Inzwischen ist „Semantic Web“ ja schon so hype, dass es schwierig wird, die Spreu vom Weizen zu trennen.

Aktuelle Projekte und Formate zu Strukturdaten

Mit zunächst ZVDD und nun TextGrid gibt es im deutschen Sprachraum mindestens ein größeres bibliothekarisches DFG-Projekt, dass sich auch der Erschließung von Dokumenten unterhalb der bibliographischen Ebene annimmt. Inzwischen werden im bibliothekarischen Umfeld diese Erschließungsdaten wie zum Beispiel Kapitelgliederung und Paginierung als „Strukturdaten“ bezeichnet (wie es im Englischsprachigen Umfeld aussieht, weiß ich nicht). Standardformate zur Kodierung von Stukturdaten sind der Metadata Encoding and Transmission Standard (METS) und das Format der Text Encoding Initiative (TEI). Der vor kurzem in einer ersten Version veröffentlichte DFG-Viewer basiert auf Strukturdaten im MODS-Format, bislang werden allerdings noch keine Inhaltsverzeichnisses unterstützt. Bislang werden Strukturdaten vor allem im Rahme der Digitalisierung und Archivierung eingesetzt. Ein Beispiel zur Archivierung ist die Dissertation Markup Language (DiML) – als ich als HiWi daran gesessen habe, hat das allerdings noch niemand ein Strukturdatenformat genannt. Ein weiteres Format, das zur Speicherung von Strukturdaten eingesetzt werden kann ist OpenDocument (ODF). Mit der nächsten Version dürfte ODF noch interessanter werden – derzeit sitzt eine Arbeitsgruppe daran, die Einbindung von Metadaten in ODF-Dokumenten auszubauen – wer sich mit Strukturdaten beschäftigt, sollte sich das aktuelle Proposals anschauen – wie man dort sieht, geht alles in Richtung RDF. Wann welches Format vorzuziehen ist bzw. ob und wie ODF beispielsweise TEI verdrängt oder in welchem Kontext die existierenden Formate nebeneinander existieren werden, bleibt abzuwarten.

Citation parsing

Citation Analysis is used to rate authors (problematic) and to find interesting papers (good idea). Citations of papers at the famous arXiv.org preprint server are analysed by CiteBase which is very useful. Unluckily it is buggy and does not alway work. I really wonder why the full text of a paper is parsed instead of using the BibTeX source. The citation parser ParaCite has been developed in the Open Citation Project. Since then it seems to be more or less abandoned. But it’s open source so you can test you papers before uploading and one could take the suiting parts to build a better citation parser. I found out that this way you can extract citations out of a document in $file (for instance a pdf) with perl (the needed modules are available at CPAN):

my $parser = Biblio::Citation::Parser::Citebase->new;
my $content = Biblio::Document::Parser::Utils::get_content( $file );
my $doc_parser = Biblio::Document::Parser::Brody->new;
my @references = $doc_parser->parse($content);

for (my $i=0; $i < @references; $i++) {
    my $metadata = $parser->parse( $references[$i] );
    print '[' . ($i+1) . '] ' . Dumper( $metadata ) . "\n";
}

In the documented that I tested there are almost always parsing errors, but better then nothing. I wonder what CiteSeer uses to extract citations? There is more action in citation parsing in the Zotero project – even an IDE called Scaffold to create new „translators“ that extract bibliographic data out of webpages. Another playing ground is Wikipedia which contains a growing number of references. And of course there are the commericla citation indexes like SCI. I thought to use citation data for additional catalog enrichement (in addition to ISBN2Wikipedia) but quality of data seems to be too low and identifiers are missing.

P.S: Right after writing this, I found Alf Eaton’s experiment with collecting together the conversations around a paper from various academic, news, blog and other discussion channels – as soon as you have identifiers (ISBN, URL, DOI, PMID…) the world gets connected 🙂

P.P.S: ParsCit seems to be a good new reference string parsing package (open source, written in Perl).

P.P.S: Konstantin Baierer manages a bibliography on citation parsing for his parser Citation::Multi::Parser.