29 Nov
2010
29 Nov
'10
8:42 p.m.
Entschuldigung, die Anrede sollte natürlich "Lieber Herr Heiligenhaus" lauten.
Da hatte ich noch einen falschen Text in der Zwischenablage.
--
Sebastian Meyer
Referatsleiter Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek (SLUB)
01054 Dresden
Telefon: +49 351 4677-206<tel:+49%20351%204677-206>
Telefax: +49 351 4677-711<tel:+49%20351%204677-711>
Web: http://www.slub-dresden.de
________________________________
Von: Meyer, Sebastian
Sent: Montag, 29. November 2010 19:59
An: technik(a)dfg-viewer.de
Betreff: Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC
Lieber Herr Mittebach,
Wenn Sie doch ebenfalls nicht glücklich mit der Vereinfachung sind und lieber
<originInfo><place> nutzen würden (was ich auch bevorzugen würde), warum dann
nicht den Versuch wagen, das für MODS 3.5 anzustreben?
Oder benötigen wir dazu so dringend eine Festlegung, dass wir die Vereinfachung in Kauf
nehmen müssen?
Meines Erachtens würden wir mit einer "übereilten" Festlegung langfristig mehr
Probleme bekommen (Stichwort: Abwärtskompatibilität).
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Referatsleiter Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek (SLUB)
01054 Dresden
Telefon: +49 351 4677-206<tel:+49%20351%204677-206>
Telefax: +49 351 4677-711<tel:+49%20351%204677-711>
Web: http://www.slub-dresden.de
________________________________
Von: Kay Heiligenhaus
Sent: Montag, 29. November 2010 17:26
An: dv-technik(a)dfg-viewer.de
Betreff: Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC
Liebe Frau Rühle, lieber Herr Meyer,
ich denke nicht, daß das ein Fehler in der Spezifikation ist. Es ist m.E. schlicht der
Vereinfachung geschuldet, die MODS eben vornimmt. Wenn wir uns damit nicht anfreunden
können, dann sollten wir grundsätzlich die Frage stellen, ob man statt dessen nicht gleich
MARC21 nimmt (sofern das Mapping der DNB irgendwann final ist) oder auf RDA wartet (sofern
das irgendwann Akzeptanz finden sollte)... Hier deshalb nochmal die Definition zu
<mods:hierarchicalGeographic>:
"Definition: a geographic name given in a hierarchical form relating to the
resource.
Application: 'hierarchicalGeographic' includes a hierarchical form of place name
which is both readable by humans and parsable by machines. This form can be applied to the
degree of specificity that is known or relevant and used to generate browsable hierarchies
even when values are specified to different levels. Explicit inclusion of the complete
hierarchy is of potential benefit for automated consultation of a gazetteer to derive map
coordinates or to support a map-based interface for searching by country or state. It is
equivalent to MARC 21 field 752." [1]
Es ist hier m.E. bewußt offengelassen, in welcher Relation der "geographische
Name" zur bibliographischen Einheit steht und wir tun uns m.E. keinen Gefallen, wenn
wir das nun einfach ignorieren, via <mods:extension> MARC21-Felder
"nachbauen" und mit bestehenden Mappings brechen (wenn die Verbünde irgendwann
auf MARC21 umgestiegen sein sollten, werden diese für uns viel wichtiger als aktuell).
Ich bin auch nicht wirklich glücklich mit dieser Vereinfachung (die Information gehörte
eigentlich in mods:originInfo/mods:place) und wir hatten das ja bereits hier ausführlich
diskutiert. Leider sieht das MODS v3.4 aber nicht vor. Warum auch immer.
BTW: Unterscheiden ließen sich die Verwendung jedoch durchaus. Man müßte "nur"
dafür sorgen, daß man klare Bezüge zu Normdatenquellen hätte (also z.B. RSWK, CERL usw.).
Beste Grüße,
Kay Heiligenhaus
[1]
http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#hierarchi…
-----Original Message-----
From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-
bounces(a)dfg-viewer.de] On Behalf Of Meyer, Sebastian
Sent: Monday, November 29, 2010 5:08 PM
To: technik(a)dfg-viewer.de
Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC
Liebe Frau Rühle, lieber Herr Heiligenhaus,
das ist tatsächlich eine kniffelige Frage. Ich kann beide Standpunkte gut
verstehen, würde aber auch eher zu Frau Rühles Lösungsvorschlag
tendieren. Nicht weil ich ihn gut finde, sondern weil er meines Erachtens das
kleinere Übel darstellt. Im Zweifel sind mir aber semantisch saubere
Metadaten wichtiger als der Verzicht auf MODS-Erweiterungen über
<mods:extent>.
Für mich stellt sich die Frage, wie denn die ideale Lösung aussähe? Wo und
wie würden Sie die Angaben denn am liebsten kodieren, wenn MODS es
erlauben würde? Vielleicht sollten wir besser eine entsprechende
Erweiterung von MODS anstreben und uns bis dahin gar nicht zu
hierarchischen Druck- und Verlagsorten äußern, als jetzt einen Kompromiss
zu schließen, der niemanden glücklich macht.
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Referatsleiter Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Telefon: +49 351 4677-206
Telefax: +49 351 4677-711
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 Ruehle, Stefanie
Gesendet: Montag, 29. November 2010 16:25
An: dv-technik(a)dfg-viewer.de
Betreff: Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC
Hallo Herr Heiligenhaus,
Name"
<mods:extent> sollte man m.E. nicht zu
schnell bei der Hand haben.
Die Herleitung für ein Mapping auf <mods:hierarchicalGeographic>
habe ich im o.g. ersten Posting gegeben. Es leitet sich ab von
MARC21-
Feld 752, das eben genau so definiert ist:
"Added entry in which the
entry element is a hierarchical form of place name that is related
to
a
particular attribute of the described item, e.g.,
the place of
publication
for a rare book." [1] Nach
LoC-MARC21-MODS-Mapping wird es auf
<mods: hierarchicalGeographic> gemapped.
ja, und das geschieht nicht nur in dem Mapping, sondern in der
"Detailed Description of MODS Elements" wird auch und nur auf 752
verwiesen.
(see:
http://www.loc.gov/standards/mods/v3/mods-userguide-
elements.html#hierarchica
lgeographic)
M. E. ist das ein grober Fehler in der MODS-Dokumentation. Schauen Sie
sich das Mapping an, so stellen Sie fest, das auch 662 auf
<mods:subject><mods:hierarchicalGeographic> gemappt wird. Und damit
wird aus dem Fehler ein echtes Problem. Im Grunde genommen haben wir
jetzt den folgenden Sachverhalt:
<mods:hierarchicalGeographic> wird definiert als: "a geographic name
given in a hierarchical form relating to the resource"
das klingt ja noch ganz gut und würde auch auf alles passen. Aber
dieses Element ist nun einmal ein Subelement zu <mods:subject>, heißt,
was für <mods:subject> gilt, gilt auch für
<mods:hierarchicalGeographic> Und <mods:subject> ist definiert als:" A
term or phrase representing the primary
topic(s) on which a work is focused."
Demnach kann <mods:hierarchicalGeographic> eigentlich nur dann
verwendet werden, wenn es sich um geographische Angaben handelt, die
den topic, also das Thema der Ressource beschreiben.
Das Mapping auf MARC21-Feld 662 - "Subject Added Entry-Hierarchical
Place Name" macht in dieser Hinsicht darum m. E. auch absolut Sinn,
denn 662 wird definiert als: "Hierarchical form of a geographic name
used as a subject added entry."
Das Mapping auf MARC21-Feld 752 - "Added Entry-Hierarchical Place macht
m. E. hingegen wenig Sinn. Wie Sie ja schon festgestellt haben, lautet
die
Definition: "Added entry in which the entry element is a hierarchical
form of place name that is related to a particular attribute of the
described item, e.g., the place of publication for a rare book."
Ärgerlich ist an der Sache aber vor allem, dass in dem Moment, wo
sowohl 662 als auch 752 in <mods:subject><mods:hierarchicalGeographic>
verwendet werden, überhaupt nicht mehr zu unterscheiden ist, ob es
sich nun um den
Verlags-
bzw. Druckort handelt - also die Frage, an welchem Ort ist das Werk
entstanden -, oder um den Topic - also die Fragen nach dem Ort der
Handlung des Werks, Thema des Werks usw. Das sind ja doch zwei
grundsätzlich unterschiedliche Fragestellungen. Diese in einem Feld
zusammenzuschmeißen finde ich für die Nachnutzbarkeit der Daten
einfach fatal, denn
* in Suche, Browsing und Anzeige der Treffen kann der Nutzer nun nicht
zwischen Druck- und Verlagsorten einerseits und Thema des Werks
andererseits unterschieden,
* bei der Konversion der Daten in ein ggf. anderes Format lassen sich
die Daten nicht mehr vernünftig mappen.
Angesichts der Tatsache, dass wir das Profil ja nicht für eine
einzelne Anwendung verwenden und es auch für zukünftige
Anwendungen
möglichst flexibel sein muss, müssen wir diese
beiden Fragestellungen
auf jeden Fall auseinanderhalten. Und da 622 nun einmal semantisch dem
entspricht, was <mods:subject><mods:hierarchicalGeographic> eigentlich
sein soll, würde ich dafür plädieren, für den Sachverhalt von 752 eine
Lösung in <mods:extent> zu suchen.
Wie stehen die anderen dazu?
fragt sich
Stefanie Rühle
------------------------------------------
Stefanie Rühle
Niedersächsische Staats- und Universitätsbibliothek (SUB) Göttingen
Goettingen State and University Library Metadaten und Datenkonversion
Papendiek 14
37073 Göttingen
Tel.: +49(0)551/39-10905
E-Mail: sruehle(a)sub.uni-goettingen.de
Internet: http://www.sub.uni-goettingen.de
-----Original Message-----
From: dv-technik-bounces(a)dfg-viewer.de on behalf of Kay Heiligenhaus
Sent: Mon 29.11.2010 12:42
To: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de
Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC
Liebe Frau Rühle,
vielen Dank für Ihre schnelle Rückmeldung! Kurz zu einigen Punkten:
das
Beispiel
haben?
Die Frage ist hier m.E., wie man "Pärchen" von Erscheinungsorten und
Verlagen gruppiert. Besonders interessant wird es, wenn wir z.B.
Verlage mit zwei Erscheinungsorten haben in Kombination mit einem
Verlag mit einem Erscheinungsort, also das Muster (EOXVY für
Erscheinungsort X des Verlages
Y):
EO1V1, EO2V1 : V1 ; EOV2 : V2 ; EO1V3, EO2V3 : V3
nicht
Elementes
Hier die beiden Einsprungpunkte dazu:
https://maillist.slub-dresden.de/pipermail/dv-technik/Week-of-Mon-
20100607/00
0489.html
https://maillist.slub-dresden.de/pipermail/dv-technik/Week-of-Mon-
20100607/00
0492.html
> Ich habe den Vorschlag,
> <mods:subject><mods:hierarchicalGeographic> zu verwenden noch
einmal
> 4) Die Ausführungen (S. 5ff.) zu Titeln sind
m.E. nicht kompatibel
mit
> MAB2. Teile mehrbändiger Werke haben häufig
keine eigenen Titel,
> sofern sie eben keine Stücktitel sind. Ein Beispiel finden Sie
unter
> [2]. Ein MAB2-Mapping würde hieran scheitern
rsp. das Mapping
> erheblich erschweren.
> Zudem berücksichtigt der Viewer diese Konstrukte hinreichend,
sofern
man die
Daten so liefert, wie es das Beispiel [3] zeigt.
Ich verstehe Ihre Anmerkung nicht ganz. Geht es um die Aussage, dass Wurzelelement einen <titleInfo> haben muss?
Dann haben Sie
wahrscheinlich
recht: Bei mehrbändigen Werken ohne eigenen Stücktitel wird der
Titel bereits im Subelement <titleInfo> in <relatedItem
type="host">
gespeichert,
es braucht also kein Element <titleInfo>.
Geht es darum? Dann würde
ich das
ändern.
Ja, darum ging es mir.
> 7) Bei <mods:originInfo> (S. 11ff)
sollte man m.E. Beispiele für
die
Verwendung mehrere Erscheinungsorte und Verlage geben.
Ich kann entsprechende Beispiele nachtragen.
Hier spielt m.E. die Reihenfolge durchaus eine
Rolle!
Mir ist nicht ganz klar, in welcher Form. Könnte ich dazu ein 8) Das
Beispiel zur Verwendung von @keydate (S. 15) halte ich
nicht für plausibel.
Ich werde die Beispiele überarbeiten, müsste aber wissen, was genau plausibel ist?
Für die Angabe von
<mods:dateCreated encoding="w3cdtf" qualifier="approximate"
point="start">1630</mods:dateCreated>
<mods:dateCreated encoding="w3cdtf" qualifier="approximate"
point="end">1633</mods:dateCreated>
sehe ich noch keinen rechten Sinn bei Druckschriften. Welchen
"Spezialfall"
haben Sie denn hier im Auge? Besser fände ich es, wenn zunächst ein
"einfaches Standardbeispiel" aufgeführt würde und dann verschiedene
Varianten von mods:dateIssued/@qualifier anstatt
mods:dateCreated/@qualifier.
10) Bei
<mods:subject> (S. 20ff.) fehlt mir ein Hinweis auf dessen
Verwendung im Rahmen der Codierung von normierten Druck-
/Verlagsorten.
> Wir hatten das in Göttingen, Berlin und auch hier auf der Liste
> intensiv diskutiert. Vorgesehen dafür ist die Verwendung des
<mods:hierarchicalGeographic> [5].
Sorry, die Diskussion habe ich nicht mitbekommen:-( geprüft
und muss gestehen, dass das m. E. gar nicht geht. Die
Definition zu
<mods:subject> lautet: "A term or
phrase representing the primary
topic(s)
on which a work is focused." Es wäre ein
eklatanter Verstoß gegen
die Regeln semantischer Konformität, dies für die Druck- und
Verlagsorte
zu
nutzen. Aber warum nehmen wir nicht
<mods:extent>? Das scheint mir
genau für einen solchen Fall gedacht: "used to provide for
additional information not covered by MODS." Was wir brauchen könnte
folgendermaßen oder ähnlich aussehen:
<mods:extension>
<xxx:wrap>
<xxx:hierarchicalPlaceOfPublication>
<xxx:country>Deutschland</mods:country>
<xxx:state>Sachsen</mods:state>
<xxx:city>Leipzig</mods:city>
</xxx:hierarchicalPlaceOfPublication>
</xxx:wrap>
</mods:extension>
<mods:extent> sollte man m.E. nicht zu schnell bei der Hand haben. Die
Herleitung für ein Mapping auf <mods:hierarchicalGeographic> habe ich
im o.g.
ersten Posting gegeben. Es leitet sich ab von MARC21-Feld 752, das
eben genau so definiert ist: "Added entry in which the entry element
is a hierarchical form of place name that is related to a particular
attribute of the described item, e.g., the place of publication for a
rare book." [1] Nach LoC-MARC21-MODS-Mapping wird es auf <mods:
hierarchicalGeographic> gemapped.
> Denn darauf beziehen wir uns, wenn wir hier
z.B. VD-Nummern
eintragen.
Das Problem ist mir auch schon bei der Bearbeitung des PICA+
Mappings begegnet und ich muss gestehen, dass ich mich mit der Natur
der VD- Nummer nicht auskenne und nicht weiß, ob es sich dabei um
einen
Objekt-
Identifier handelt, wiederzugeben in
<mods:identifier> oder den
Identifier
der Metadaten, wiederzugeben in
<mods:recordInfo><mods:recordIdentifier>. Kann mir da jemand
weiterhelfen.
"manifestations".
Wie
sieht
Hinter eine VD-Nummer können sich aber x
"Ressourcen"
(= Sekundärformen) verbergen.
Das ist bei einer ISBN auch so. Diese steht für alle das bei den VD-Nummern aus?
Nach meinem Verständnis ist eine VD-Nummer durchaus vergleichbar mit
einer ISBN.
Beste Grüße,
Kay Heiligenhaus
5450
days inactive
5450
days old
0 comments
1 participants
participants (1)
-
Meyer, Sebastian