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
Lieber Herr Meyer,
alles klar. - - - Dann noch kurz die Frage in die Runde, ob es noch Änderungsbedarf bzgl. der Darstellung von Zeitschriften gibt. Wenn ich das richtig gesehen habe, hat Herr Funk ja den Vorschlag so in die METS-Doku 1.0 übernommen. Auch ansonsten kamen keine Anmerkungen, evtl. aber bedingt durch die Urlaubszeit. Für uns wäre wichtig, hier relativ bald zu einem finalen Stand zu gelangen. Auf unserer "internen Roadmap" ist das Thema nämlich eigentlich nun abgefackelt. ;)
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: Monday, August 04, 2008 5:55 PM
> To: technik(a)dfg-viewer.de
> Subject: Re: [DFG-Viewer] Auswertung von Ortsangaben im Viewer
>
> Lieber Herr Heiligenhaus,
>
> ja, das ist richtig. Der Viewer ignoriert da (noch) die Attribute.
> Steht auch auf meiner v1.1-Todoliste. :)
>
> 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, 1. August 2008 18:17
> > An: technik(a)dfg-viewer.de
> > Betreff: [DFG-Viewer] Auswertung von Ortsangaben im Viewer
> >
> > Liebe Kolleginnen und Kollegen,
> >
> > vielleicht hat sich ja schon jemand angemeldet... Ich eröffne mal den
> > Technik-Reigen mit einer Implementierungsfrage. Wir importieren
> aktuell
> > Daten aus der ZDB. Dabei entstehen im <originInfo>-Block solche
> > Konstrukte:
> >
> > <mods:place>
> > <mods:placeTerm type="code" authority="marccountry"
> > >DX</mods:placeTerm>
> > </mods:place>
> > <mods:place>
> > <mods:placeTerm type="text" >Duisburg</mods:placeTerm>
> > </mods:place>
> >
> > Anscheinend wertet der Viewer das aktuell nicht "korrekt" aus, denn
> > daraus entsteht sowas
> >
> > (DX, 1849)
> >
> > Und nicht
> >
> > (Duisburg, 1849)
> >
> > Sprich: die Attribute scheinen nicht beachtet zu werden. Was sagen
> Sie
> > dazu, lieber Herr Meyer?
> >
> > Beste Grüße,
> > Kay Heiligenhaus
Liebe Kolleginnen und Kollegen,
vielleicht hat sich ja schon jemand angemeldet... Ich eröffne mal den Technik-Reigen mit einer Implementierungsfrage. Wir importieren aktuell Daten aus der ZDB. Dabei entstehen im <originInfo>-Block solche Konstrukte:
<mods:place>
<mods:placeTerm type="code" authority="marccountry" >DX</mods:placeTerm>
</mods:place>
<mods:place>
<mods:placeTerm type="text" >Duisburg</mods:placeTerm>
</mods:place>
Anscheinend wertet der Viewer das aktuell nicht "korrekt" aus, denn daraus entsteht sowas
(DX, 1849)
Und nicht
(Duisburg, 1849)
Sprich: die Attribute scheinen nicht beachtet zu werden. Was sagen Sie dazu, lieber Herr Meyer?
Beste Grüße,
Kay Heiligenhaus
Könnten die Beispiele auch an die Liste gegeben werden. Ich würde mir
das gern ansehen.
Viele Gruesse,
th.staecker
Hallo Stefan,
die erste Frage kann ich beantworten: es gibt noch keinen Viewer, der
die "neue" METS-Struktur versteht. Ich arbeite aber dran und melde mich,
sobald eine erste Version in einem Zustand ist, dass damit getestet
werden kann. Ich rechne damit, dass das etwa gegen Ende der nächsten
Woche sein wird.
Kannst du mir deine neuen METS-Dateien aber bitte trotzdem schonmal
zuschicken? Ich sammle im Augenblick so viele Beispiele wie möglich (und
arbeite auch selbst noch am Beispiel für die mehrbändigen Werke, das ich
eigentlich ja schon Anfang der Woche versprochen hatte), um die dann als
grobe Vorgabe für die neue Viewer-Version zu verwenden.
Viele Grüße
Sebastian
--
