[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [InetBib] Follow up: Bibliothekswissenschaft - quo vadis?

Lieber Herr Wagner,

nur kurz noch zur Verständigung und Klarstellung:

Alexander Wagner wrote:

Uwe Müller schrieb:


[...]


Aus edoc-Perspektive handelt es sich bei der Übersicht über alle Artikel des
Sammelbandes, wie sie sich hinter der URL
http://edoc.hu-berlin.de/miscellanies/umstaetter/ verbirgt, lediglich um
eine Sicht auf den gesamten Dokumentenraum, genauer: um einen Knoten in
der Browsing-Struktur des edoc-Servers.


Schon klar, ich weiß schon was Sie da machen, ich finde die Lösung aber
nach wie vor nicht schön, würde lieber sehen es gäbe eine übergeordnete
Aufnahme für den Gesamtband die dann wiederum eine URN erhält, damit
zitierbar und katalogisierbar ist. Diese übergeordnete Aufnahme sollte
dann die URNs der Einzeldokumente referenzieren.


Es gibt bei uns diese übergeordnete Aufnahme für Sammelbände bereits, 
ebenso beispielsweise für Schriftenreihen oder Ausgaben von 
Zeitschriften. Sammelband und die enthaltenen Einträge werden getrennt 
voneinander als Datensätze erfasst und stehen in einer 
"is-part-of"-Relation zueinander. Daher ist es ja auch, wie gesagt, 
technisch kein Problem, hier eine URN zuzuordnen. Wir haben bislang eben 
nur deswegen davon abgesehen, weil es dort kein zugehöriges 
Volltextdokument gibt.


Dass es sich dabei durchaus um eine herausgehobene Sicht handelt, steht
natürlich außer Frage. Und ich verstehe, dass Sie sich für die
Katalogisierung auch eine URN für den gesamten Sammelband wünschen.
Technisch ist das auch ohne Probleme realisierbar, und wir prüfen, ob
wir im Falle von Sammelbänden von der o.g. Annahme (URN bezieht sich
immer auf einen Volltext) abweichen und dort gesonderte URNs vergeben.


Wo man herauskommt wenn man die URN eingibt macht ja durchaus der eDoc
sowieso anders als jedes andere Repositorium. Nicht dass ich es generell
dumm fände, wenn eine URN direkt auf das PDF resolved statt auf das
Katalogisat, IMHO hat man bei OAI-PMH tatsächlich vergessen einen
Mechanismus zu schaffen mit dem man auch das PDF "harvesten" kann. (Na
ja, steht ja im Namen, und ist ja soweit auch mittlerweile fertig.)
Allerdings muß der edoc eine Lösung haben wenn ein Dokument aus mehr als
einer Datei besteht, sonst hat der edoc eigentlich interen ein echtes
Problem, da dann ganz viele Dinge nicht gehen.


Ganz genau. Jeder, der mal versucht hat, einen Harvester zu bauen und 
z.B. eine Volltextsuche über die gesammelten Dokumente zu machen, weiß, 
dass das zentrale Problem dabei die Identifikation des Volltextlinks 
ist, weil in den Metadaten meist nur eine Jump-Off-Page genannt wird. 
Gerade das spricht dafür, in dc:identifier den Volltextlink anzugeben 
und eben darauf auch die URN zu beziehen.


Wenn man eine dauerhafte Langzeitverfügbarkeit im Auge hat, ist mit
dieser Lösung allerdings nicht wirklich viel erreicht. Denn solange der
edoc-Server besteht, sorgen wir ohnehin dafür, dass URLs wie
http://edoc.hu-berlin.de/miscellanies/umstaetter/ usw. zum gewünschten
und korrekten Ziel führen, auch wenn sich die zugrunde liegende
Dateistruktur usw. ändert. Dazu verwenden wir intern bereits einen
entsprechenden Resolver, der genau das bewerkstelligt.


Eben ihre index.php, aber schön ist das nicht, zumal die Teil ihres
Systems ist. Ohne das nachzubauen was der edoc da macht kann ich das
nicht mal irgendwohin portieren wenn ich das denn wollte. ;) Und sollte
edoc mal nicht mehr bestehen gäbe es noch die Einzelteile des Dokuments
aber die wüßten nicht wie sie sich zusammenfinden müssen.


Sobald man irgendwelche Daten in einer Datenbank speichert, auf deren 
Grundlage irgendwelche dynamischen Webseiten ausgeliefert werden (also 
z.B. einfache Jump-Off-Pages), liegt dahinter immer auch ein impliziter 
Resolving-Mechanismus - ob das nun schön ist oder nicht. Das Problem hat 
also jedes Repository, das mehr als einen Verzeichnisbaum mit reinen 
Volltexten zur Verfügung stellt.

[...]


Dazu müsste nämlich die
gesamte Software portiert werden, was im großen Maßstab vollkommen
unrealistisch ist. Da nützen dann auch URNs nicht mehr viel.


Jain. Wenn die TAs dann ein "is part of" und "belongs to" enthalten die
wieder permanent referenzieren geht das schon, sofern beide Felder etwas
enthalten was per Definition resolven muß. Wenn ein PI allerdings eine
endliche Lebenszeit hat (dann würde ich den nicht PI nennen ;) ist das
dann kaputt, in der Tat.


Wie gesagt, diese Beziehungen sind bei genau so abgebildet. Eben dieses 
mehrstufige Dokumentmodell findet sich in den meisten 
Bibliothekssystemen nicht wieder.

Schöne Grüße,
Uwe Müller


--

Kind regards,

Alexander Wagner
Subject Specialist
Central Library
52425 Juelich

mail : a.wagner@xxxxxxxxxxxxx
phone: +49 2461 61-1586
Fax  : +49 2461 61-6103
http://www.fz-juelich.de/zb/mitarbeiter/fachinformation#wagner


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------



-- 
Uwe Müller
Humboldt-Universität zu Berlin

Institut für Bibliotheks- und
Informationswissenschaft
Lehrstuhl für Informationsmanagement
Dorotheenstraße 26, Raum 3c/2

Postanschrift:
Unter den Linden 6
D - 10099 Berlin

Email: u.mueller@xxxxxxxxxxxxxxxx
Tel: +49 30  20 93 - 44 95

-- 
http://www.inetbib.de
Listeninformationen unter http://www.inetbib.de.