Identifier in RDF considered harmful

18. Juni 2013 um 11:31 7 Kommentare

Ich bin gerade dabei die RDF-Daten des Linked Data Service der ZDB zu analysieren, um sie direkt im RDF-Bibliotheksverzeichnis des GBV nutzen zu können. Dabei sind mir einige Unterschiede bei der Behandlung von Identifiern aufgefallen. Hier ein Beispiel aus den Daten der
Stabi Berlin (das RDF-Subjekt habe ich zum Kürzen durch $BIB ersetzt):


  dc11:identifier "DE-1a" ;
  foaf:phone <tel:+49-30-2-66-333501> , <tel:+49-30-2-66-433888> .


  dc11:identifier "(ISIL)DE-1a" ;
  vcard:tel [
     a vcard:Pref, vcard:Voice ;
     rdf:value "+49 30 2 66-433888 (Auskunft)"
  ], [
     a vcard:Fax, vcard:Pref ;
     rdf:value "+49 30 2 66-333501" .
  ] .

Solche unterschiedlichen Kodierungen sind besonders dann problematisch wenn RDF-Daten aus mehreren Quellen zusammengeführt werden sollen. Plötzlich hat dann in diesem Beispiel die Stabi Berlin zweil Identifier und vier Telefonnummern. Telefonnummern lassen sich übrigens nach RDF 3966 auch als URI kodieren, für ISILs gilt dies leider nicht, weil die internationale ISIL-Agentur versäumt hat, sich darum zu kümmern. Grundsätzlich bestärkt mich dieses Beispiel in der Überzeugung, dass Identifier in RDF-Daten Müll sind, solange sie nicht in Form von URIs kodiert werden – und zwar in vielen Fällen besser nicht als HTTP-URIs in mehrfacher Ausführung, wie im Rahmen von Linked Data gängige Praxis!

Dead End Electronic Resource Citation (ERC)

29. März 2013 um 11:51 Keine Kommentare

Tidying up my PhD notes, I found this short rant about “Electronic Resource Citation”. I have not used it anywhere, so I publish it here, licensed under CC-BY-SA.

Electronic Resource Citation (ERC) was introduced by John Kunze with a presentation at the International Conference on Dublin Core and Metadata Applications 2001 and with a paper in the Journal of Digital Information, Vol. 2, No 2 (2002). Kunze cited his paper in a call for an ERC Interest Group within the Dublin Core Metadata Initiative (DCMI) at the PERL4LIB mailing list, giving the following example of an ERC:

erc:  Kunze, John A. | A Metadata Kernel for Electronic Permanence
      | 20011106 |

An ERC is a minimal “kernel” metadata record that consist of four elements: who, what, when and where. In the given example they are:

who:   Kunze, John A.
what:  A Metadata Kernel for Electronic Permanence
when:  20011106

Ironically the given URL is obsolete, the host ‘’ does not even exist anymore. The ERC is pretty useless if it just uses a fragile URL to cite a resource. How about some value that does not change over time, e.g:

where: Journal of Digital Information, Volume 2 Issue 2

As ERC is defined as “a location or machine-oriented identifier”, one could also use stable identifiers:

where: ISSN 1368-7506, Article No. 81

Both ISSN and article numbers 81 are much more identifiers then URLs. Citing an URL is more like

where: at the desk in the little reading room of my library

By the way the current location is – but who knows whether Texas A&M University will still host the journal at this URL in 20 years?

There are some interesting ideas in the original ERC proposal (different kinds of missing values, TEMPER date values, the four questions etc.), but its specification and implementation are just ridiculous and missing references to current technology (you know that you are doing something wrong in specification if you start to define your own encodings for characters, dates etc. instead of concentrating to your core subject and refering to existing specifications for the rest). The current draft (2010) is a typical example of badly mixing modeling and encoding issues and of loosing touch with existing, established data standards.

In addition to problems at the “low level” of encoding, the “high level” of conceptual modeling lacks appropriate references. What about the relation of ERC concepts to models such as FRBR and CIDOC-CRM? Why are ‘who’, ‘when’, ‘where’, ‘what’ the important metadata fields (in many cases the most interesting question is ‘why’)? How about Ranganathan’s colon classification with personality, matter, energy, space, and time?

In summary the motivation behind ERC contains some good ideas, but its form is misdirected.

Proposed changes in VIAF RDF

13. April 2011 um 13:42 2 Kommentare

