Liebe KollegInnen,
hier die Antwort von Herr Mackert von der UB Leipzig auf Ihre Fragen zum Hintergrund einiger Strukturdaten:
---
Collegae,
das sind interessante Nachfragen und sehr überlegenswert. Ich versuche
mal, aus der Perspektive desjenigen, der sich inhaltlich mit
Handschriften beschäftigt, darzulegen, was zu den Vorschlägen geführt
hat. Vielleicht ergeben sich ja dann Vereinfachungen und Möglichkeiten,
Termini zusammenzuführen. Grundsätzlich möchte ich darauf hinweisen, daß
unsere Bemühungen dahin gingen, möglichst wenige und weit gefaßte
Oberbegriffe zu bilden, statt für Einzelphänomene ein eigenes Lemma zu
schaffen.
1. Künstlerische Phänomene im weitesten Sinn: Aus Hssperspektive können
grob drei "Eskalationsstufen" von Buchschmuck und anderen künsterischen
Ausdrucksformen unterschieden werden, erstens einfache Initialen
(wichtig wg Textgliederung und -abtrennung), zweitens Initialen mit
Schmuckformen (vom Fleuronné bis zur Feldinitiale mit
Deckfarbenausmalung und Akanthusrankenwerk) und drittens bildliche
Darstellungen. Letztere können Bildseiten, Deckfarbenminiaturen,
historisierte Initialen, kolorierte oder nicht kolorierte
Federzeichnungen oder auch bewohnte Initialen, Drolerien, Groteske und
nachgetragene Zeichnungen in Musterbuchmanier (gar nicht selten) sein.
Illustration ist im handschriftenkundlichen Bereich als "textbezogene
Ausstattung einer Handschrift mit Mitteln der Malerei, Zeichnung oder
Druckgraphik" definiert (Jakobi-Mirwald, Buchmalerei - Ihre
Terminologie.., 3. überarb. Aufl., Berlin 2008, S. 21). Die im
Strukturdatenset vorgegebenen Begriffe waren von den Drucken abgeleitet,
so daß wir die handschriftenkundlichen Belange darin schlecht
untergebracht fanden. Vor allem Illustration ist aus meiner Sicht ein
ungünstiger Begriff, wenn man z. B. einen nackten Trommler in einer
historisierten Initiale zum Weichbildrecht (haben wir!), eine marginale
Gewandstudie von späterer Hand oder eine völlig textunabhängige
Drolerieszene markieren will. "Bildliche Darstellung" ist wesentlich
offener.
2. Text: Hintergrund war hier, nicht die verschiedenen Textgattungen,
die möglich sind, zu einer langen und sicher stets unvollständigen Liste
zusamenzustellen, sondern einen universellen Oberbegriff zu schaffen.
Der Begriff Text oder Drucktext war nach meinem Wissen nicht in der
vorhandenen Liste aufgeführt, sonst hätte man den natürlich modifiziert
übernehmen können. Hinzu kommt: Im Handschriftenbereich stehen wir ja
oft vor dem Problem unfester Texte bzw. neu gebildeter Textcorpora. Das
können z. B. singulär überlieferte Florilegien sein oder
Zusammenstellungen von Kirchenväterkommentaren, die dann ihrerseits als
Einheit wahrgenommen und bestenfalls abgeschrieben wurden. Aus
verschiedenen Titeln (Florilegium: Ilias latina, Walther von Chatillon,
Vergil, Horaz etc.; Patreskompilation: Augustinus, Hieronymus etc.)
entsteht dann ein neuer Text. Es kann sich auch um spätmittelalterliche
Kurzversionen höfischer Epen handeln, die einen anderen Schluß aus einem
anderen Text erhalten. Etc. In all diesen Fällen stehen uns keine festen
Werktitel, sondern Hilfsoberbegriffe zur Verfügung. Das gleiche gilt für
die vielen Nachträge, die ja oft Ergänzungen aus anderen Texten sind.
Von einem Titel im Sinne der Titelei einer Druckschrift wird man nur mit
Bauchschmerzen reden wollen. "Text" stellt dagegen, so die Überlegung
der Runde, eine Art Einsprungpunkt für die Stellen zur Verfügung, an
denen sich innerhalb der Handschrift Textgrenzen befinden.
3. Schema: Ist eine Art der visuellen Buchausstattung, kehrt oft in
philosophischen, juristischen, musiktheoretischen und z. T. auch in
theologischen Hss wieder, außerdem in Formelbüchern und Briefstellern.
Schemata sind abstrakte graphische Figuren mit Textelementen (so etwas
wie heute die Pfeildiagramme). Eine sehr elaborierte Form kennt man von
den Arbores consanguinitatis et affirmitatis, bei denen aber die Grenze
zur Illustration meist überschritten wird.
4. Auf welche Ebene Faszikel gesetzt wird (als Bezeichnung für einen
ursprünglich selbständigen Teil mit eigener Kodikologie und Geschichte
innerhalb einer zusammengesetzten Handschrift), können wohl eher die
intimeren Technikkenner beantworten.
Alles klar? Sonst bitte Rückmeldung.
Beste Grüße in die Runde
CM
--
Dr. Christoph Mackert
Universitaetsbibliothek Leipzig
Leiter des Handschriftenzentrums
Stellvertretender Bereichsleiter Sondersammlungen
Beethovenstr. 6
D-04107 Leipzig
fon: +49 (0)341 97-30509
mail: mackert(a)ub.uni-leipzig.de
---
Bitte beachten Sie, dass Herr Mackert kein Abonnent dieser Mailingliste ist. Eventuelle Antworten, die Sie auch an ihn richten möchten, müssten Sie also bitte explizit auch an mackert(a)ub.uni-leipzig.de adressieren.
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Projekt-Mitarbeiter
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
http://www.slub-dresden.de/
Hallo Herr Funk,
Ihre Ausführungen kann ich nicht ganz nachvollziehen. Wenn Sie an den
Viewer Strukturdaten schicken, die nicht der vereinbarten
Strukturdatentypologie entsprechen, dann kann es zu allen möglichen
"Unschönheiten" kommen - aber dafür kann der Viewer doch nichts.
Wir hatten das Thema "Mehrsprachigkeit" hier schon oft diskutiert. Und
die probateste Lösung ist die, die Herr Meyer hier nun nochmals
aufführt: Wenn ein Label-Attribut angegeben ist, wird dessen Wert
(unabhängig von der gerade vom Nutzer gewählten Sprache) angezeigt.
Wenn Label nicht vorhanden ist, wird das Typ-Attribut ausgewertet und
entsprechend der Strukturdatenliste in die gerade ausgewählte Sprache
übersetzt. Über die Labels können Sie das Thema Mehrsprachigkeit
überhaupt nicht lösen. Wie wollen Sie denn über OAI mitteilen,
welche Sprache der Viewernutzer gerade ausgewählt hat, um dann
lokalisierte Labels zu generieren?
Beste Grüße,
Kay Heiligenhaus
Am 02.09.2009 um 13:59 schrieb "Stefan Funk" <funk(a)sub.uni-
goettingen.de>:
> Hallo liebe Liste.
>
> Eine kleine Unschönheit sehe ich hier mit verschiedenen Sprachen: Ha
> be ich
> einen deutschen Titel und die Strukturtypen sind beispielsweise aus
> zvdd, dann
> wären diese Englisch. Der Viewer übersetzt, soweit ich weiß, nur d
> ie
> DFG-Viewer-Typen. Es wäre meiner Meinung nach sehr unpraktisch, dann
> die
> zvdd-Typen in der METS-Datei übersetzen zu müssen. Das wäre dann
> evtl. wieder
> die Sache des Labels, man könnte den Typ ja auch übersetzt in das La
> bel
> schreiben (also "Typ: Label" als Label).
>
> Solange wir keine Regelung für Mehrsprachigkeit für Strukturtypen ha
> ben, würde
> ich daher gerne nur das Label anzeigen lassen.
>
> Viele Grüße.
> *fu*
>
>
> Meyer, Sebastian schrieb am 02.09.2009 13:36:
>> Lieber Herr Staecker,
>>
>> über die Behandlung von @TYPE und @LABEL im Viewer hatten wir uns
>> vor
>> einiger Zeit schonmal (ich glaub in Halle) unterhalten. Damals
>> hatten wir
>> die Entscheidung getroffen, dass in der Navigation immer bevorzugt
>> das
>> Label angezeigt werden solle. Nur wenn das Attribut nicht
>> existiert, soll
>> stattdessen der Typ (in entsprechender Übersetzung laut Strukturda
>> tenset)
>> angezeigt werden. Ursprünglich war es mal so, dass der Viewer imme
>> r "Typ:
>> Label" angezeigt hat. Das wurde aber glaube ich kritisiert, weil die
>> Bezeichnungen dadurch teilweise recht lang wurden und auch
>> Dopplungen der
>> Art "Titelseite: Titelseite" auftraten. (Wobei ich es für falsch h
>> alte, in
>> @LABEL reine Deskriptoren unterzubringen. Diese Information steckt
>> doch
>> bereits in @TYPE und muss nicht nochmal in @LABEL wiederholt
>> werden. Was
>> die Dopplungen betrifft, sehe ich den Fehler also nicht beim Viewer,
>> sondern beim Ersteller der METS-Datei.)
>>
>> Mein Vorschlag wäre deshalb, zum alten Verhalten des Viewers zurüc
>> kzukehren
>> und immer "Typ: Label" in der Navigation anzuzeigen (bzw. nur
>> "Typ", falls
>> kein @LABEL vergeben wurde). Die Vermeidung von Dopplungen obliegt
>> dann dem
>> Datenlieferanten, der @LABEL nicht belegen sollte, wenn die
>> Information zu
>> der in @TYPE redundant ist.
>>
>> Viele Grüße Sebastian Meyer
>>
>>
>> --
>>
>>
>>
>> Sebastian Meyer
>>
>> Projekt-Mitarbeiter
>>
>>
>>
>> Sächsische Landesbibliothek -
>>
>> Staats- und Universitätsbibliothek Dresden (SLUB)
>>
>> 01054 Dresden
>>
>> Tel.: +49 351 4677-206
>>
>> Fax: +49 351 4677-711
>>
>> http://www.slub-dresden.de/
>>
>> ________________________________ Von: dv-technik-bounces@dfg-
>> viewer.de
>> [dv-technik-bounces(a)dfg-viewer.de] im Auftrag von Thomas Stäcker
>> [staecker(a)hab.de] Gesendet: Mittwoch, 2. September 2009 07:42 An:
>> dv-technik(a)dfg-viewer.de Cc: Torsten Schaßan Betreff: Re: [DFG-Vie
>> wer]
>> Strukturdaten
>>
>> Lieber Herr Meyer, liebe Kollegen,
>>
>> sorry, ich war etwas vorschnell und wiegte mich wegen der positiven
>> Validierung in Sicherheit. Unser Skript hatte noch Mängel und bild
>> ete die
>> Strukturdaten im structLink Bereich nur auf der obersten
>> Hierarchiestufe
>> ab. Das konnte natürlich dann trotz korrekter logical structMap ni
>> cht
>> gelingen. Jetzt ist alles OK, vgl. z.B.
>>
>> http://dbs.hab.de/oai/wdb/?verb=GetRecord&metadataPrefix=mets&identifier=oa…
>>
>>
>> Ich möchte noch zwei Bemerkungen dazu anschließen.
>>
>> a) um eine zur Viewerliste-Strukturdatenliste konforme Ausgabe zu
>> erhalten, wird durch ein XSLT Skript geprüft, ob der Begriff, der in
>> unserer XML Strukturdatendatei, vorkommt und zumeist der Liste
>> http://diglib.hab.de/rules/concordance/structMD.xml entnommen ist
>> (Alternative fachspezifische Listen s.
>> http://www.hab.de/bibliothek/wdb/doku/lists.htm#thesauri), den
>> Indikator
>> n="dfg-viewer" traegt. Wenn ja, wird der Begriff in xml:id unserer
>> Liste in
>> @TYPE der <DIV> in <structMap> übernommen, der Begriff in <term
>> xml:lang="de"> in @LABEL. Ist der Begriff vorhanden, hat aber nicht
>> den
>> Indikator n="dfg-viewer" wird nach einem Verweis gesucht (z.B.
>> verweist
>> introduction auf preface) und dann der Viewer konforme Begriff
>> verwendet.
>> Entsprechendes könnte für zvdd konforme Begriffe gemacht werden (d
>> azu
>> brauchen wir dann noch einen Steuerungsindikator oder überlegen, o
>> b wir es
>> über die behavior-section in METS lösen können). Gibt es keinen Ve
>> rweis und
>> sonstwie keine Zuordnung wird das Paar section/Abschnitt verwendet
>> (dies
>> vielleicht für die interessant, die auf der Basis von TEI und/oder
>> unserer
>> XML Strukturdatenliste arbeiten wollen).
>>
>> b) ich finde die Behandlung von @TYPE und @LABEL in der Anzeige
>> noch nicht
>> ganz glücklich. Derzeit wird nur LABEL begrücksichtigt. Das verkür
>> zt aber
>> die Information, die gebracht werden könnte und müsste. Zum einen
>> könnte
>> auf der Basis unserer Vereinbarung die XML-IDs der Viewerliste in
>> @TYPE
>> schreiben, mehrer Sprachen bedient werden. Vgl. bei uns
>> http://diglib.hab.de/wdb.php?dir=drucke/nd-24&lang=de und
>> http://diglib.hab.de/wdb.php?dir=drucke/nd-24&lang=en. Zum anderen
>> besteht
>> ein Problem der reinen @LABEL Darstellung darin, dass wir nicht
>> zwischen
>> textlichen Inhalten und Deskriptoren unterscheiden können. Wenn @
>> LABEL den
>> Inhalt einer Überschrift enthält, weiss man nicht mehr, dass es si
>> ch um
>> eine Überschrift handelt, es könnte auch ein Abschnitt oder andere
>> s sein
>> (im obigen OAI Beispiel <mets:div ID="logMD_515681113_8"
>> TYPE="preface"
>> LABEL="Avis, Sur les dessein, & sur l'ordre de ce Recueil" ></
>> mets:div> ).
>> Wenn ich recht sehe wird es in Halle auch so kodiert. Was wir an
>> dieser
>> Stelle bräuchten, ist m.E. eine Anzeige der Form @TYPE: @LABEL (pr
>> eface:
>> Avis...) oder eigentlich besser: Vorrede: Avis... Nun wäre das abe
>> r bei den
>> Deskriptoren unschön: illustration:Illustration. Eine sinnvolle Al
>> ternative
>> könnte darin bestehen mit Unterordnungen zu arbeiten:
>>
>> <mets:div ID="logMD_515681113_8" TYPE="preface" LABEL="Vorrede" >
>> <mets:div
>> ID="logMD_515681113_8" TYPE="preface" LABEL="Avis, Sur les dessein,
>> & sur
>> l'ordre de ce Recueil" ></mets:div> </mets:div>
>>
>> Was schlagen Sie vor?
>>
>> Viele Grüße, Ihr Th. Stäcker
>>
>> Thomas Stäcker schrieb:
>>> Lieber Herr Meyer,
>>>
>>> die neue Version ist wunderbar, besonders die Doppelseitenansicht
>>> gefällt
>>> mir sehr gut. Leider werden die Strukturdaten werden bei mir nur
>>> auf der
>>> obersten Hierachieebene angezeigt (Validation ist aber korrekt).
>>> Wenn Sie
>>> einmal
>>>
>>> http://test.dfg-viewer.de/demo/viewer/?set[image]=372&set[zoom]=min&set[deb…
>>>
>>>
>>>
>>> mit
>>>
>>> http://diglib.hab.de/drucke/nd-24/start.htm
>>>
>>> vergleichen, sehen Sie, dass das meiste weggefallen ist.
>>>
>>> Viele Grüße, Ihr Th. Stäcker
>
>
> --
> Stefan E. Funk
> DP-D - Diensteportal Digitalisierung
> Goettingen State and University Library - The Historical Library
> Building
> Papendiek 14, 37073 Goettingen, Germany
> Phone: +49 551 39-7700 | 39-12170
> Mail: funk(a)sub.uni-goettingen.de
>
Lieber Herr Heiligenhaus,
war natürlich alles Absicht ;-) Im Ernst, danke für den Hinweis, habe es
geändert. Bitte verwenden Sie auch nicht mehr unsere alte Schnittstelle.
Sie ist nicht OAI konform wegen des implizit übergebenen Parameters
?Repository=WDB, das hat die OAI community - obwohl URI konform - nach
längerer Diskussion verworfen, so dass ich die BasisURL jetzt auf
http://dbs.hab.de/oai/wdb geändert habe. Diese unterstützt jetzt auch
die CONTENTIDs, die Strukturdaten kommen in Kürze. Ihr Beispiel also
jetzt wie folgt:
http://dbs.hab.de/oai/wdb?verb=GetRecord&metadataPrefix=mets&identifier=oai…
Lieber Herr Meyer, könnten Sie bitte auch das Beispiel auf der Viewer
Seite entsprechend ändern?
Viele Grüße,
Ihr
Th. Stäcker
Kay Heiligenhaus schrieb:
> Lieber Herr Stäcker,
>
>> ich sehe es auch wie Sie, der Validator sollte 3.2. kompatibel bleiben.
>> Die Praxisregeln haben sich erst in der letzten Version auf 3.3.
>> festgelegt, davor gab es natürlich auch schon DFG Projekte. Neue
>> Projekte sollten aber immer 3.3. kompatibel sein bzw. nach dem Wunsch
>> der Praxisregeln möglichst einen shelflocator aufweisen. Das würde ich
>> auch als deontische Formulierung in die Viewerdokumentation aufnehmen.
>
> Dann dürfen Sie aber nicht erschrecken, wenn bald ebenso deontisch vom Schema-Validator bei der Validierung von MODS-Daten aus Wolfenbüttel zurückkommt: "Das Element <shelfLocator> ist in Schema-Version 3.2 nicht bekannt". Die OAI-Schnittstelle in Wolfenbüttel
>
> http://dbs.hab.de/oai/?verb=GetRecord&metadataPrefix=mets&identifier=oai:di…
>
> liefert zumindest gerade:
>
> * * *
>
> <mods:mods xsi:schemaLocation="http://www.loc.gov/mods/v3http://www.loc.gov/standards/mods/v3/mods-3-2.xsd" >
> [...]
> <mods:location>
> <mods:physicalLocation>Herzog August Bibliothek Wolfenbüttel</mods:physicalLocation>
> <mods:shelfLocator>A: 378.7 Theol. 2°</mods:shelfLocator>
> </mods:location>
> [...]
> </mods:mods>
>
> * * *
>
> In Ihrer aktuellen Implementierung haben Sie also eine apollinische Lösung gefunden: Der Validator "merkt" aufgrund des gerade diskutierten Fehlers nicht mal, daß Ihre MODS-Dokumente de facto schemainkonform sind - ganz unabhängig von den Praxisregeln. ;)
>
> Beste Grüße,
--
Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung)
Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel
Tel. +49(0)5331/808-119 - email: staecker(a)hab.de
Liebe Kolleginnen und Kollegen,
ich habe nun beinahe alle bisher bei mir eingegangenen Anmerkungen umgesetzt und Fehler beseitigt. Bitte testen Sie noch einmal intensiv die neue Viewer-Version und den Validator unter http://test.dfg-viewer.de/ (dort einfach den Demonstrator verwenden - dahinter verbirgt sich die derzeitige Entwicklerversion).
Zudem habe ich alle Texte der DFG-Viewer-Webseite gemäß unseren Vereinbarungen vom 25.6. umgeschrieben. Das betrifft vor allem die Strukturdatenliste und die METS-Beispiele. Auch da bin ich für Hinweise und Fehlermeldungen dankbar.
Was noch zu tun ist:
- Die farbliche Markierung der nur für Handschriften in Frage kommenden Strukturdaten steht noch aus. Wobei die vier betreffenden Elemente auch daran zu erkennen sind, dass es für sie kein Mapping auf ein ZVDD-Element gibt. Ich würde deshalb vorschlagen, statt einer farblichen Markierung (die der Übersicht abträglich wäre) lieber einen Hinweis anzubringen, der auf dieses Merkmal hinweist. Was meinen Sie?
- Der METS-Validator validiert nach wie vor gegen das jeweils aktuellste METS- bzw. MODS-Schema statt gegen das in der zu validierenden Datei angegebene. Hier tüftel ich noch an einer Möglichkeit, einerseits gegen das in der Datei angegebene Schema zu validieren, andererseits aber trotzdem zu prüfen, ob das verwendete Schema aktuell genug ist, um die DFG-Praxisregeln überhaupt erfüllen zu können. (In den Praxisregeln wird die Verwendung von MODS-Elementen empfohlen, die erst seit Version 3.4 Bestandteil von MODS sind.)
Sollten keine größeren Fehler mehr zu Tage treten, wird die neue DFG-Version planmäßig am 1.9. veröffentlicht werden.
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Projekt-Mitarbeiter
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
http://www.slub-dresden.de/
Liebe Kollegen,
> das Repository der SUB Göttingen ist im Moment leider nicht auf dem aktuellen Stand. Der DFG-Viewer wird an der SLUB Dresden in einem dort betriebenen Repository entwickelt und da in Dresden kürzlich die zahlreichen Subversion-Repositories zentralisiert und restrukturiert wurden, funktioniert bisher die Synchronisierung des Göttinger Repositories noch nicht wieder. Die Dresdner Repositories sind dagegen auch noch nicht extern erreichbar. Daran arbeiten wir aber.
>
> Aber selbst wenn demnächst auch das Göttinger Repository wieder aktuell und das Dresdner extern erreichbar ist, sollten Sie den Code aus dem Trunk-Zweig nicht produktiv einsetzen. In "trunk" befindet sich der aktuell in Entwicklung befindliche Quellcode. Dieser ist also gänzlich ungetestet und nicht selten gar nicht funktionstüchtig, etwa weil eine unvollständige Entwicklung dort abgelegt wird, um sie Kollegen zugänglich zu machen.
>
die automatische Synchronisation der Repositorien in Dresden und
Göttingen wurde reaktiviert. Leider wurde bei der Migration des
Repositories in Dresden ist die Versionsgeschichte nicht mitgenommen,
daher wird unter https://develop.sub.uni-goettingen.de/repos/dfg-viewer/
als aktuellste Version die Revision 2 angegeben.
Mit freundlichen Grüßen,
--
----------------
Christian Mahnke
----------------
Center for Retrospective Digitization
Goettingen State and University Library (SUB)
University of Goettingen
Papendiek 14
37073 Goettingen, Germany
web: http://gdz.sub.uni-goettingen.de/
phone: +49 (0)551 39 - 4917
skype: christian.mahnke
mail: mahnke(a)sub.uni-goettingen.de
Lieber Herr Meyer,
als derzeit federführend zuständig für das VD 17 erkläre ich die VD 17
Nummer hiermit zu einem persistenten Identifier ;-) Im Ernst, die VD 17
Nummer ist eine fixe bibliographische Nummer, vgl.
http://www.vd17.de/zitieren.html (Auf den Seiten des VD 17 finden Sie
auch das Regelwerk zum VD 17)
Ob man bibliographische Nummern mit persistenten Identifieren
gleichsetzt, könnte man diskutieren (Frage der formalen Bilderegel und
theoretischen Resolvingmöglichkeiten), halte ich aber für nebensächlich.
Das für mich eigentlich entscheidende Argument ist, dass sich der Viewer
vor allem dem VD-Digitaliserungskontext verdankt und insofern die dort
verwendteten Identifer anzeigen sollte, auch wenn sich andere, nicht
technische Identifier ebenfalls anbieten, wie ISBN etc.
Viele Grüße,
Ihr
Th. Stäcker
Meyer, Sebastian schrieb:
> Lieber Herr Staecker,
>
> da scheint es also unterschiedliche Auffassungen darüber zu geben, ob VD16/17-Nummern persistente Identifier sind oder nicht. Bislang werden die Identifier in der Test-Version ja als persistent angezeigt (weil ich sie auch dafür hielt), was beim Arbeitstreffen jedoch kritisiert wurde. Daraufhin wurde nach alternativen Möglichkeiten der Anzeige gesucht, gleichzeitig aber deutlich gemacht, dass der Viewer künftig nicht für jeden denkbaren Identifier jeweils eine individuelle Anzeigeform umsetzen soll.
>
> Offenbar müssten wir also erst einmal klären, ob VD16/17-Nummern nun persistent sind oder nicht - und demnach überhaupt Handlungsbedarf besteht. Gibt es dazu irgendwo eine offizielle Aussage? Auf der VD17-Webseite ist von einem "VD17-Regelwerk" die Rede, das ich aber nirgends finden konnte.
>
> Viele Grüße
> Sebastian Meyer
>
>
> --
>
>
>
> Sebastian Meyer
>
> Projekt-Mitarbeiter
>
>
>
> Sächsische Landesbibliothek -
>
> Staats- und Universitätsbibliothek Dresden (SLUB)
>
> 01054 Dresden
>
> Tel.: +49 351 4677-206
>
> Fax: +49 351 4677-711
>
> http://www.slub-dresden.de/
>
> ________________________________
> Von: dv-technik-bounces(a)dfg-viewer.de [dv-technik-bounces(a)dfg-viewer.de] im Auftrag von Dr. Thomas Staecker [staecker(a)hab.de]
> Gesendet: Dienstag, 28. Juli 2009 09:19
> An: dv-technik(a)dfg-viewer.de
> Betreff: Re: [DFG-Viewer] Verarbeitung von VD16/17-Identifiern
>
> Lieber Herr Meyer,
>
> in der Tat scheint mir eine Gleichbeahndlung aller Identifier vom
> technischen Standpunkt aus das Richtige zu sein. Allerdings ist die VD
> 17 Nummer eine "persistente" Nummer. Sie wurde als bibliographisch
> eindeutige Nummer extra dafür eingerichtet. Hinfällige Nummern erhälten
> Verweise, so dass die Erreichbarkeit der Aufnahme stets gewährleistet ist.
> Von der inhaltlichen Seite möchte ich dennoch aber für die Anzeige der
> VD-Nummern plädieren. D.h. nicht, dass Sie im Format irgendwie anders
> abgelegt werden sollte als andere IDs, aber wir sollten sie,
> möglicherweise anders als andere IDs, zur Anzeige bringen, denn diese
> Nummer ist der im nationalen Kontext verbindliche Identifier (wie eine
> ISBN) und sollte zur Ansicht gebracht werden.
>
> Viele Gruesse,
> Ihr
> Th. Stäcker
>
>
>
>
> Meyer, Sebastian schrieb:
>> Liebe KollegInnen,
>>
>> gerade bin ich dabei, die Ergebnisse des letzten Arbeitstreffens in Dresden und die Anmerkungen und Fehlermeldungen von Herrn Heiligenhaus umzusetzen. Dabei ist mir ein Widerspruch aufgefallen, den ich gerne zur Diskussion stellen möchte.
>> Während des Arbeitstreffens hatten wir uns darauf verständigt, für die VD16/17-Nummer eigentlich nur ungern eine Sonderbehandlung umsetzen zu wollen. Die Argumentation war, dass die VD16/17-Nummern als Identifier aus Sicht des DFG-Viewers nicht mehr- oder minderwertiger sind als andere Identifier auch. In sofern wäre eine Sonderbehandlung also nicht gerechtfertigt, solange man diese dann nicht auch jedem anderen Identifier zukommen lässt. Die Frage war also: wollen wir potentiell jeden Identifier individuell behandeln oder lieber alle Identifier gleich?
>> Die Meinung ging eigentlich eher zu zweiterem, was jedoch im Widerspruch dazu steht, dass die VD16/17-Identifier nun doch an anderer Stelle und in anderer Form angezeigt werden sollen, als beispielsweise URN, PURL oder PPN. Das jedoch vor allem vor dem Hintergrund, dass die VD16/17-Nummern nicht persistent sind und deshalb nicht als "persistente Identifier" erscheinen sollen.
>>
>> Mein Vorschlag wäre nun, dass wir die VD16/17-Nummern (genauso wie jeden anderen in MODS angegebenen Identifier) doch auch weiterhin im Abschnitt "Persistente Identifier" aufführen, diesen Abschnitt aber künftig eben nicht mehr "persistent" nennen. Kurzum: wir ändern gegenüber der jetzigen Anzeigeform im Test-System (http://test.dfg-viewer.de/) nichts als die Bezeichnung "Persistente Identifier" zu "Identifier".
>>
>> Was meinen Sie?
>>
>> Viele Grüße
>> Sebastian Meyer
>>
>> --
>>
>> Sebastian Meyer
>> Projekt-Mitarbeiter
>>
>> Sächsische Landesbibliothek -
>> Staats- und Universitätsbibliothek Dresden (SLUB)
>> 01054 Dresden
>> Tel.: +49 351 4677-206
>> Fax: +49 351 4677-711
>> http://www.slub-dresden.de/
>>
>>
>
>
> --
> Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung)
> Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel
> Tel. +49(0)5331/808-119 - email: staecker(a)hab.de
>
>
>
>
> ------------------------------------------------------------------------
>
> Lieber Herr Staecker,
>
> da scheint es also unterschiedliche Auffassungen darüber zu geben, ob
> VD16/17-Nummern persistente Identifier sind oder nicht. Bislang werden
> die Identifier in der Test-Version ja als persistent angezeigt (weil ich
> sie auch dafür hielt), was beim Arbeitstreffen jedoch kritisiert wurde.
> Daraufhin wurde nach alternativen Möglichkeiten der Anzeige gesucht,
> gleichzeitig aber deutlich gemacht, dass der Viewer künftig nicht für
> jeden denkbaren Identifier jeweils eine individuelle Anzeigeform
> umsetzen soll.
>
> Offenbar müssten wir also erst einmal klären, ob VD16/17-Nummern nun
> persistent sind oder nicht - und demnach überhaupt Handlungsbedarf
> besteht. Gibt es dazu irgendwo eine offizielle Aussage? Auf der
> VD17-Webseite ist von einem "VD17-Regelwerk" die Rede, das ich aber
> nirgends finden konnte.
>
> Viele Grüße
> Sebastian Meyer
>
>
> --
>
>
>
> Sebastian Meyer
>
> Projekt-Mitarbeiter
>
>
>
> Sächsische Landesbibliothek -
>
> Staats- und Universitätsbibliothek Dresden (SLUB)
>
> 01054 Dresden
>
> Tel.: +49 351 4677-206
>
> Fax: +49 351 4677-711
>
> http://www.slub-dresden.de/
>
>
>
> ------------------------------------------------------------------------
> *Von:* dv-technik-bounces(a)dfg-viewer.de
> [dv-technik-bounces(a)dfg-viewer.de] im Auftrag von Dr. Thomas Staecker
> [staecker(a)hab.de]
> *Gesendet:* Dienstag, 28. Juli 2009 09:19
> *An:* dv-technik(a)dfg-viewer.de
> *Betreff:* Re: [DFG-Viewer] Verarbeitung von VD16/17-Identifiern
>
> Lieber Herr Meyer,
>
> in der Tat scheint mir eine Gleichbeahndlung aller Identifier vom
> technischen Standpunkt aus das Richtige zu sein. Allerdings ist die VD
> 17 Nummer eine "persistente" Nummer. Sie wurde als bibliographisch
> eindeutige Nummer extra dafür eingerichtet. Hinfällige Nummern erhälten
> Verweise, so dass die Erreichbarkeit der Aufnahme stets gewährleistet ist.
> Von der inhaltlichen Seite möchte ich dennoch aber für die Anzeige der
> VD-Nummern plädieren. D.h. nicht, dass Sie im Format irgendwie anders
> abgelegt werden sollte als andere IDs, aber wir sollten sie,
> möglicherweise anders als andere IDs, zur Anzeige bringen, denn diese
> Nummer ist der im nationalen Kontext verbindliche Identifier (wie eine
> ISBN) und sollte zur Ansicht gebracht werden.
>
> Viele Gruesse,
> Ihr
> Th. Stäcker
>
>
>
>
> Meyer, Sebastian schrieb:
> > Liebe KollegInnen,
> >
> > gerade bin ich dabei, die Ergebnisse des letzten Arbeitstreffens in
> Dresden und die Anmerkungen und Fehlermeldungen von Herrn Heiligenhaus
> umzusetzen. Dabei ist mir ein Widerspruch aufgefallen, den ich gerne zur
> Diskussion stellen möchte.
> > Während des Arbeitstreffens hatten wir uns darauf verständigt, für
> die VD16/17-Nummer eigentlich nur ungern eine Sonderbehandlung umsetzen
> zu wollen. Die Argumentation war, dass die VD16/17-Nummern als
> Identifier aus Sicht des DFG-Viewers nicht mehr- oder minderwertiger
> sind als andere Identifier auch. In sofern wäre eine Sonderbehandlung
> also nicht gerechtfertigt, solange man diese dann nicht auch jedem
> anderen Identifier zukommen lässt. Die Frage war also: wollen wir
> potentiell jeden Identifier individuell behandeln oder lieber alle
> Identifier gleich?
> > Die Meinung ging eigentlich eher zu zweiterem, was jedoch im
> Widerspruch dazu steht, dass die VD16/17-Identifier nun doch an anderer
> Stelle und in anderer Form angezeigt werden sollen, als beispielsweise
> URN, PURL oder PPN.. Das jedoch vor allem vor dem Hintergrund, dass die
> VD16/17-Nummern nicht persistent sind und deshalb nicht als "persistente
> Identifier" erscheinen sollen.
> >
> > Mein Vorschlag wäre nun, dass wir die VD16/17-Nummern (genauso wie
> jeden anderen in MODS angegebenen Identifier) doch auch weiterhin im
> Abschnitt "Persistente Identifier" aufführen, diesen Abschnitt aber
> künftig eben nicht mehr "persistent" nennen. Kurzum: wir ändern
> gegenüber der jetzigen Anzeigeform im Test-System
> (http://test.dfg-viewer.de/) nichts als die Bezeichnung "Persistente
> Identifier" zu "Identifier".
> >
> > Was meinen Sie?
> >
> > Viele Grüße
> > Sebastian Meyer
> >
> > --
> >
> > Sebastian Meyer
> > Projekt-Mitarbeiter
> >
> > Sächsische Landesbibliothek -
> > Staats- und Universitätsbibliothek Dresden (SLUB)
> > 01054 Dresden
> > Tel.: +49 351 4677-206
> > Fax: +49 351 4677-711
> > http://www.slub-dresden.de/
> >
> >
>
>
> --
> Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung)
> Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel
> Tel. +49(0)5331/808-119 - email: staecker(a)hab.de
>
>
--
Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung)
Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel
Tel. +49(0)5331/808-119 - email: staecker(a)hab.de
--
Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung)
Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel
Tel. +49(0)5331/808-119 - email: staecker(a)hab.de
Liebe KollegInnen,
gerade bin ich dabei, die Ergebnisse des letzten Arbeitstreffens in Dresden und die Anmerkungen und Fehlermeldungen von Herrn Heiligenhaus umzusetzen. Dabei ist mir ein Widerspruch aufgefallen, den ich gerne zur Diskussion stellen möchte.
Während des Arbeitstreffens hatten wir uns darauf verständigt, für die VD16/17-Nummer eigentlich nur ungern eine Sonderbehandlung umsetzen zu wollen. Die Argumentation war, dass die VD16/17-Nummern als Identifier aus Sicht des DFG-Viewers nicht mehr- oder minderwertiger sind als andere Identifier auch. In sofern wäre eine Sonderbehandlung also nicht gerechtfertigt, solange man diese dann nicht auch jedem anderen Identifier zukommen lässt. Die Frage war also: wollen wir potentiell jeden Identifier individuell behandeln oder lieber alle Identifier gleich?
Die Meinung ging eigentlich eher zu zweiterem, was jedoch im Widerspruch dazu steht, dass die VD16/17-Identifier nun doch an anderer Stelle und in anderer Form angezeigt werden sollen, als beispielsweise URN, PURL oder PPN. Das jedoch vor allem vor dem Hintergrund, dass die VD16/17-Nummern nicht persistent sind und deshalb nicht als "persistente Identifier" erscheinen sollen.
Mein Vorschlag wäre nun, dass wir die VD16/17-Nummern (genauso wie jeden anderen in MODS angegebenen Identifier) doch auch weiterhin im Abschnitt "Persistente Identifier" aufführen, diesen Abschnitt aber künftig eben nicht mehr "persistent" nennen. Kurzum: wir ändern gegenüber der jetzigen Anzeigeform im Test-System (http://test.dfg-viewer.de/) nichts als die Bezeichnung "Persistente Identifier" zu "Identifier".
Was meinen Sie?
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Projekt-Mitarbeiter
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
http://www.slub-dresden.de/
Lieber Herr Bigger,
versuchen Sie es mal mit einer Änderung im obersten DIV Ihrer physical-structMap:
<mets:div ID="phy_IBB_5_000057805" DMDID="md_IBB_5_000057805" ADMID="amd_IBB_5_000057805">
-->
<mets:div ID="phy_IBB_5_000057805" TYPE="physSequence">
Beste Grüße,
Kay Heiligenhaus
> -----Original Message-----
> From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> viewer.de] On Behalf Of Andreas Bigger
> Sent: Monday, July 13, 2009 11:35 AM
> To: dv-technik(a)dfg-viewer.de
> Subject: [DFG-Viewer] METS-Problem?
>
> Liebe Listenmitglieder,
>
> Ich bin nicht sicher, ob die Technik-Liste für diese Frage die richtige
> Adresse ist. Jedoch scheint mir die Support-Liste aus ihrer
> Beschreibung
> heraus noch weniger geeignet.
>
> Ich bin gerade dabei zu schauen, ob der DFG-Viewer für uns hier in
> Basel
> eine Option wäre, um Digitalisate im Netz anzubieten. Dazu wollte ich
> einfach mal den DFG-Viewer mit einem METS-File + Digitalisaten
> "beschiessen" und sehen, was dabei herauskommt:
> http://dfg-
> viewer.de/show/?set%5Bmets%5D=http%3A%2F%2Fwww.ub.unibas.ch%2Fcmsdata%2
> Fdfgviewertest%2Fmetsbsp-ub.xml
>
> Soweit so gut. Der Viewer findet das METS-File, aber die Bilder nicht.
> Meldung: "Das Bild scheint nicht erreichbar zu sein."
>
> Was konnte ich feststellen:
> - Die Bilder sind im Netz erreichbar für jedermann (sie sind zwar nicht
> 1000 Pixel breit, sondern nur ca. 800, das dürfte ihn aber wohl nicht
> stören?)
> - Die METS-Struktur validiert mit dem SLUB-METS-Validator
> - Die Verweise innerhalb der Struktur scheinen mir nach meinem
> (begrenzten) METS-Verständnis in Ordnung.
>
> Kann mir jemand einen Tipp geben, wo ich fehlgegangen bin?
>
> Mit bestem Dank im Voraus und freundlichen Grüssen
> Andreas Bigger
>
> --
> UNIVERSITÄT BASEL
> Universitätsbibliothek
> Dr. Andreas Bigger
> Wiss. Mitarbeiter IT / Koordinator Digitalisierung
> Schönbeinstrasse 18-20
> 4056 Basel, Schweiz
> Tel. direkt +41 (0)61 267 0977
> E-Mail Andreas.Bigger(a)unibas.ch
> URL http://www.ub.unibas.ch/
Liebe Listenmitglieder,
Ich bin nicht sicher, ob die Technik-Liste für diese Frage die richtige
Adresse ist. Jedoch scheint mir die Support-Liste aus ihrer Beschreibung
heraus noch weniger geeignet.
Ich bin gerade dabei zu schauen, ob der DFG-Viewer für uns hier in Basel
eine Option wäre, um Digitalisate im Netz anzubieten. Dazu wollte ich
einfach mal den DFG-Viewer mit einem METS-File + Digitalisaten
"beschiessen" und sehen, was dabei herauskommt:
http://dfg-viewer.de/show/?set%5Bmets%5D=http%3A%2F%2Fwww.ub.unibas.ch%2Fcm…
Soweit so gut. Der Viewer findet das METS-File, aber die Bilder nicht.
Meldung: "Das Bild scheint nicht erreichbar zu sein."
Was konnte ich feststellen:
- Die Bilder sind im Netz erreichbar für jedermann (sie sind zwar nicht
1000 Pixel breit, sondern nur ca. 800, das dürfte ihn aber wohl nicht
stören?)
- Die METS-Struktur validiert mit dem SLUB-METS-Validator
- Die Verweise innerhalb der Struktur scheinen mir nach meinem
(begrenzten) METS-Verständnis in Ordnung.
Kann mir jemand einen Tipp geben, wo ich fehlgegangen bin?
Mit bestem Dank im Voraus und freundlichen Grüssen
Andreas Bigger
--
UNIVERSITÄT BASEL
Universitätsbibliothek
Dr. Andreas Bigger
Wiss. Mitarbeiter IT / Koordinator Digitalisierung
Schönbeinstrasse 18-20
4056 Basel, Schweiz
Tel. direkt +41 (0)61 267 0977
E-Mail Andreas.Bigger(a)unibas.ch
URL http://www.ub.unibas.ch/
Lieber Herr Meyer, liebe Kolleginnen und Kollegen,
die ersten Titel aus dem zum 1.7. gestarteten VD16-Digitalisierungsprojekt der ULB Sachsen-Anhalt sind in der zurückliegenden Woche online gegangen. Wir haben uns die Darstellung der Titel im DFG-Viewer-Testsystem nun näher angeschaut und sehen noch hier und da einen gewissen Klärungsbedarf. Hier zunächst ein Beispiel:
http://test.dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fdigitale.bibliothek.un…
Wie man sehen kann, wird nun die VD16-Nummer korrekt aus den MODS-Daten übernommen. Was noch nicht korrekt funktioniert, ist die Verlinkung auf den VD16-Katalog der BSB. Der Viewer generiert folgenden Link:
http://bvba2.bib-bvb.de/V/?func=find-1&BASE=BVB00560&find_code_1=WVD&find_r…
Anscheinend stellen die Leerzeichen in VD16-Nummern, die ja durchgängig vorhanden sind, noch ein Problem bei der Datenextraction dar. Aber selbst, wenn man den Link von Hand korrigiert, führt dieser in eine "normale Suchabfrage" im VD16, nicht direkt auf die Titeldaten:
http://bvba2.bib-bvb.de/V/?func=find-1&BASE=BVB00560&find_code_1=WVD&find_r…
Der Nutzer muß dann von hier aus erst weiterklicken. Besser wäre es m.E., man würde auf den Nachweis direkt verlinken können. Dies bietet die BSB auch an:
http://gateway-bayern.bib-bvb.de/aleph-cgi/bvb_suche?sid=VD16&find_code_1=W…
m.E. sollte, wenn überhaupt, dieser Link verwendet werden und mit der BSB geklärt, ob es sich hier um eine "permanente Verlinkungsmöglichkeit" handelt oder ob häufigere Änderungen geplant sind.
Dann aber auch grundsätzlich zur Darstellungsform: Der VD16-Identifier wird im Viewer als "gleichwertig" zum URN betrachtet:
Persistente Identifier (Werk): ZV 12706, urn:nbn:de:gbv:3:1-101863
Nun ist die VD16-Nummer aber keinesfalls etwas, was persistent dem digitalisierten Exemplar eines Werkes zuzuordnen ist (wie der URN) und folglich eine persistente Zitationsmöglichkeit der Netzpublikation desselben darstellt, sondern sie stellt einen eindeutigen Identifier des Katalogeintrages dieses Werkes dar (und das, anders als URIs, in einem "proprietären Format", der keinerlei Internetstandards folgt, wie das etwa bei URNs und PURLs der Fall ist). Von daher war auch der erste Vorschlag, den wir hier in der Liste diskutiert haben, die VD16-Nummer hinter die bibliographische Angaben zu stellen in eckigen Klammern (wie es Praxis bei der Webpräsentation der BSB ist):
Possel, Johannes <der Ältere>: REGVLAE || VITAE, VERSIBVS || GRAECIS ILLVSTRATAE,|| ET POSTREMO AVCTAE || ac recognitae.|| IN FINE ADDITA || EST BREVIS ET ERVDITA || EAQVE GEMINA ORATIO-||nis Dominicae explicatio.|| ITEM, APPENDIX DE || PROMISSIONIBVS ET COM-||minationibus diuinis, digna conside-||ratione, Graecè & Latinè.|| AVTORE || JOHANNE POSSELIO.|| Leipzig (1594) [VD 16 ZV 12706]
Die Verlinkung des Katalogeintrages sehe ich weiterhin in der mets:digiprovMD-Section richtig aufgehoben. So machen wir das auch weiterhin für VD16-Titel:
<dv:links>
<dv:reference>http://gateway-bayern.bib-bvb.de/aleph-cgi/bvb_suche?sid=VD16&find_code_1=W… 21600</dv:reference>
<dv:presentation>http://digitale.bibliothek.uni-halle.de/ulbhalvd16/id/994395</dv:presentation>
</dv:links>
Ein separate Verlinkung im Viewer scheint mir vor diesem Hintergrund nicht notwendig - zumindest sollte man über deren Notwendigkeit m.E. diskutieren. Formal problematisch finde ich es auf jeden Fall, sich aus verschiedenen Stellen der DFG-Viewer-Profils zu bedienen, um Navigationsmöglichkeiten zu anderen Portalen aufzubauen. Das hieße nämlich perspektivisch, daß wir bald für jede "besondere Nachweisform" von Katalogisaten unserer Digitalisate neue Identifier einführen müssen und den Viewer zum "Resolving-Dienst" für diese Identifier umfunktionieren. Mit <dv:links/> hatten wir aber bewußt eine Möglichkeit geschaffen, daß sich die nutzenden Projekte selbst um Katalogreferenzen kümmern und diese eben auch projektspezifisch modifizieren können.
Soweit zu diesem Themenfeld. Ich bin gespannt auf evtl. Rückmeldungen.
Beste Grüße,
Kay Heiligenhaus
