Lieber Herr Meyer,
prima! Ich sehe bei wenigen Punkten - insbesondere bzgl. des Designs der "Introseite" für mehrbändige Werke sowie der Positionierung der Strukturdatenliste - noch Diskussionsbedarf, aber finde das eine sehr gute erste Umsetzung!
Zwei kurze Frage noch:
1) Die OAI-Anbindung für v2 haben Sie noch nicht umgesetzt? Das funktioniert bei meinen Beispielen nicht mehr, v2 scheint aktuell nur mit "nacktem METS" klarzukommen.
2) Schon in v1 trat das Problem auf, daß bei einigen Werken aus Halle kein Logo angezeigt wird und auch die Links zur lokalen Präsentation und zum OPAC nicht korrekt interpretiert werden. Ein Beispiel ist: http://dfg-viewer.de/v1/?set[mets]=http%3A%2F%2Fdigitale.bibliothek.uni-hal…. Ich kann im gelieferten OAI-METS auf Anhieb keinen Fehler erkennen. Haben Sie eine Idee? (Das Problem tritt auch in v2 auf, wenn man die Daten nicht über OAI anliefert. Über OAI erscheint nur eine weiße Seite.)
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 Meyer, Sebastian
> Sent: Thursday, September 25, 2008 6:00 PM
> To: ralf.goebel(a)dfg.de
> Cc: technik(a)dfg-viewer.de; Bürger, Dr. Thomas
> Subject: [DFG-Viewer] DFG-Viewer v2.0
>
> Lieber Herr Goebel,
>
> leider doch nicht so schnell wie erhofft habe ich nun den DFG-Viewer so
> gut wie fertig gestellt.
>
> http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fdigital.slub-
> dresden.de%2FMulti.xml
>
> Unter dem Link können Sie sich den Viewer anhand eines Beispiels eines
> mehrbändigen Werks anschauen. Wie Sie sehen, funktioniert die
> Navigation anhand der Strukturdaten ebenso wie die Navigation vom
> mehrbändigen Werk zum Band und umgekehrt. Auch der Download von
> Einzelseiten und Gesamtwerk ist möglich, sofern entsprechende Angaben
> in METS vorhanden sind. Die Anzeige der persistenten Identifier erfolgt
> nun unterhalb der Titeldaten, so dass sie leicht kopiert und im Fall
> von URLs auch gleich angeklickt werden können.
> Auf Ihren Hinweis hin kann man nun auch mit Klick auf das Image
> weiterblättern, außerdem ist das Blättern mit der Plus- bzw. Minustaste
> möglich (dazu müssen jedoch je nach Browser noch weitere Tasten wie
> Strg, Alt, etc. zusätzlich gedrückt werden - eine komfortablere
> Javascript-Umsetzung mache ich noch). Auch werden sämtliche externen
> Links nun in einem separaten Fenster geöffnet und das DFG-Logo verweist
> direkt auf die Informationsseite für Digitalisierungsprojekte.
>
> Die Hervorhebung des aktuellen Navigationspunkts erledige ich morgen
> noch. Die Sprachumschalter sind ebenfalls noch nicht aktiv, was daran
> liegt, dass noch keine Übersetzungen vorliegen. Diese wollen wir
> gemeinsam mit der Übersetzung der Dokumentation und METS/MODS-Profile
> in Auftrag geben, wobei ich immer noch auf die Fertigstellung des MODS-
> Profils durch Frau Levergood warte.
>
> Ich werde mich morgen auch noch intensiv um die Fehlersuche und -
> bereinigung kümmern, so dass die Version 2.0 dann im Laufe des morgigen
> Abends offiziell freigegebenen werden kann.
>
> Viele Grüße
> Sebastian Meyer
>
> --
> ___________________________________________________
>
> Sebastian Meyer
>
> Abteilung Informationstechnologie
> Referat Entwicklung
>
> Sächsische Landesbibliothek -
> Staats- und Universitätsbibliothek Dresden (SLUB)
> 01054 Dresden
> Besucheradresse: Zellescher Weg 18
>
> Tel.: +49 351 4677-206
> Fax: +49 351 4677-711
> Mail: smeyer(a)slub-dresden.de
> Web: http://www.slub-dresden.de/
> ___________________________________________________
>
Lieber Herr Meyer,
vielen Dank für die Hinweise! Da muß sich bei einem der letzten Updates ein Bug eingeschlichen haben.
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 Meyer, Sebastian
> Sent: Friday, September 26, 2008 3:30 PM
> To: technik(a)dfg-viewer.de
> Subject: Re: [DFG-Viewer] DFG-Viewer v2.0
>
> Lieber Herr Heiligenhaus,
>
> und noch ein Fehler in Ihrem METS, der verhindert, dass die
> Strukturdaten in der Navigation mit dem korrekten Image verlinkt
> werden: In den structLinks steht häufiger "phy123" statt "phys123".
> Dadurch kann der Viewer logische und physische Struktur nicht korrekt
> verknüpfen.
>
> Viele Grüße
> Sebastian Meyer
>
> --
> ___________________________________________________
>
> Sebastian Meyer
>
> Abteilung Informationstechnologie
> Referat Entwicklung
>
> Sächsische Landesbibliothek -
> Staats- und Universitätsbibliothek Dresden (SLUB)
> 01054 Dresden
> Besucheradresse: Zellescher Weg 18
>
> Tel.: +49 351 4677-206
> Fax: +49 351 4677-711
> Mail: smeyer(a)slub-dresden.de
> Web: http://www.slub-dresden.de/
> ___________________________________________________
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> > viewer.de] Im Auftrag von Kay Heiligenhaus
> > Gesendet: Freitag, 26. September 2008 13:28
> > An: technik(a)dfg-viewer.de
> > Betreff: Re: [DFG-Viewer] DFG-Viewer v2.0
> >
> > Lieber Herr Meyer,
> >
> > prima! Ich sehe bei wenigen Punkten - insbesondere bzgl. des Designs
> > der "Introseite" für mehrbändige Werke sowie der Positionierung der
> > Strukturdatenliste - noch Diskussionsbedarf, aber finde das eine sehr
> > gute erste Umsetzung!
> >
> > Zwei kurze Frage noch:
> >
> > 1) Die OAI-Anbindung für v2 haben Sie noch nicht umgesetzt? Das
> > funktioniert bei meinen Beispielen nicht mehr, v2 scheint aktuell nur
> > mit "nacktem METS" klarzukommen.
> >
> > 2) Schon in v1 trat das Problem auf, daß bei einigen Werken aus Halle
> > kein Logo angezeigt wird und auch die Links zur lokalen Präsentation
> > und zum OPAC nicht korrekt interpretiert werden. Ein Beispiel ist:
> > http://dfg-
> > viewer.de/v1/?set[mets]=http%3A%2F%2Fdigitale.bibliothek.uni-
> >
> halle.de%2Foai%2F%3Fverb%3DGetRecord%26metadataPrefix%3Dmets%26identifi
> > er%3D444892. Ich kann im gelieferten OAI-METS auf Anhieb keinen
> Fehler
> > erkennen. Haben Sie eine Idee? (Das Problem tritt auch in v2 auf,
> wenn
> > man die Daten nicht über OAI anliefert. Über OAI erscheint nur eine
> > weiße Seite.)
> >
> > 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 Meyer, Sebastian
> > > Sent: Thursday, September 25, 2008 6:00 PM
> > > To: ralf.goebel(a)dfg.de
> > > Cc: technik(a)dfg-viewer.de; Bürger, Dr. Thomas
> > > Subject: [DFG-Viewer] DFG-Viewer v2.0
> > >
> > > Lieber Herr Goebel,
> > >
> > > leider doch nicht so schnell wie erhofft habe ich nun den DFG-
> Viewer
> > so
> > > gut wie fertig gestellt.
> > >
> > > http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fdigital.slub-
> > > dresden.de%2FMulti.xml
> > >
> > > Unter dem Link können Sie sich den Viewer anhand eines Beispiels
> > eines
> > > mehrbändigen Werks anschauen. Wie Sie sehen, funktioniert die
> > > Navigation anhand der Strukturdaten ebenso wie die Navigation vom
> > > mehrbändigen Werk zum Band und umgekehrt. Auch der Download von
> > > Einzelseiten und Gesamtwerk ist möglich, sofern entsprechende
> Angaben
> > > in METS vorhanden sind. Die Anzeige der persistenten Identifier
> > erfolgt
> > > nun unterhalb der Titeldaten, so dass sie leicht kopiert und im
> Fall
> > > von URLs auch gleich angeklickt werden können.
> > > Auf Ihren Hinweis hin kann man nun auch mit Klick auf das Image
> > > weiterblättern, außerdem ist das Blättern mit der Plus- bzw.
> > Minustaste
> > > möglich (dazu müssen jedoch je nach Browser noch weitere Tasten wie
> > > Strg, Alt, etc. zusätzlich gedrückt werden - eine komfortablere
> > > Javascript-Umsetzung mache ich noch). Auch werden sämtliche
> externen
> > > Links nun in einem separaten Fenster geöffnet und das DFG-Logo
> > verweist
> > > direkt auf die Informationsseite für Digitalisierungsprojekte.
> > >
> > > Die Hervorhebung des aktuellen Navigationspunkts erledige ich
> morgen
> > > noch. Die Sprachumschalter sind ebenfalls noch nicht aktiv, was
> daran
> > > liegt, dass noch keine Übersetzungen vorliegen. Diese wollen wir
> > > gemeinsam mit der Übersetzung der Dokumentation und METS/MODS-
> Profile
> > > in Auftrag geben, wobei ich immer noch auf die Fertigstellung des
> > MODS-
> > > Profils durch Frau Levergood warte.
> > >
> > > Ich werde mich morgen auch noch intensiv um die Fehlersuche und -
> > > bereinigung kümmern, so dass die Version 2.0 dann im Laufe des
> > morgigen
> > > Abends offiziell freigegebenen werden kann.
> > >
> > > Viele Grüße
> > > Sebastian Meyer
> > >
> > > --
> > > ___________________________________________________
> > >
> > > Sebastian Meyer
> > >
> > > Abteilung Informationstechnologie
> > > Referat Entwicklung
> > >
> > > Sächsische Landesbibliothek -
> > > Staats- und Universitätsbibliothek Dresden (SLUB)
> > > 01054 Dresden
> > > Besucheradresse: Zellescher Weg 18
> > >
> > > Tel.: +49 351 4677-206
> > > Fax: +49 351 4677-711
> > > Mail: smeyer(a)slub-dresden.de
> > > Web: http://www.slub-dresden.de/
> > > ___________________________________________________
> > >
Lieber Herr Goebel,
leider doch nicht so schnell wie erhofft habe ich nun den DFG-Viewer so gut wie fertig gestellt.
http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fdigital.slub-dresden.de%2FM…
Unter dem Link können Sie sich den Viewer anhand eines Beispiels eines mehrbändigen Werks anschauen. Wie Sie sehen, funktioniert die Navigation anhand der Strukturdaten ebenso wie die Navigation vom mehrbändigen Werk zum Band und umgekehrt. Auch der Download von Einzelseiten und Gesamtwerk ist möglich, sofern entsprechende Angaben in METS vorhanden sind. Die Anzeige der persistenten Identifier erfolgt nun unterhalb der Titeldaten, so dass sie leicht kopiert und im Fall von URLs auch gleich angeklickt werden können.
Auf Ihren Hinweis hin kann man nun auch mit Klick auf das Image weiterblättern, außerdem ist das Blättern mit der Plus- bzw. Minustaste möglich (dazu müssen jedoch je nach Browser noch weitere Tasten wie Strg, Alt, etc. zusätzlich gedrückt werden - eine komfortablere Javascript-Umsetzung mache ich noch). Auch werden sämtliche externen Links nun in einem separaten Fenster geöffnet und das DFG-Logo verweist direkt auf die Informationsseite für Digitalisierungsprojekte.
Die Hervorhebung des aktuellen Navigationspunkts erledige ich morgen noch. Die Sprachumschalter sind ebenfalls noch nicht aktiv, was daran liegt, dass noch keine Übersetzungen vorliegen. Diese wollen wir gemeinsam mit der Übersetzung der Dokumentation und METS/MODS-Profile in Auftrag geben, wobei ich immer noch auf die Fertigstellung des MODS-Profils durch Frau Levergood warte.
Ich werde mich morgen auch noch intensiv um die Fehlersuche und -bereinigung kümmern, so dass die Version 2.0 dann im Laufe des morgigen Abends offiziell freigegebenen werden kann.
Viele Grüße
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
Referat Entwicklung
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Besucheradresse: Zellescher Weg 18
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
Mail: smeyer(a)slub-dresden.de
Web: http://www.slub-dresden.de/
___________________________________________________
Lieber Herr Meyer,
ich habe noch einmal über die Frage der Zweiseitigkeit nachgedacht. Wenn
wir unterstellen, dass alle Bücher einen Rand hätten und nicht
beschnitten sind, könnte man auf der Basis der Tatsache, dass ein Buch
zum Falz hin an die Bildgrenze anschliesst, doch eindeutig definieren,
dass die Seite verso oder recto ist (Farbwert heller oder dunkler als
der Rand). Ist der Falz links, ist es recto, ist der Falz rechts, ist es
verso. So könnte man, wenn man zwei Bildschirmplätze für die rechte und
linke Seite eines Buches vorsieht, immer eindeutig sagen, wo es
hingehört. Wenn z.B. zwei linke Fälze aufeinander folgen (Eingeklebte
Tafel, deren Rückseite nicht aufgenommen wurde), bliebe ein
Bildschirmplatz leer.
Halten Sie so etwas perspektivisch für machbar? Für WF würde ich es mal
versuchen. Ich bin mir aber unsicher, ob man bei allen Einlieferern Rand
um das Objekt unterstellen kann.
Ist aber sicherlich nicht vordringlich.
Viele Gruesse,
Ihr
Th. Stäcker
Liebe Kolleginnen und Kollegen,
ich bin leider nicht mehr dazu gekommen, die METS-Beispiele für mehrbändige Werke von Herrn Meyer hinreichend intensiv zu studieren. Bei meiner "grobe Sichtung" ist mir jedoch nichts aufgefallen, das ich monieren wollte.
Bevor ich nun für drei Wochen in den Urlaub entschwinde, möchte ich allerdings noch kurz einen Vorschlag machen, den man evtl. bei der Finalisierung von Version 1.1 berücksichtigen könnte: Unsere statistischen Auswertungen zeigen, daß sich bei Digitalisierungsportalen RSS-Feeds zunehmender Beliebtheit erfreuen. Nicht nur auf Seiten der Anbieter (wenn ich es recht sehe, trifft das auf alle VD16/17-Pilotprojekte zu), auch auf Seiten der Nutzer. Von daher wäre es m.E. nicht schlecht, wenn wir im Tag <mets:digiprovMD /> noch ein
<dv:feed>http://digitale.bibliothek.uni-halle.de/rss/</dv:feed>
unterbringen könnten. Der Viewer würde das dann in browserkompatibles XHTML wandeln, in aktuellen Browsern sähe der Nutzer sofort, daß es einen Feed zu der Sammlung gibt, aus dem das aktuell angezeigte Werk stammt. Es könnte evtl. auch ein Icon angeboten werden analog zu den sonstigen Links zur lokalen Präsentation. Ersteres würde aber schon reichen. Was meinen Sie?
Beste Grüße,
Kay Heiligenhaus
=======================================
Kay Heiligenhaus
Geschäftsführung
semantics Kommunikationsmanagement GmbH
Viktoriaalle. 45, 52066 Aachen
Tel: +49 241 89 49 89 29
Fax: +49 241 89 49 89 30
eMail: heiligenhaus(a)semantics.de
Web: www.semantics.de
Registergericht: Amtsgericht Aachen, HRB 8189
Geschäftsführer: Prof. Dr. Christian Stetter, Kay Heiligenhaus M.A., Dipl. Ing. José de la Rosa
Liebe Kolleginnen und Kollegen,
was lange währt, wird endlich (hoffentlich) gut: Anbei das ausführliche Beispiel eines mehrbändigen Werks in METS/MODS.
Bei der Erstellung ist mir noch ein kleiner Widerspruch zum METS-Profil aufgefallen. Dort heißt es in "dmdSec Anforderung 1", dass das oberste <div>-Element der logischen <structMap> zwingend ein verknüpftes <dmdSec>-Element besitzen muss. Bei mehrbändigen Werke enthält das oberste <div>-Element der logischen <structMap> allerdings nur das <mptr>-Element zur Verknüpfung mit dem Datensatz des übergeordneten Werks und somit keine verknüpfte <dmdSec>. Ich würde die METS-Anforderung deshalb etwas entschärfen: Grundsätzlich muss mindestens ein <div>-Element der logischen <structMap> eine verknüpfte <dmdSec> besitzen. Zur Identifizierung des Datensatzes wird dabei die <dmdSec> des obersten (hierarchisch und sequentiell) <div>-Elements herangezogen, das eine <dmdSec> besitzt.
Viele Grüße
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
Referat Entwicklung
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Besucheradresse: Zellescher Weg 18
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
Mail: smeyer(a)slub-dresden.de
Web: http://www.slub-dresden.de/
___________________________________________________
Liebe Kollegen,
mir sind ein paar Unstimmigkeiten im METS-Profil aufgefallen. Vielleicht habe ich da aber auch einfach etwas missverstanden:
1. Auf Seite 2 heißt es unter "dmdSec Anforderung 1" im letzten Satz, dass nur <div>-Elemente der logischen <structMap> eine verknüpfte <dmdSec> besitzen dürfen. Das wird auch in "structMap Anforderung 5" noch einmal wiederholt, wobei dort zugleich gesagt wird: "Grundsätzlich können jedem <div> Element ein oder mehrere Metadatensektionen zugeordnet werden. Dies ist unabhängig davon, ob sich das Element in einer logischen und physischen Struktur befindet." In "dmdSec Anforderung 6" heißt es wiederum, dass <dmdSec> auch verwendet werden sollen, um physische Strukturen zu adressieren. Sind verknüpfte <dmdSec>-Elemente in der physischen <structMap> nun erlaubt oder nicht?
Wobei wir uns doch darauf geeinigt hatten, die in "dmdSec Anforderung 6" genannte Adressierung physischer Strukturen über das CONTENTIDS-Attribut in der physischen <structMap> zu lösen, wie es ja auch korrekt in "structMap Anforderung 2" (letzter Absatz) formuliert ist. Zu diesem Zweck wäre eine verknüpfte <dmdSec> also gar nicht nötig.
2. Noch nicht ganz klar ist mir das Zusammenspiel von <mods:identifier>, <mods:relatedItem><mods:recordInfo><mods:recordIdentifier> und <mods:recordInfo><mods:recordIdentifier>. Wenn ich das richtig verstehe, müsste doch in <relatedItem><recordInfo><recordIdentifier> eines Bandes dieselbe ID stehen wie in <recordInfo><recordIdentifier> des übergeordneten Werks? Wenn im Beispiel zu "dmdSec Anforderung 4" also im Band-Datensatz
<relatedItem>
<recordInfo>
<recordIdentifier type="gbv-ppn">
515678759
</recordIdentifier>
</recordInfo>
</relatedItem>
steht, müsste doch zugleich die Anforderung formuliert werden, dass dann in der übergeordneten Einheit sowas stehen muss:
<recordInfo>
<recordIdentifier type="gbv-ppn">
515678759
</recordIdentifier>
</recordInfo>
Oder müsste es dort <identifier type="gbv-ppn">515678759</identifier> heißen? Jedenfalls nützt der <recordIdentifier> doch nichts, wenn er nicht auch in beiden Datensätzen steht.
3. In "fileSec Anforderung 4" heißt es, die Thumbnail-Images müssten eine Breite von 150 Pixeln haben. Richtig ist: sie müssen in ihrer maximalen Ausdehnung 150 Pixel groß sein. Bei Hochkant-Bildern ist also die Höhe auf 150 Pixel beschränkt, bei Querformat-Bildern dagegen die Breite. Die jeweils andere Größe sollte so gewählt werden, dass die Proportionen erhalten bleiben.
4. In "structLink Anforderung 2" muss es im ersten Satz "physische Struktur" statt "logische Struktur" heißen.
Viele Grüße
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
Referat Entwicklung
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Besucheradresse: Zellescher Weg 18
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
Mail: smeyer(a)slub-dresden.de
Web: http://www.slub-dresden.de/
___________________________________________________
Lieber Herr Stäcker,
> Ja, Sie haben recht, ich empfinde nur das "Verzeigern" immer als etwas
> dem XML eigentlich Fremdes und gehöre eher zu den Schachtelfreunden.
> Ist meist auch leichter zu prozessieren.
So sehe ich es grundsätzlich auch. So haben es die METS-Architekten - aus welchen Gründen auch immer - aber eben de facto nicht gesehen. MODS verfährt hier ja anders. Aber: Die Welt ist alles, was der Fall ist. Wovon man nicht sprechen kann, darüber muß man schweigen. ;)
> Das Problem, das ich jetzt habe, ist, dass ich mangels geiegneter
> Anwendungen (ich habe diese Woche noch einen Termin in dieser Sache),
> im Grunde im Moment nicht vollen Herzens Ja sagen kann. Ich verstehe aber,
> dass es pressiert.
Mich pressiert es nur insoweit, daß ich da gerne entwicklungstechnisch einen Strich drunter machen möchte. Eine spätere Änderung halte ich aber für unkritisch. Viel wichtiger scheint mir zu sein, daß Herr Meyer "seinen" Termin im Oktober halten kann und eben auch, daß zvdd in absehbarer Zeit damit eben auch zurande kommt, vor allem: sichtbar wird. Ich hatte ja schon gesagt, daß ich es für problematisch halte, allzulange über vermeintliche "Fiktionen" zu reden, ohne, daß man ein Ergebnis sehen kann...
> So gesehen, können wir ja erst einmal damit
> Erfahrungen sammeln, wenn wir Pech haben, kommt uns eben ein dicker
> Klopfer in die Quere und wir (Sie) müssen nachbasteln (ich bin aber
> zuversichtlich, dass das nicht der Fall ist). Eines hätte ich jedoch
> vor einem Ja und Amen vorher schon gern noch, nämlich ein Beispiel mit
> Artikelebene. Das mache ich dann nach dem Gespräch mit den
> Zeitschriftenkollegen fertig. Bis wann geben Sie uns denn Zeit ;-)
s.o. Hier wären eigentlich eher Herr Meyer, Frau Levergood und Herr Funke gefragt aus meiner Sicht. Sicherlich auch Frau Federbusch, da in Berlin wahrscheinlich der größte Bestand an Zeitschriften-Digitalisaten vorliegt.
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Stäcker,
> Ich habe im Moment eigentlich zur Diskussion nicht mehr viel
> beizutragen. Allenfalls dies, dass mit eine Schachtelung der dmdsec
> sinnvoll erscheint, um die Abhängigkeitsverhältnisse deutlich zu machen
> (wenn das das Schema hergibt):
>
> Also
>
> <dmdsec Zeitschrift>
> <dmdsec Volume 1/>
> <dmdsec Volume 2/>
> <dmdsec Volume n/>
> </dmdsec>
>
> Im Artikelsatz dann
>
> <dmdsec Volume 1>
> <dmdsec Artikel 1/>
> <dmdsec Artikel 2/>
> <dmdsec Artikel n/>
> </dmdsec>
>
> Wenn das nicht geht (was ich gerade mangels geeignetem Parser nicht
> pruefen kann), sollte aus dem Dokument die Zugehörigkeit durch Pointer
> ersichtlich sein.
Soweit ich das gerade ausgetestet habe, geht eine solche Konstruktion nicht. Es wäre auch etwas "doppelt gemoppelt" aus meiner Sicht. Die METS-DIV-Hierarchie macht hier ja die strukturellen Zusammenhänge deutlich, die Pointer verzeigern die jeweiligen Navigationsmöglichkeiten.
Unterm Strich scheinen wir uns also einig zu sein. Blieben evtl. Anmerkungen von den weiteren Beteiligten. In Anbetracht unserer vereinbarten Zeitschiene sollten wir hier allerdings nicht mehr allzuviel Zeit verstreichen lassen.
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Stäcker,
nur kurz vorneweg, für die anderen in der Runde: Sie antworten auf einen Reply von mir auf eine Mail von Ihnen, die vorher nicht an die Liste ging. Deshalb sind da einige Zitate, die die anderen wohl (noch) nicht kennen. ;)
> > 1. METS der Zeitschrift findet sich unter: http://ulbhal-
> dev.semantics.de/dmg/oai/?verb=GetRecord&metadataPrefix=mets&identifier
> =258774
>
> Genaus das, dass im Datensatz der Zeitschrift (!) die dmd des Volumes
> steht, hatte ich nicht verstanden. Im Moment steht in diesem Satz eine
> zweite dmdsec mit
>
> <mods:part order="1">
> −
> <mods:detail type="volume">
> <mods:number>Jg. 1943</mods:number>
> </mods:detail>
> </mods:part>
>
> Bedeutet das, dass sie falls es hier mehere Volumes zu einer
> Zeitschrift gibt, was es ja wohl meist gibt, diese alle hier listen wollen?
Ja. Genau so verhält es sich. Die Idee dahinter ist folgende: Aus der ZDB (oder einem anderen Nachweisinstrument) wird via URN (oder einem sonstigen, persistenten Identifier/Link) auf eine digitalisierte Zeitschrift verwiesen. Diese wird (nach Vorgabe der Praxisregeln) primär über den Viewer angezeigt. In diesem Falle (Periodikum) zeigt der Viewer eine Liste der vorhandenen Bände an. Im nächsten Schritt wählt der Nutzer einen davon aus - und gelangt: in die Darstellung des Bandes.
> Ich hatte dies nicht als Datensatz für die Zeitschrift, sondern fuer das
> Volume verstanden, dem die Zeitschriftenaufnahme (eben der
> Bequemlichkeit wegen) beigegeben wurde. Mit anderen Worten, die feinste
> Granularitaet definiert die Art des Datensatzes.
Da lag Ihr Mißverständnis.
> > 2. METS des (einen vorhandenen) Bandes findet sich unter:
> http://ulbhal-
> dev.semantics.de/dmg/oai/?verb=GetRecord&metadataPrefix=mets&identifier
> =258380
>
> Das scheint dann das zu sein, was ich unter 1. mutmasste.
Korrekt.
> Nur scheinen hier alle Seiten (images), die zu dem Volume gehören gelistet zu sein.
> Korrekt? Eine Artikelebene gibt es hier anscheinend nicht. Diese haben
> Sie in die structMap verbannt. Hmm. Ich haette die Artikel in eine
> dmdsec und nicht in die StructMap geschreiben, weil es sich um
> bibliographische nicht Strukturdaten handelt. Ich habe hier offenbar
> mit RAK fuer unselbstaendige Werke eine andere Struktur im Kopf.
Wie schon mal gesagt: das wäre die "Luxusvariante". Es liegen _echte_ Metadaten auf Artikelebene vor. In diesem Falle würde man einfach eine weitere Ebene einziehen können: Analog zu den Bänden einer Zeitschrift würden dann <mptr>s und <dmdSec>s für die einzelnen Artikel geliefert. Eine offene Frage wäre hier: Wie stellt man Titelblätter, Inhaltsverzeichnisse usw. dar? Auch nach RAK-UW ja keine Enheiten, die "metadatenwürdig" wären. ;)
> Ich baue Ihnen mal ein Beispiel zusammen. Das schaffe ich heute aber nicht mehr.
Das Beispiel kann ich mir gut vorstellen. In Ermangelung eines aktuellen Projektes, das bereits über solche auf aktuellem Stand verfügt, konnte ich kein solches liefern. Ich könnte aber ebenfalls eines: fingieren für das Hallesche ZDMG-Projekt.
> > 3. Im METS der Zeitschrift finden sich: Alle vorhandenen (hier also
> genau einer) Bände, die jeweils im DIV referenziert werden:
> >
> > <mets:div ID="id201432-4_201432-4_J_1943_B_097" LABEL="Jg. 1943"
> TYPE="volume" ORDER="1" DMDID="sd258380">
> > <mets:mptr LOCTYPE="URL" xlink:href="http://ulbhal-
> dev.semantics.de/dmg/oai/?verb=GetRecord&metadataPrefix=mets&identifier
> =258380"/>
> > </mets:div>
>
> S. oben, Sie würden dann wohl alle vorhandenen Bände listen. Ich würde
> nur die Zeitschrift nennen, dann die einzelnen Bände mit Zeitschrift,
> dann in einer eigenen dmdsec die Aufsätze mit den redundanten einzelnen
> Bänden und der Zeitschrift. Ich haett edann drei dmdsec.
S. ebenfalls oben. Aus meiner Sicht sollte im ersten Schritt bereits eine Bandübersicht geboten werden.
> > 4. Zum Band finden sich, wie Sie richtig schreiben, ebenfalls
> Metadaten in der dmdSec. Der Viewer kann diese auswerten, um
> Informationen über die verfügbaren Bände darzustellen.
>
> Stimmt für den Viewer ist das einfacher. Je mehr ich darüber nachdenke,
> umso mehr kann ich mich damit anfreunden.
Ich persönlich finde das sehr praktisch. Außerdem würde das ein "Grundproblem" bei der Konversion von MAB2 zur MARC21 auffangen (aus meiner Sicht).
> Also, wenn ich recht verstehe liefern Sie
>
> 1) Die Zeitschrift mit allen verfügbaren Volumes, was es dem Viewer
> leicht macht, diese anzuzeigen. Images gibt es hier nicht. Damit waere
> ich einverstanden, ich muss nur schauen, wie ich das aus PICA
> herausprozessiere.
Korrekt.
> 2) Das einzelne Volume samt der übergeordneten Zeitschrift mit allen
> untergeordneten Seiten (images). Die Artikel werden als Strukturdaten
> aufgefasst.
Korrekt.
> Mit letzterem haette ich Bauschmerzen und würde dem Artikel eine eigene
> DMD gönnen.
Yep. Wenn Metadaten vorhanden sind. Was eben nicht immer der Fall ist (ich bemühe nochmal den frühen Wittgenstein: "Die Welt ist alles, was der Fall ist." ;)
> Nun müssten auch hier analog zum Zeitschrift-Volume
> Verhältnis alle Artikel aufgelistet werden. Das führt zu einem weiteren
> Satz, in den dann nur die Images in Relation zum Artikel aufgelistet
> werden.
Jetzt sind wir: beieinander.
> Innerhalb der Artikel gibt es dann echte Strukturdaten
> (Zwischenüberschriften, Abbildungen etc.). Man kann das natürlich auch
> alles in eine Datei packen.
Korrekt.
> Ich lasse mir das noch einmal durch den Kopf gehen und baue einmal ein
> Beispiel. In Praxis sieht es dann möglicherweise wieder ganz anders
> aus. Das Problem dürfte sein, dass wir einmal eine dmdsec-Artikelebene
> haben, manchmal, wie in Ihrem Fall, nicht, weil die Metadaten nicht erhoben
> wurden.
Ich sehe darin kein Problem: Das Modell, das wir jetzt gefunden haben, ist streng rekursiv. Es erlaubt von daher (aus meiner Sicht): das eine, ohne das andere zu verbieten.
> > Ich hoffe, wir reden nicht allzusehr aneinander vorbei. ;)
>
> Nicht wirklich ;-)
Denke ich auch.
Beste Grüße,
Kay Heiligenhaus