The Virtual International Authority File (VIAF) is one of the distinguished showcases of international library community projects. Since more then five years, name authority files from different countries are mapped in VIAF. With VIAF you can look up records about authors and other people, and see which identifiers are used for the same person in different national library catalogs. For some people there are also links to bibliographic articles in Wikipedia (I think only English Wikipedia, but you can get some mappings to other Wikipedias via MediaWiki API), and I hope that there will be links to LibraryThing author pages, too.

However, for two reasons VIAF is not used as much as it could be: first not enough easy-to-understand documentation, examples, and simple APIs; and second difficulties to adopt technologies by potential users. Unfortunately the second reason is the larger barrier: many libraries cannot even provide a simple way to directly link to publications from and/or about a specific person, once you got the right person identifier from VIAF. If you cannot even provide such a fundamental method to link to your database, how should you be able to integrate VIAF for better retrieval? VIAF can do little about this lack of technical skills in libraries, it can only help integrating VIAF services in library software to some degree. This brings me to the other reason: you can always further improve documentation, examples, the design of you APIs, etc. to simplify use of your services. As a developer I found VIAF well documented and not very difficult to use, but there are many small things that could be made better. This is natural and a good thing, if you communicate with your users and adopt suggested changes, as VIAF does.

For instance yesterday Jeffrey A. Young, one of the developers behind VIAF at OCLC published a blog article about proposed changes to the RDF encoding of VIAF. I hope that other people will join the discussion so we can make VIAF more usable. There is also a discussion about the changes at the library linked data mailing list. And earlier this month, at the Code4Lib mailing list, there was a a controversial thread about the problems to map authority records that are not about people (see my statement here).

I appreciate the simplification of VIAF RDF and only disagree in some details. The current proposal is illustrated in this picture (copied from Jeffrey’s original article):

This looks straightforward, doesn’t it? But it only suits for simple one-to-one mappings. Any attempt to put more complex mappings into this scheme (as well as the existing VIAF RDF scheme) will result in a disaster. There is nothing wrong with simple one-to-one mappings, with SKOS you can even express different kinds of mappings (broader, narrower, exact, close), but you should not expect too much preciseness and detail. I wonder why at one side of the diagram links are expressed via foaf:focus and at the other side via owl:sameAs. In my opinion, as VIAF is about mapping authority files, all mapping links should use SKOS mapping properties. There is nothing wrong in declaring an URI like to stand for both a foaf:Person, a rdaEnt:Person, and a skos:Concept. And the Webpage that gives you information about the person can also get the same URI (see this article for a good defense of the HTTP-303 mess). Sure Semantic Web purists, which still dream of hard artificial intelligence, will disagree. But in the end RDF data is alway about something instead of the thing itself. For practical use it would help much more to think about how to map complex concepts at the level of concept schemes (authority records, classifications, thesauri etc.) instead of trying to find a “right” model reality. As soon as we use language (and data is a specific kind of language), all we have is concepts. In terms of RDF: using owl:Thing instead of skos:Concept in most cases is an illusion of control.

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.

Class or Property? Objectification in RDF and data modeling

14. August 2009 um 00:23 4 Kommentare

A short twitter statement, in which Ross Singer asked about encoding MARC relator codes in RDF, reminded me of a basic data modeling question that I am thinking about for a while: When should you model something as class and when should you model it as property? Is there a need to distinguish at all? The question is not limited to RDF but fundamental in data/information modeling. In Entity-relationship modeling (Chen 1976) the question is whether to use an entity or a relation. Let me give an example by two subject-predicat-object statements in RDF Notation3:

:Work dc:creator :Agent
:Agent rdf:type :Creator

The first statement says that a specific agent (:Agent) has created (dc:creator) a specific work (:Work). The second statement says that :Agent is a creator (:Creator). In the first dc:creator is a property while in the second :Creator is a class. You could define that the one implies the other, but you still need two different concepts because classes and properties are disjoint (at least in OWL – I am not sure about plain RDF). In Notation3 the implications may be written as:

@forAll X1, X2. { X1 dc:creator X2 } => { X2 a _:Creator }.
@forAll Y1. { Y1 a _:Creator } => { @forSome Y2. Y2 dc:creator Y1 }.

If you define two URIs for class and property of the same concept (the concept of a creator and creating something) then the two things are tightly bound together: Everyone who ever created something is a creator, and to be a creator you must have created something. This logic rule sounds rather rude if you apply it to other concepts like to lie and to be a liar or to sing and to be a singer. Think about it!

