Gibt es Diskurse in Metadaten?

9. Juli 2012 um 00:35 2 Kommentare

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

26. Februar 2011 um 17:21 14 Kommentare

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:

“Daten über Daten”, d.h. ↗  Daten die andere Daten oder Objekte strukturiert beschreiben. Ob und um welche Art von M. es sich bei Daten handelt, hängt vom jeweiligen ↗ Kontext und Zweck der ihrer Anwendung ab.

Bis Ende der 1980er wurden lediglich bei ↗  Datenbanken deren technische Beschreibungsdaten wie ↗  Datenfeld und ↗  Datenmodell im Gegensatz zur ↗  Datenbasis als M. bezeichnet. Später wurden M. auf Beschreibungen von ↗  Primärdaten bei der ↗  Datendokumentation ausgeweitet. Ab Mitte der 1990er prägte das ursprünglich zur ↗  Katalogisierung von ↗  Netzpublikationen entwickelte ↗  Dublin Core Metadata Element Set die Vorstellung von M. Inzwischen können alle strukturierten Beschreibungen von ↗  Informationsobjekten und alle als Daten vorliegenden Formen der ↗  Erschließung als M. bezeichnet werden, also auch alle bibliographischen Daten.

Ein Metadatensatz fasst M., die sich auf ein Referenzobjekt (ein ↗  Dokument oder eine ↗  Dokumentarische Bezugseinheit) beziehen zu einer ↗  Dokumentationseinheit zusammen. Bei Containerformaten wie z.B. ↗  METS kann ein ↗  Datensatz auch M. zu mehreren Objekten enthalten. Die klassische Form eines M.satzes in der Bibliothekspraxis ist das ↗  Katalogisat.

Wesentlich für M. ist das Vorhandensein einer einheitlichen Struktur. Diese kann u.A. als Schema (↗  Kategorienkatalog, ↗  Datendefinitionssprache), Profil, Regelwerk, ↗  Datenformat oder Modell (↗  Ontologiesprache) vorliegen. Die Attribute und Beziehungstypen einer M.struktur sowie die in ihr verwendeten Einträge einer ↗  Indexierungssprache werden auch als Metadatenterme bezeichnet. Die Nutzbarkeit von M. über verschiedenen Systeme (↗  Interoperabilität) wird durch ↗  Standardisierung ermöglicht. Hilfreich sind dabei Metadaten-Registries und die Vergabe von ↗  URIs für M.terme. Zur ↗  Datenkonvertierung zwischen verschiedenen M.strukturen dienen M.mappings (“crosswalks”). M.strukturen sind häufig in Beschreibungsebenen verschachtelt und aufeinander bezogen; so ist beispielsweise ↗  MODS durch ein ↗  XML Schema als ↗  XML-Format definiert.

Ob es sich bei konkreten Daten um M. handelt und welche Art von M. vorliegen, hängt jeweils vom ↗  Kontext der Anwendung ab. Üblich ist eine Unterteilung von M. in beschreibende M., verwaltende oder administrative M. und Strukturdaten. Beschreibende M. geben mittels ↗  Sacherschließung und ↗  Formalerschließung Inhalt und Form des Referenzobjekt wieder. Sie dienen vor allem seiner Auffindbarkeit und Identifizierung. Administrative Metadaten enthalten u.A. Angaben zu Nutzungsbedingungen, ↗  Provenienz und ↗  Archivierung sowie Angaben zur technischen Verarbeitung. Zu M. über das Objekt kommen dabei “Meta-Metadaten” mit M. über dessen Beschreibung. Angaben über Beziehungen zu anderen Objekten sowie zur Bewertung und Nutzung gehören je nach Anwendung zu beschreibenden oder verwaltenden M. oder bilden eigene M.typen. Strukturdaten beschreiben die Gliederung des Objekts in ↗  Informationelle Einheiten, z.B. mittels ↗  METS und ↗  OAI-ORE. Je nach ↗  Granularität kann diese Beschreibung von einem einfachen ↗  Inhaltsverzeichnis bis zur detaillierten Repräsentation der Binnenstruktur reichen, so dass hier die Grenze zwischen M. und Objektdaten fließend ist. Da vernetze Informationsobjekte (z.B. im ↗  Semantic Web) im Gegensatz zu physischen Objekten keine eindeutigen Grenzen aufweisen, können M. auch als konstituierend für ein digitales Objekt angesehen werden. Dies spielt vor allem bei der ↗  digitalen Langzeitarchivierung eine Rolle, wo M. und Meta-M. über mehrere ↗  Migrationsschritte mitunter einen größeren Umfang als das ursprüngliche Dokument annehmen können.

