Liebe Frau Wiesenmüller,
es gibt verschiedene Gründe sich hier nicht mehr äußern zu wollen (bzw.
können)
und so respektiere ich die ihren.
Für das RDA-Lehrbuch kann man ja nur viel Erfolg wünschen!
Da wir im Prinzip schon bei dem Thema waren, würde ich, wie Sie sich
denken können, RDA nicht ohne Blick auf XML behandeln.
Daher hier nur die Anregung:
http://tsig.wikispaces.com/file/view/Future+of+cataloguing+for+wiki.ppt
“Future of Cataloguing: how RDA positions us for the future”
“RDA = content standard can be used with web-friendly encoding schema,
based on XML."
bzw.
http://unllib.unl.edu/LPP/PNLA%20Quarterly/moehrle76-4.pdf
“Sally McCallum of the Library of Congress defined 9 format
characteristics of MARC in her lecture titled "MARC Forward": "XML;
Granularity; Versatility; Extensibility; Hierarchy support; Crosswalks;
Tools; Cooperative management; Pervasive" (2007, p. 3). It's clear any
replacement for MARC 21 will need these characteristics, and more.”
Dazu auch die Einschätzung der Bibliotheksberaterin Karen Coyle.
“There is sometimes the assumption that the future data carrier for
library data will be XML. I think this assumption may be misleading and
I'm going to attempt to clarify how XML may fit into the library data
future.”
http://kcoyle.blogspot.de/2011/09/xml-and-library-data-future.html
bzw. "RDA in XML - why not give it a shot?"
http://kcoyle.blogspot.de/2011/07/rda-in-xml-why-not-give-it-shot.html
Es wird also bezüglich XML auf drei Probleme ankommen:
1. Mit welcher DTD kann man RDA am besten ausschöpfen (Verhältnis zu
JATS NISO Z39.96-2012
http://www.niso.org/apps/group_public/download.php/8975/z39.96-2012.pdf
)?
2. Wie leistungsfähig werden XML-Native-Datenbanken (oder auch Google)
diese DTD recherchieren können,
wenn wir in diesem Bereich endlich die Ebene der relationalen
Datenbanken überwunden haben.
3. Wird es noch vor dieser XML-Nutzung eine Abzweigung der Entwicklung
z.B zu Turtle (Terse RDF Triple Language) geben.
Dass es verschiedene Philosophien in der Wissensverarbeitung und den
Ontologien (für die ja die Semantik Voraussetzung ist) gibt, ist
bekannt.
Als dokumentarisch denkender Mensch, war mir das Konzept der Dokumente
mit Frames und Slots immer näher als die Triple languages, da sich mit
struktirierten Dokumenten ein Objekt beschreiben lässt (aus
archivarischen und historischen Gründen am besten in reiner ASCII bzw.
UNICODE-Form, wie bei SGML), bei dem dann Interferenzmaschinen sich in
einer Art Datamining das an Information herausfiltern können, was sie
für ihre Entscheidungen brauchen. Also beispielsweise welche Rechte ein
Fragesteller bei einem Dokument hat, was er sehen oder hören darf, was
er dafür zahlen muss oder wie weit er es weiter verwenden darf, um nur
ein Beispiel zu nennen.
"In etlichen Bibliotheken gibt es dazu Dateien, beispielsweise mit
Ampelanzeigen, die mit rot (ohne Bibliothekszugang), gelb (einige
Aufsätze zugänglich) und grün (Bibliothekszugang) den Zugang für jeden
Benutzer signalisieren. Dahinter stehen Dateien, auch Knowledge Bases
genannt, die jeweils prüfen, welche Zugriffsrechte das jeweilige
Terminal zur Zeit hat. Da diese Rechte immer wieder verändert sein
können und über unterschiedliche Kanäle erworben werden (so verkaufen
große Verlage ihre Zugriffsrechte auf Publikationen gern im Paket), sind
die Ampelangaben nicht immer korrekt, da die Benutzer über verschiedene
Verträge der Bibliothek unterschiedliche Zugangsberechtigungen beim
Linkresolver SFX bekommen. Damit ist der Zugang bzw. die Zugangsprozedur
von verschieden Terminals nicht immer identisch. Im Prinzip vergleicht
SFX die Zugangsrechte bei einer URL mit den Lizenzrechten der Bibliothek
und deren Benutzerkennungen." (Lehrb. Bibliotheksmanagement S. 81) Schon
heute hat jede Bibliothek das Problem herauszufinden, welche Rechte ihre
Benutzer welchen digitalen Dokumenten gegenüber haben. Dabei geht es um
viel Geld.
Die Bevorzugung von Tripeln in Ontologien ist ähnlich der bei
relationalen Datenbanken. Sie sind einfacher und bekannter, aber damit
nicht unbedingt besser als Frames und Slots. Das gilt insbesondere für
den Bibliotheksbereich.
Frames und Slots hat die NLM schon beim Unified Medical Language System
(UMLS) benutzt. (
http://pubmedcentralcanada.ca/pmcc/articles/PMC2245463/pdf/procascamc00016-0196.pdf
), obwohl damals H. Warner noch kein XML zur Verfügung stand.
Mit freundlichen Grüßen
Walther Umstätter