Beside the lack of fuzzy logic on the Semantic Web I miss an easy way to do “reification” (there is another concept called “reification” in RDF but I have never seen it in the wild) or “objectification”: You cannot easily convert between classes and properties. In a closed ontology this is less a problem because you can just decide whether to use a class or a property. But the Semantic Web is about sharing and combining data! What if Ontology A has defined a “Singer” class and Ontology B defined a “sings” property which refer to the same real-world concept?

Other data modeling languages (more or less) support objectification. Terry Halpin, the creator and evangelist of Object-Role Modeling (ORM) wrote a detailed paper about objectification in ORM whithout missing to mention the underlying philosophical questions. My (doubtful)
philosophic intuition makes me think that properties are more problematic then classes because the latter can easily be modeled as sets. I think the need for objectification and to bring together classes and properties with similar meaning will increase, the more “semantic” data we work with. In many natural languages you can use a verb or adjective as noun by nominalization. The meaning may slightly change but it is still very useful for communication. Maybe we should more rely on natural language instead of dreaming of defining without ambiguity?

Unique Identifiers for Authors, VIAF and Linked Open Data

20. Mai 2009 um 15:53 1 Kommentar

The topic of unique identifiers for authors is getting more and more attention on the Web. Martin Fenner listed some research papers about it and did a quick poll – you can see the results in a short presentation [via infobib]. What striked me about the results is how unknown existing traditional identifier systems for authors are: Libraries manage so called “authority files” since years. The German Wikipedia has a cooperation with the German National Library to link biliographic Wikipedia articles [de] with the German name authority file since 2005 and there is a similar project in the Czech Wikipedia.

Maybe name authority files of libraries are so unknown because they have not been visible on the Web – but this changes. An important project to combine authority files is the Virtual International Authority File (VIAF). At the moment it already contains mappings between name authority files of six national libraries (USA, Germany, France, Sweden, Czech Republic, and Israel) and more are going to be added. At an ELAG 2008 Workshop in Bratislava I talked with VIAF project manager Thomas Hickey (OCLC) about also getting VIAF and its participating authority files into the Semantic Web. He just wrote about recent changes in VIAF: by now it almost contains 8 million records!

So why are people thinking about creating other systems of unique identifiers for authors if there already is an infrastructure? The survey that Martin did showed, that a centralized registry is wished. VIAF is an aggregator of distributed authority files which are managed by national libraries. This architecture has several advantages, for instance it is non-commercial and data is managed where it can be managed best (Czech librarians can better identify Czech authors, Israeli librarians can better identify authors from Israel, and so on). One drawback is that libraries are technically slow – many of them have not really switched to the Web and the digital age. For instance up to now there are no official URIs for Czech and Israeli authority records and VIAF is not connected yet to Linked Open Data. But the more people reuse library data instead of reinventing wheels, the faster and easier it gets.

For demonstration purpose I created a SeeAlso-wrapper for VIAF that extracts RDF triples of the mappings. At you can try out by submitting authority record URIs or the authority record codes used at VIAF. For instance a query for LC|n 79003362 in Notation3 to get a mapping for Goethe. Some returned URIs are also cool URLs, for instance at the DNB or the VIAF URI itself. At the moment owl:sameAs is used to specify the mappings, maybe the SKOS vocabulary provides better properties. You can argue a lot about how to encode information about authors, but the unique identifiers – that you can link to – already exist!

Who identifies the identifiers?

10. Mai 2009 um 16:39 6 Kommentare

A few days ago, after a short discussion on Twitter, Ross Singer posted a couple of open questions about identifiers for data formats on code4lib and other related mailing lists. He outlined the problem that several APIs like Jangle, unAPI, SRU, OpenURL, and OAI-PMH use different identifiers to specify the format of data that is transported (MARC-XML, Dublin Core, MODS, BibTeX etc.). It is remarable that all these APIs are more or less relevant only in the libraries sector while the issue of data formats and its identifiers is also relevant in other areas – looks like the ivory tower of library standards is still beeing build on.

The problem Ross issued is that there is little coordination and each standard governs its own registry of data format identifiers. An inofficial registry for unAPI [archive] disappeared (that’s why I started the discussion), there is a registry for SRU, a registry for OpenURL, and a list for Jangle. In OAI-PMH and unAPI each service hosts its own list of formats, OAI-PMH includes a method to map local identifier to global identifiers.