Eine alternative Unterteilung von M.typen besteht aus konstituierenden M., die den eigentlichen Inhalt eines Dokuments beschreiben, abgeleiteten M., die sich automatisch aus dem Inhalt des Dokuments ermitteln lassen, beigefügten M., die Relationen zu anderen Objekten beinhalten, und operationalen M., die das Verhalten von M. verarbeitenden Systemen steuern (↗  Programmierung).

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

24. Februar 2011 um 18:33 2 Kommentare

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:

title and location name identifier
MODS Schema Version 3.0 mods info:srw/schema/1/mods-v3.0
MODS Schema Version 3.3 mods info:srw/schema/1/mods-v3.3
MARCXML marcxml info:srw/schema/1/marcxml-v1.1

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

29. April 2010 um 16:39 5 Kommentare

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

4. Juni 2008 um 16:38 Keine Kommentare

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

31. März 2008 um 14:52 3 Kommentare

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?

26. Februar 2008 um 14:19 11 Kommentare

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:

2008 Bronze Doping Gold Menschrechtsverletzung Propaganda Peking Silber Sponsor

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

18. Februar 2008 um 18:04 Keine Kommentare

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

24. Januar 2008 um 19:09 6 Kommentare

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.

More MTSR 2007 presentations

11. Oktober 2007 um 15:54 Keine Kommentare

The after-lunch session of MTSR 2007 contained five presentations:

Spyros Voulgaris presented a A Web Classifier for Semantic Classification Between News and Sports Broadcasts, that is an automated method of classification of news vs sports broadcast based on the properties of audio signal. The method does not require speech-recognition and is language independent. The audio signal is processed into a feature vector with is then fed to a neural network for classification. For feature extraction AMDF (Average Magnitude Difference Function) with segments of one to six seconds is used. As I do not know AMDF I cannot tell you more about this, nor what simple automatic binary classification has to do with semantics.

Based on classifier by Voulgaris et al. a Semiautomated tool for characterizing news video files, using metadata schemas was presented by Stefanos Asonitis. Their system consists of a web crawler for video content, the classifier, and an export of NewsML und SportsML which is partly derived from the sources and the classifier and party edited by users of the system.

For a scientometrics-lover like me Metadata Encoding for the Levels of Scientific Research presented by Nikoletta Peponi was highly interesting. Frankly speaking most of the schema is outdated (for instance the division into article, monograph, essay, and thesis), naive and incomplete. Whithout a set of examples and mapping to existing ontologies its pointless. But it’s an interesting beginning.

Sylvia Poulimenou (Metadata Encoding for the Documents based on the Rules of Diplomatics Science) presented an extension of TEI for diplomatics (the analysis and critical edition of documents to test their authenticity).

In the fifth presentation Mrs. Belesiotis talked about Ontology Oriented Support for the Teaching Process in the Greek Secondary Education. My knowledge of didactics is to low to write more about this, but the didactic of the presentation could habe been better then speedy reading the text on overfilled, too-many slides only. Maybe I just missed the point.

Powered by WordPress with Theme based on Pool theme and Silk Icons.
Entries and comments feeds. Valid XHTML and CSS. ^Top^