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
Lieber Herr Heiligenhaus,
>
> 1. METS der Zeitschrift findet sich unter: http://ulbhal-dev.semantics.de/dmg/oai/?verb=GetRecord&metadataPrefix=mets&…
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? 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.
>
> 2. METS des (einen vorhandenen) Bandes findet sich unter: http://ulbhal-dev.semantics.de/dmg/oai/?verb=GetRecord&metadataPrefix=mets&…
Das scheint dann das zu sein, was ich unter 1. mutmasste. 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. Ich baue
Ihnen mal ein Beispiel zusammen. Das schaffe ich heute aber nicht mehr.
>
> 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&…"/>
> </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.
>
> 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.
>
>> Warum wird eine eigene dmdSec formuliert? Herr Funk hat doch von eigenen
>> Datensätzen gesprochen, die dann über den Key(Identifier) in
>> relatedItem verbunden würden. Sie haben es aber wohl in einen DS integriert? Sollen
>> alle Volumes plus Zeitschrift in einen Datensatz stehen? Dann haben wir
>> keine eindeutige Über- und Unterordnung mehr.
>
> Doch, über die <mptr/> und die Hierarchien im METS wird die Sache eindeutig. Aber auch im MODS sind die Relationen korrekt abgebildet.
>
>> Ich dachte, Herr Funk meint so etwas:
>>
>> Datensatz 1 (Zeitschrift) -> Datensatz 2 (Volume) -> Datensatz 3
>> Artikel
>
> Yep, so ist es. Und so lese ich auch unsere eigene Implementierung.
>
>> Datensatz 1 ware dann nur über Datensatz 2 zugaenglich. Datensatz 2 nur
>> über Datensatz 3. Oder schreiben wir redundant Datensatz 1 in Datensatz
>> 2? Dann dürfte es aber wohl nur eine dmdsec geben, oder?
>
> Hm, das verstehe ich auch noch nicht so recht, was Sie hier meinen. Was aber richtig ist: DS1 muß in DS2 nicht enthalten sein. Wir haben uns geeinigt (das war ja die Problematik, die Sie bzgl. Ihrer Schnittstellenimplementierung angesprochen hatten), daß die übergeordneten Daten vom auswertenden System ermittelt werden müssen. Wir haben uns allerdings bei unserer Implementierung entschieden, die übergeordneten DS immer auch mitzuliefern. Das macht anderen Nutzern unserer Schnittstellen das Leben leichter, da wir die Auflösung liefern.
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.
2) Das einzelne Volume samt der übergeordneten Zeitschrift mit allen
untergeordneten Seiten (images). Die Artikel werden als Strukturdaten
aufgefasst.
Mit letzterem haette ich Bauschmerzen und würde dem Artikel eine eigene
DMD gönnen. 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. Innerhalb der Artikel gibt es dann echte Strukturdaten
(Zwischenüberschriften, Abbildungen etc.). Man kann das natürlich auch
alles in eine Datei packen.
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 hoffe, wir reden nicht allzusehr aneinander vorbei. ;)
Nicht wirklich ;-)
Viele Gruesse,
Ihr
Th. Staecker
Lieber Herr Stäcker,
bevor ich meine Anmerkungen zum Profil mache ganz schnell:
> P.S. Lieber Herr Heiligenhaus: ich konnte eben auf
>
> http://ulbhal-
> dev.semantics.de/dmg/oai/?verb=GetRecord&metadataPrefix=mets&identifier
> =258774
>
> nicht zugreifen (502 Error).
Daß wir auch immer gleichzeitig an etwas arbeiten müssen. <g> - - - Sollte wieder funktionieren. Ich werkel da gerade in anderen Zusammenhängen dran. Von daher kann diese Entwicklungsumgebung ab und an mal down sein.
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Funk,
nun mein Kommentar zu Ihrem Papier:
S.3 Ich dachte wir hätten die URN Anforderung im Identifier hinter uns
gelassen. Das sollte an den aktuellen Diskussionstand angepasst werden.
Nötig ist auch für zvdd lediglich ein weltweit eindeutiger Identifier,
z.B. ein OAI Identifier, denn Persistenz ist kein Muss fuer die innere
Logik der Datensatzverwaltung in zvdd (vgl. a. S.4), sondern nur für das
"Anspringen" der Ressource. Für diesen Zweck würde ich darüber hinaus
nicht exklusiv auf URN drängen, sondern auch andere IDs zulassen (PURL,
DOI, ARK, HANDLE...).
S. 5 Nachgefragt (auch schon diskutiert): Sind wir uns einig, dass
innerhalb von MODS es nicht um Strukturdaten geht (sprachlich wird hier
auf die "zvdd Strukturdatetypologie" verwiesen), sondern um
bibliographisch beschreibbare Einheiten? Um die Metaphysik aus der
Diskussion zu nehmen, meine ich damit alles, was auch im OPAC steht.
Dann würde CHAPTER, SECTION, PARAGRAPH z.B. vermutlich nicht zur
Anwendung kommen. Das wären Dinge, die in METS abgebildet werden
müssten, nicht in MODS. Das sollten wir vielleicht noch stärker
eingrenzen. Ich schlage vor, hier nur VOLUME (Band eines mehrbändigen
Werkes), ISSUE (Zeitschriftenaufsatz, wenn das hier gemeint ist), PART
(enthal. Werk, Lexikonartikel, Zeitungsartikel und alles was man sonst
als Teil bezeichnen möchte) zuzulassen. Allerdings frage ich mich, ob
diese Differenzierung überhaupt nötig ist. Warum belassen wir es nicht
beim simplen "part" für alles? Oder wieder wie gehabt in part type=host.
Wir bilden doch nur ein Verhältnis von übergeordneter zu Untergeordneter
Einheit ab. Wozu braucht man das? simplex est index veri ;-)
S. 6 Schreibfehler: "logischer ODER" muss "logischen ORDER" heissen
S.11 Nur eine sprachliche Finesse: MAX - enthält nicht Imagedateien, die
der MASTER-Auflösung entsprechen, sondern die größtmögliche online
verfügbare Auflösung. Wie sähe die Struktur bei nur einer Downloaddatei
aus? Bitt auch dafür ein Beispiel bringen, ich vermute so:
<mets:file ID="download_gesamt" MIMETYPE="application/pdf"
SIZE="13000000000">
<mets:FLocat xmlns:xlink="http://www.w3.org/1999/xlink" LOCTYPE="URL"
xlink:href="http://link.to
/pdf/alles.pdf" />
</mets:file>
Was nach meiner Erinnerung noch offen ist, wie dies im Viewer angezeigt
wird. Ich plädiere dafür, erst einmal simple anzufangen und nur ein Link
zum Gesamtdownload zu bieten (wir hatten das andiskutiert). Wo entnimmt
der Viewer diese INformation, hier? Brauchen wir dann in der StructMap
noch etwas Besonderes: <mets:div ID="physDownload" TYPE="physSequence">.
Oder soll er Einzelseiten zusammenrechnen? Dann muss aber eine
Applikation dahinterstehen, die das Downloadpäckchen mundgerecht packt
(wie. z.B. in Göttingen). Das geht aber auch nur auf Basis bitonaler
Daten etcetcicero. (vgl.a. S.18)
S. 16 Schreibfehler "inden die" muss "indem die" heissen
Für die uns hier interessierende wichtigste Diskussion, dem Verhältnis
von Zeitschrift - Band - Artikel fehlt ein Beispiel. Extradateien
scheinen hier auch für den Band gefordert zu werden, das bringt aber
eine Komplexion ein, darin, dass wir es nicht mehr mit einem einfachen
Über- oder Unterordnungsverhätnis zu tun haben, sondern mit einer
qualitativ anderen Zwischenstufe (Jahrgang, Band). Das sollten wir
vermeiden. Der Jahrgang ist ein Überordnungstyp, so wie die Zeitschrift
zum Jahrgang. INsofern gibt es eine Verknüpfung mit einer "extra" Datei,
aber das System ist blind gegen dei Ebene dahinter und bekommt die
INformation zu Artikeln erst auf der Bandebene, nicht auf der
Zeitschriftenebene. Aber hier bräuchte ich, wie gesagt ein Beispiel, um
es wirklich nachvolziehen zu können.
S. 20 Schreibfehler: Verweisarte
Soweit zu meiner Lektüre. Das ist wirklich eine sehr hilfreiche
Zusammenfassung unserer Arbeitsergebnisse, durchuas auch mit Blick auf
die Abgrenzung von zvdd und DFG-Viewer.
Schön wäre etwas mehr Anschaulichkeit im Bereich Zeitschriften. Ich
weiss eigentlich jetzt nach der Lektüre immer noch nicht genau, wie eine
Zeitschriftenstruktur von Zeitschrift - Band - Artikel genau aussehen
soll.
Wenn wir dies genannte Beispiel von Herrn Heiligenhaus nehmen:
<mods:part order="1">
<mods:detail type="volume">
<mods:number>Jg. 1943</mods:number>
</mods:detail>
</mods:part>
Welchen Identifier haette Jg. 1943?
Viele Gruesse,
Ihr
Th. Stäcker
P.S. Lieber Herr Heiligenhaus: ich konnte eben auf
http://ulbhal-dev.semantics.de/dmg/oai/?verb=GetRecord&metadataPrefix=mets&…
nicht zugreifen (502 Error).
Lieber Herr Stäcker,
> nach meinem ersten turbulenten Arbeitstag nach dem Urlaub nur die
> Bitte, dass Sie mir, auch wenn es Sie jetzt drängt, das Thema
> Zeitschriftenstruktur abzuschliiessen, noch bis Ende der Woche (meint
> inklusive Wochenende ;-)Zeit geben, mir die Struktur von Herrn Funke
> noch einmal en detail anzusehen. ich bin leider bisher nicht dazu
> gekommen.
Kein Problem. Ich habe mir den Entwurf von Herrn Funk auch noch nicht so intensiv durchgesehen, wie es notwendig ist. Und werde ebenfalls bemüht sein, das bis zum Wochenende hinzubekommen. Da wir inzwischen ziemlich viele Projekte angehen, die sich der Erschließung von Periodika widmen, drängt es mich an dieser Stelle am meisten. Aber auch bzgl. der mehrbändigen Werke wäre ein Beispiel von Herrn Meyer nicht schlecht. Der scheint aber gerade ebenfalls: ziemlich eingebunden. ;)
Wie steht es denn mit dem MODS-Profil Vers. 1? Mir scheint, auch in Göttingen sind aktuell die meisten Aktanten im verdientem Urlaub...
Beste Grüße,
Kay Heiligenhaus