On code4lib several arguments and suggestions where raised which almost provoced me to a rant on library standards in general (everyone want’s to define but noone likes to implement and reuse. Why do librarians ignore W3C and IETF?). Identifiers for data formats should neither be defined by creators of transport protocols nor do we need yet another über-registry. In my point of view the problem is less technical but more social. Like Douglas Campbell writes in Identifying the identifiers, one of the rare papers on identifier theory: it’s not a technology issue but a commitment issue.

First there is a misconception about registries of data format identifiers. You should distinguish descriptive registries that only list identifiers and formats that are defined elsewhere and authoritative registries that define identifiers and formats. Yes: and formats. It makes no sense to define an identifier and say that is stands for data format X if you don’t provide a specification of format X (either via a schema or via a pointer to a schema). This already implies that the best actor to define a format identifier is the creator of the format itself.

Second local identifiers that depend on context are always problematic. There is a well-established global identifier system called Uniform Resource Identifier (URI) and there is no excuse not to use URIs as identifiers but incapability, dullness, laziness, or ignorance. The same reasons apply if you create a new identifier for a data format that already has one. One good thing about URI is that you can always find out who was responsible for creating a given identifier: You start with the URI Scheme and drill down the namespaces and standards. I must admin that this process can be laborious but at least it makes registries of identifiers descriptive for all identifiers but the ones in their own namespace.

