Ein Schema, nach dem medienspezifische Daten auf RFID Tags abgelegt werden. Dänisch ist an dem Modell vor allem die Herkunft, nachdem Dänemark mit der Bibliotheksautomatisierung mittels RFID schon flächendeckend Erfahrung gesammelt hat. Der Normenausschuss Bibliotheks- und Dokumentationswesen hat 2007 das dän. Datenmodell als Vorlage für eine eigene Normempfehlung genutzt und als ISO 28560-3 eingereicht.
Für die "Primary Item Id" sind 16 Zeichen (Bytes) vorgesehen. Der Platz sollte genügen, um den bisher verwendeten Bandbarcode unverändert übernehmen zu können. Inclusive der Mod11 Prüfziffer des Barcodes, auch wenn diese vor jeder Weiterverarbeitung ungeprüft abgetrennt wird. Die Barcodeleser haben sie genutzt, um Lesefehler auszuschließen und nach Prüfung abgetrennt. Im Hinblick auf den begrenzten Platz von 8x4 Bytes auf einem Tag ein verschwenderisches Vorgehen. Vorteil der schlichten Übernahme des Barcodes als String ist hingegen die hohe Flexibilität gegenüber Vorgaben des LBS.
Im Rahmen der Konvertierung, sprich RFID Ausstattung an der Helmut-Schmidt-Universität, wurden 14 der vorgesehenen 16 Stellen für den Barcode verwendet. Mit 7 Stellen können lediglich 10 Millionen Items auseinandergehalten werden. Weitere 7 Stellen werden für die immer gleiche Präambel und die Prüfziffer verwendet. Die verbleibenden 2 Stellen sind Nullbytes. Zum Vergleich: eine numerische Codierung hätte mit 4 Bytes rund 4 Milliarden (2^32) Item Ids geboten, bei unveränderter Fehlertoleranz (nämlich null - die CRC kann lediglich Fehler entdecken, aber nicht reparieren).
Die Daten werden in Feldern fester Position abgelegt, die Anordnung geht aus der Tabelle unten hervor. Details zur Implementierung folgen.
| lfd. Nummer | Feldinhalt | # Bytes | Wertebereich |
|---|---|---|---|
| 1 | Ausleihstatus + Version | 1 | 0: neu, 1: ausleihbar, 2: präsenz, 7: gelöscht, 8: Ausweis |
| 2 | Gesamtzahl Teile des Mediums | 1 | |
| 3 | Teilenummer/Ordinal | 1 | (<= Feld 2) 0: nur ein Tag vergeben |
| 4 | Bandbarcode/Primary Item Id | 16 | Individuell je nach LBS |
| 5 | CRC | 2 | siehe unten |
| 6 | Landeskennung nach ISO | 2 | DE z.B. |
| 7 | Isil Bibliothekskennung | 9 | 0500 z.B. (wozu die führende 0?) s.a. Bibliothekssigel |
Anmerkungen
Feld 1: In diesem Byte ist zusätzlich noch die Versionsnummer des dän. Modells untergebracht. Die findet sich im höherwertigen Nibble - also in den ersten 4 Bits. Für die Version 1 müssen also auf die genannten Werte noch 0x10 addiert werden. Beispiel: Für ausleihbare Medien steht hier ein 0x11. Leider ist damit die Anzahl der Versionen auf 15 begrenzt.
In der Implementierung von Bibliotheca findet sich eine Abweichung: Hier sind die beiden Nibble vertauscht. Bei der Mehrzahl der Bände fällt das nicht auf 0x11 heißt "Version 1, ausleihbar". Aber schon ein Präsenzband wird zu 0x21 statt 0x12. Bummer!
Feld 5: Die Summe wird aus genau 32 Bytes gebildet. Ausgenommen sind die beiden Bytes der CRC. um die 32 vollzumachen, werden in unserem Beispiel noch zwei Nullbytes angehängt. Beispielcodes finden sich im Netz - siehe libdanrifid bei code.google.com.
Feld 7: Hier wird bisweilen der Ländercode wiederholt, also DE-123 statt nur 123. Und: warum eigentlich führende Nullen?
Besonderheiten verschiedener Anbieter
Zur Beurteilung verschiedener Implementierungen wurde der RFID Validator benutzt, der Abweichungen von der Spezifikation aufzeigt. Eine quelloffene Referenzimplementierung des DDM liegt mit libdanrfid vor.
FKI Logistex aka Lyngsoe
Die Tags weisen eine Vertauschung der Bytefolge in den Blöcken auf. Einzelne Softwarebestandteile - etwa Gates und Entwicklungswerkzeuge - gleichen das aus. Wenn es um die Analyse des Datenmodells geht, ist diese Software grundsätzlich nicht in der Lage, Tags aus Fremdbibliotheken zu verarbeiten.
FKI setzt Leser und Software von Tagsys ein. Diese Software ist dafür bekannt, daß die Inhalte der Blöcke in umgekehrter Reihenfolge gelesen und geschrieben werden.
Bibliotheca
Sobald Medien mit einem anderen Status als "ausleihbar" (= 0x11) verwendet werden, fällt auf, daß das erste Byte, in dem Version und Medienstatus gemeinsam codiert sind, in den Nibbles verstauscht werden. Statt 0x12 für "Version 1, Status Präsenzbestand" wird hier beispielsweise 0x21 geschrieben. Diese Abweichung spielt für die Mehrzahl der Medien bislang keine Rolle, weil sie mit 0x11 (= ausleihbar) beschrieben sind. Eine Stellungnahme des Herstellers sollte eingeholt werden.
DDM und danach
Als de-facto Standard von Tags in der Öffentlichkeit scheint sich das NDEF (NFC Data Exchange Format) zu etablieren. Es erlaubt, auf einem Tag mehrere Nachrichten unterzubringen - je nach Kapazität. Vielleicht ist eine Kapselung des DDM in einen NDEF Record denkbar, der eine erkennbare Zuordnung als Biliotheksmedium erlaubt?
Links
- Bibliotheca: FAQ (leider 404)
- Bibliotheca: RFID Standards (leider schon wieder ungültig)
- Bibliotheksverband zur Normung
Diese Seite wurde zuletzt am 18. September 2014 um 10:52 Uhr geändert.