29 Nov
2010
29 Nov
'10
12:42 p.m.
Liebe Frau Rühle,
vielen Dank für Ihre schnelle Rückmeldung! Kurz zu einigen Punkten:
Ja, darum ging es mir.
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
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.
Hier die beiden Einsprungpunkte dazu:
https://maillist.slub-dresden.de/pipermail/dv-technik/Week-of-Mon-20100607/…
https://maillist.slub-dresden.de/pipermail/dv-technik/Week-of-Mon-20100607/…
Nach meinem Verständnis ist eine VD-Nummer durchaus vergleichbar mit einer ISBN.
Beste Grüße,
Kay Heiligenhaus
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 das
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. 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 Beispiel haben? 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 nicht
plausibel ist? 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 Elementes
<mods:hierarchicalGeographic> [5].
Sorry, die Diskussion habe ich nicht mitbekommen:-( Ich habe den Vorschlag,
<mods:subject><mods:hierarchicalGeographic> zu verwenden noch einmal
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.
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 "manifestations". Wie
sieht
das bei den VD-Nummern aus? 
29 Nov
29 Nov
4:25 p.m.
New subject: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC
Hallo Herr Heiligenhaus,
Ja, darum ging es mir.
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
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.
Hier die beiden Einsprungpunkte dazu:
https://maillist.slub-dresden.de/pipermail/dv-technik/Week-of-Mon-20100607/…
0489.html
https://maillist.slub-dresden.de/pipermail/dv-technik/Week-of-Mon-20100607/…
0492.html
sieht
<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#hierarchi…
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 Name" 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:
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 das
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. 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 Beispiel 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 nicht
plausibel ist? 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 Elementes
<mods:hierarchicalGeographic> [5].
Sorry, die Diskussion habe ich nicht mitbekommen:-( Ich habe den Vorschlag,
<mods:subject><mods:hierarchicalGeographic> zu verwenden noch einmal
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.
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 "manifestations". Wie
das bei den VD-Nummern aus?
Nach meinem Verständnis ist eine VD-Nummer durchaus vergleichbar mit einer
ISBN.
Beste Grüße,
Kay Heiligenhaus
5:08 p.m.
New subject: [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,
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
<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 Name"
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:
> 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:-( Ich habe den Vorschlag,
<mods:subject><mods:hierarchicalGeographic> zu verwenden noch einmal
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
5160
days inactive
5160
days old
2 comments
3 participants
participants (3)
-
Kay Heiligenhaus -
Meyer, Sebastian -
Ruehle, Stefanie