Third you must be clear on the definition of a format. For instance the local identifier “MARC” does not refer to a format but to many variants (USMARC, UNIMARC, MARC21…) and encodings (MARCXML/MARC21). This is not unusual if you consider that many formats are specializations of other formats. For instance ATOM (defined by RFC4287 and RFC5023, identified either its Mime Type “application/atom+xml” which can could expressed as URI or by its XML Namespace “”)* is extended from XML (specified in [XML 1.0] and [XML 1.1], identified by this URLs or by the Mime Type “application/xml” which is URI*.

The problem of identifying the right identifiers for data formats can be reduced to two fundamental rules of thumb:

1. reuse: don’t create new identifiers for things that already have one.

2. document: if you have to create an identifier describe its referent as open, clear, and detailled as possible to make it reusable.

If there happen to exist multiple identifiers for one thing, choose the one that is documented and adopted best. There will always be multiple identifiers for the same thing – don’t make it worse.

*Footnote: The identification of Internet Media Types with URIs that start with is neither widely used nor documented well but it’s the most official URI form that I could find. If for a particular format there is a better identifier – like an XML or RDF namespace – then you should use that, but if there is nothing but a Mime Type then there is no reason to create a new URI on your own.

Konkurrenz zu Normdaten mit dem Scopus Affiliation Identifier

30. April 2008 um 09:34 2 Kommentare

Wie medinfo berichtet (Details dort) hat Scopus nach dem Author identifier nun den Scopus Affiliation Identifier eingeführt. Damit baut Scopus praktisch eine eigene Normdatei für Körperschaftenh auf. In Deutschland ist dafür bislang die Gemeinsame Körperschaftsdatei (GKD) verbreitet, weitere Systeme existieren in anderen Ländern.

Ich sehe die Entwicklung von Normdaten ähnlich wie Patrick Danowski, der in seiten Vorträgen (The future importance of bibliographic data Sharing and control in Web 2.0, Sharing and control) auf die Bedeutung von freien Normdaten hingewiesen hat: Wenn Bibliotheken nicht endlich ihre Normdaten aktiv und kompetent für die Nutzung im Web anbieten, machen es andere und die bibliothekarischen Normdaten versinken in der Bedeutungslosigkeit. Das Zeitfenster, in dem andere Akteure dazu gebracht werden können, die bibliothekarischen Normdaten weiterzunutzen, schließt sich langsam – wenn es zu spät ist, werden Bibliotheken den anderen herlaufen müssen anstatt umgekehrt. Das Potential für Bibliotheken, sich als relevanter Bestandteil des (Semantic) Web zu positionieren ist mit den bestehenden Normdaten da. Leider aber ist die Situation zu oft – wie beispielsweise neulich an der DNB – so, dass eine gute Idee in ihrer (technischen und organisatorischen) Umsetzung dem Stand der Entwicklung hinterherhinkt und langsam so sehr verkrustet, dass es irgendwann eben andere besser machen – und Bibliotheken damit stückweise überflüssig werden. :-(

BibSonomy und Kataloge verknüpfen mit dem Bibkey

25. April 2008 um 15:46 2 Kommentare

Anknüpfend an einen Workshop zum Thema “Social Tagging in Bibliotheken” und an Gespräche auf der INETBIB 2008 gab es Überlegungen, Bibliothekskataloge mit der webbasierten Literaturverwaltung BibSonomy zu verknüpfen (siehe auch die Diplomarbeit von Annett Kerschis auf die Patrick hingewiesen hat).

Zum einen sollen Nutzer Einträge aus dem Katalog direkt in BibSonomy abspeichern können (wie bereits der KUG und HEIDI anbieten) – der einfachste Weg dazu ist ein BibTeX-Export. Zum anderen soll per Webservice BibSonomy abgefragt werden, ob und mit welchen Tags dort bereits ein Titel von Nutzern gespeichert wurde. Ein grundsätzliches Problem dabei ist jedoch, erst einmal den Titel zu identifizieren, nach dem gesucht werden soll. Die dahinter liegende Aufgabenstellung ist ein klassisches (nicht nur) Bibliothekswissenschaftliches Forschungsfeld: Duplikaterkennung in bibliographischen Datenbanken. BibSonomy ist dabei auf eine ähnliche Lösung gekommen, wie sie teilweise in Katalogen angewandt wird: Aus verschiedenen Feldern (Titel, Autor, Jahr…) wird durch Normalisierung und mittels einer Hashfunktion eine Zeichenkette als Identifikator (“Hashkey”) gebildet. Dubletten sollen dabei möglichst auf den gleiche Hashkey abgebildet werden. Der übergreifende Hashkey von BibSonomy heisst dort “Interhash”.

Ich bin momentan dabei, diesen Hashkey zu spezifizieren (Unter dem Namen “Bibkey Level 1″) und zu implementieren – der Bibkey kann hier ausprobiert werden. In diesem Beispiel wird der Titel über die ISBN aus den GBV-Verbundkatalog geholt und aus den Daten der Bibkey gebildet (serverseitig, Link “Go to record in GSO”). Mit dem Bibkey wird dann über eine weitere API von BibSonomy (die ich als “SeeAlso”-verpackt habe) abgefragt ob den Titel schon jemand in seiner Sammlung hat (clientseitig, Link “Available in BibSonomy”).

Wie alle Heuristiken funktionier der Bibkey in seiner jetzigen Form nicht in jedem Fall. In diesem Beispiel wird bei BibSonomy nichts gefunden, weil die meisten Nutzer “Albert-László Barabási” Nicht richtig buchstabieren können. Auch verschiedene Auflagen kommen aufgrund unterschiedlicher Jahreszahl nicht zusammen. Es ist also noch genügend Forschungs- und Entwicklungsbedarf. Auch für den Einsatz von FRBR wird über Hashkeys nachgedacht, wie dieser Vortrag von Rosemie Callewaert auf der ELAG2008 zeigt.

Weitere Literatur zum Thema “Hashkeyverfahren zur Duplikaterkennung in bibliographischen Daten” sammle ich dank hilfreicher Hinweise mit dem Tag “bibkey” – falls jemand seine Bachelor/Master-Arbeit dazu machen möchte, helfe ich gerne! :-)

Pseudo-URIs als Identifikatoren für Normdaten der Deutschen Nationalbibliothek

7. April 2008 um 03:31 7 Kommentare

Die Deutsche Nationalbibliothek (DNB) hat anscheinend Ende März eine neue Katalog-Oberfläche online gestellt – der alte OPAC ist auch noch verfügbar. Dabei sind unter Anderem die Normdaten (SWD, GKD, PND) teilweise besser integriert. Ich warte ja schon seit einiger Zeit darauf, dass endlich richtige URIs vergeben werden, so dass sich Normdaten global referenzieren lassen. Bei der aktuellen Lösung ist aber leider einiges schiefgelaufen.

Was ist eine URI?
Die Diskussion zum Thema URI/URN/URL auf Inetbib hat mal wieder gezeigt, dass es beim Thema Identifikatoren oft Missverständnisse gibt. Die international allgemeine Form globaler Identifikatoren ist der “Uniform Resource Identifier” (URI) bzw. die Erweiterung “Internationalized Resource Identifier” (IRI). Sie sind in RFC 3986 und RFC 3987 standardisiert. Die Vergabe von UR regelt RFC 4395. Verschiedene URI-Schemata (gekennzeichnet durch den Teil einer URI bis zum ersten Doppelpunkt) sind jeweils mit einem eigenen Standard registriert und definiert, zum Beispiel URNs durch RFC 2141.

Viele URI-Schemata legen Namensräume und eigene Regeln zur Struktur und Vergabe von Identifikatoren fest. So zum Beispiel RFC 3406 für URNs und RFC 3044 für den URN-Namensraum urn:issn zur Abbildung von ISSNs. Durch die Formulierung von ISSNs als URI können diese bereits etablierten aber nur begrenzt nutzbaren Identifikatoren auch global genutzt werden, beispielsweise im Rahmen des Semantic Web. Während die Zeichenfolge “0024-9319″ sehr unterschiedliches identifizieren kann, weist “urn:issn:0024-9319″ eindeutig auf die amerikanische Ausgabe des MAD-Magazins hin.

Um welche Identifikatoren geht es?
Zur Identifikation von Personen (PND), Begriffen (SWD) und Körperschaften (GKD) gibt es im deutschen Bibliothekssystem seit vielen Jahren etablierte Normdaten. Abgesehen von wenigen Ausnahmen fristen diese Normdaten bzw. ihre Identifikatoren jedoch eher ein Schattendasein. Andere Identifikatoren, wie beispielsweise die Nummern von OCLC und der Library of Congress werden dagegen auch zunehmend von den “global players” im Netz verwendet (von Google und LibrayThing). Wenn sie endlich mit URIs versehen und frei veröffentlicht würden, könnten die deutschen Normdateien ebenfalls weitere Verbreitung finden – oder andernfalls an Bedeutung verlieren.

Was hat die DNB falsch gemacht?
Anscheinend ist nun bei der Erstellung von Identifikatoren für Normdaten bei der Deutschen Nationalbibliothek gleich an mehreren Stellen etwas schief gelaufen. Dabei sieht es auf den ersten Blick ganz gut aus: Beim SWD-Eintrag “Poetry Slam” ist beispielsweise dort als “Id” die Zeichenkette “info://” angegeben:

Ist das eine URI? Nein. In der offiziellen Liste von URI-Schemata ist “info:” als gültiges URI-Schema eingetragen, das durch RFC 4452 definiert wird. Die dort festgelegte Maintenance Authority NISO hat die Verwaltung von Namensräumen an OCLC weitergegeben. Nun bekleckert sich OCLC mit dem seit Wochen nicht erreichbaren Verzeichnis der vergebenen Unternamensräume auch nicht gerade mit Ruhm, aber immerhin gibt es klare Standards (mehr Informationen bei der LOC). Eine info-URI ist aufgebaut nach dem Schema “info:NAMENSRAUM/LOKALTEIL“. Die Zeichenkette “info://″ kann also schon formal keine URI sein. Außerdem ist “” nicht als gültiger info-URI Namensraum registriert. Zu allem Überfluss wird nicht auf die etablierten SWD-Nummern zurückgegriffen (die SWD-Nummer für den SWD-Datensatz ist “4709615-9″), sondern als lokaler Bestandteil die nicht standardisierte, systemabhängige PND-Nummer (hier: 965692973) verwendet!

Wie lässt sich der Schlamassel beheben?
Leider ist dies nicht das erste mal, dass sich die DNB im Internet lächerlich macht. Zum Glück lassen sich die Fehler relativ einfach beheben.

1. Die bereits existierenden “Standards” für die existierenden Normdaten-Nummern werden explizit und verlässlich festgeschrieben, d.h. erlaubte Zeichen und Wertebereiche, Berechnung der Prüfziffer und Normalisierung (siehe LCCN-Normalisierung).

2. Die DNB reserviert für die Normdaten-Nummern einen URI-Namensraum (beispielsweise info:swd, info:pnd, info:gkd). Dabei sind die Regeln zur Syntax und Vergabe von URI-Schemata und Namensräumen einzuhalten. Internationale Standards sind zum Lesen und Einhalten da und nicht zum Ignorieren und Uminterpretieren.

3. Die URIs werden verständlich dokumentiert und propagiert. Die Kür wäre eine völlige Freigabe der Normdaten als öffentlicher Datenbank-Abzug unter einer freien Lizenz.

Zur Klärung der Konfusion bezüglich URI und URL sei auf die Artikel URIs, URLs, and URNs: Clarifications and Recommendations (via Kay Heiligenhaus) und On Linking Alternative Representations To Enable Discovery And Publishing hingewiesen.

P.S: Eine bibliotheksrelevante Anwendung von von Identifikatoren für Personen wurde letzte Woche von Arjan Hogenaar and Wilko Steinhoff im Vortrag Towards a Dutch Academic Information Domain auf der Open Repositories 2008 vorgestellt.

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