DV-Technik

dv-technik@dfg-viewer.de

329 discussions

Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC

by Kay Heiligenhaus

Lieber Herr Meyer, > 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? Weil es keinen Weg dahin von unseren aktuellen Katalogdaten aus gibt. Weder in MAB2 (Feld 673a), noch in PICA+ (Feld 033B/03) noch in MARC21 (Feld 752) werden die Informationen in dieser Form aufeinander bezogen (Ort := normalisierter Ort). Diese stehen "isolitert" als Suchhilfen zur Verfügung, mehr nicht. Deshalb ist die "unspezifische Form" über <mods:subject> den Katalogisierungsgegebenheiten durchaus angemessen. > 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). Ja. Aber das zugrundeliegende Problem ist dann m.E. eben zu "altbestandsspezifisch", als daß man darauf hoffen könnte, hier auf Ebene der Formate zu einer besseren Lösung zu kommen, als wir sie aktuell haben. Selbst wenn es in MODS v3.5 eine adäquate Lösung gäbe, gäbe es keinen Weg von unseren aktuellen Daten dorthin... Beste Grüße, Kay Heiligenhaus

14 years, 1 month

Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC

by Meyer, Sebastian

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, > > > > > <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 > > 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. > > > > 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 > > 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 > > > > > > 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? > > > > 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 > > Elementes > > > > <mods:hierarchicalGeographic> [5]. > > > > > > Sorry, die Diskussion habe ich nicht mitbekommen:-( > > > > 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 > > > 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? > > > > Nach meinem Verständnis ist eine VD-Nummer durchaus vergleichbar mit > > einer ISBN. > > > > Beste Grüße, > > Kay Heiligenhaus > > > > > > > > > > > > >

14 years, 1 month

Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC

by Meyer, Sebastian

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, > > > > > <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 > > 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. > > > > 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 > > 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 > > > > > > 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? > > > > 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 > > Elementes > > > > <mods:hierarchicalGeographic> [5]. > > > > > > Sorry, die Diskussion habe ich nicht mitbekommen:-( > > > > 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 > > > 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? > > > > Nach meinem Verständnis ist eine VD-Nummer durchaus vergleichbar mit > > einer ISBN. > > > > Beste Grüße, > > Kay Heiligenhaus > > > > > > > > > > > > >

14 years, 1 month

Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC

by Kay Heiligenhaus

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, > > > > > <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 > > 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. > > > > 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 > > 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 > > > > > > 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? > > > > 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 > > Elementes > > > > <mods:hierarchicalGeographic> [5]. > > > > > > Sorry, die Diskussion habe ich nicht mitbekommen:-( > > > > 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 > > > 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? > > > > Nach meinem Verständnis ist eine VD-Nummer durchaus vergleichbar mit > > einer ISBN. > > > > Beste Grüße, > > Kay Heiligenhaus > > > > > > > > > > > > >

14 years, 1 month

Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC

by Kay Heiligenhaus

Liebe Frau Rühle, lieber Herr Meyer, ich habe mir das heute nochmal näher angeschaut. Ich hatte wohl in der Tat den Vorschlag falsch verstanden, was aber nichts daran ändert, daß ich diesem nicht folgen mag, da das <relatedItem type="original"> einfach anders verwendet wird in MODS als wir es hier unterstellen müßten. Allen Verwendungen von <relatedItem> dienen nach meinem Verständnis dazu, Beziehungen zu anderen Datensätzen (!) auszudrücken. Schaut man sich hierzu das LoC-MARC21-MODS-Mapping genauer an, dann sieht man, wie das Element zu verwenden ist. [1] Es leitet sich im Kern von den MARC21-Feldern 760-787 und 800-830 ab. Uns braucht hier nur die erste Feldsequenz zu interessieren [2] und hier dann speziell [3]. Schaut man nun ins Mapping, dann sieht man, daß die Mapping-Regeln nicht zu der Modellierung führen, die Frau Rühle vorschlägt. MARC21 Feld 786 (die MARC21-Grundlage von <relatedItem type="original">) ist einfach nicht dazu gedacht, Angaben zur Primärform in der hier vorgeschlagenen Weise zu transportieren, es dient vielmehr dazu, eine Beziehung zwischen Primär- und Sekundärform herzustellen! Wenn wir an dieser Stelle Änderungen vornehmen wollen, dann hilft uns m.E. ein Blick in die EROMM-"Empfehlungen zur Erfassung von layoutgetreuen Digitalisaten (digitale Master)" eher weiter. [4] Hier sieht man, daß nicht die Angaben zum Erscheinungsvermerk der Vorlage anders kodiert werden müßten, sondern die Angaben zur Onlineausgabe. Hierzu dient in MARC21 Feld 533. (Eine solche Abbildung wäre auch kompatibel mit den Mapping-Regeln der zugrundeliegenden MAB-Felder 610ff., wie sie in [6] beschrieben sind.) Ist MARC21-Feld 533 noch hinreichend differenziert, um die Angaben, die wir hier brauchen, zu transportieren, wird nach Anwendung des LoC-Mappings jedoch in etwa folgendes MODS daraus: <note type="reproduction">[Online-Ausg.] Göttingen : Niedersächsische Staats- und Universitätsbibliothek, 2010</note> Wir hätten also die differenzierte aktuelle Codierungsform durch eine "getypte Anmerkung" ersetzt. Ob ich das dann unterstützen würde, weiß ich noch nicht so genau. ;) Beste Grüße, Kay Heiligenhaus [1] http://www.loc.gov/standards/mods/mods-mapping.html#relateditem [2] http://www.loc.gov/marc/bibliographic/bd76x78x.html [3] http://www.loc.gov/marc/bibliographic/bd786.html [4] http://www.eromm.org/_media/public/de/digitalemaster.pdf?id=public%3Ade%3Ac… [5] http://www.loc.gov/marc/bibliographic/bd533.html [6] http://www.d-nb.de/standardisierung/pdf/konkordanz_1.pdf > -----Original Message----- > From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- > bounces(a)dfg-viewer.de] On Behalf Of Kay Heiligenhaus > Sent: Thursday, November 25, 2010 9:07 PM > To: dv-technik(a)dfg-viewer.de; Meyer, Sebastian; technik(a)dfg-viewer.de > Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC > > Lieber Herr Meyer, > > ich fühle mich an Diskussionen bei unseren Sitzungen in Halle vor zwei Jahren > erinnert. Da hatten wir das Thema auch schon auf der Pfanne... ;) > > > Die aktuelle Lösung ist meines Erachtens eben nicht immer eindeutig, > > da es für die Angaben zur Vorlage nur ein Negativ-Kriterium (*kein* > > <edition>[Electronic ed.]</edition>), aber kein Positiv-Kriterium > > gibt. Worauf bezieht sich also ein <originInfo>-Abschnitt, wenn es > > keinen Abschnitt mit diesem Kriterium gibt? Handelt er dann von der > > Vorlage oder folgt die METS- Datei schlicht nicht unserem Profil? > > Dann sollten wir m.E. eher dafür streiten, daß das <mods:originInfo>- > Element um ein @type-Attribut erweitert wird. Unterm Strich würde ich aber > sagen: Wenn ein solcher Block nicht vorhanden ist, dann hat das > zugrundeliegende digitalisierte Werk offensichtlich weder einen Umfang > noch einen Erscheinungs-/Entstehungsort noch einen Erscheinungs- > /Entstehungszeitpunkt. Und es existieren auch offensichtlich keinerlei > Vermutungen darüber (was mich zumindest beim Umfang verwundern > würde). Also eigentlich müßte man dann sagen: Es existiert folglich gar nicht > und der Viewer muß es folglich auch nicht anzeigen. ;) > > > Mit der Lösung über <relatedItem> hätten wir dieses Problem nicht. Und > > ich verstehe METS hier so, dass kein vollständiger bibliographischer > > Datensatz in <relatedItem> stehen muss. (So handhaben wir das ja auch > > bei <relatedItem type="host"> und <relatedItem type="series">.) > > Stimmt. Das sagt der Entwurf aber so nicht. Und wenn er es sagen würde, > würde ich einwenden: Und deshalb invalidieren wir alle bislang erstellten > MODS-Daten? > > > Ihrem Vorschlag eines <dv:version>-Elements schließe ich mich an. > > Prima. Dann sollten wir nochmal überlegen, was noch auf unserer Agenda > stand. Ich erinnere mich z.B. an die Forderung aus den DFG-Gremien, daß > man das DFG-Logo gezielt überschreiben können sollte, um eine Nutzung > auch außerhalb von DFG-Förderungen zu erleichtern... > > Beste Grüße, > Kay Heiligenhaus

14 years, 1 month

Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC

by Kay Heiligenhaus

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. 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 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 > > 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? 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 Elementes > > <mods:hierarchicalGeographic> [5]. > > Sorry, die Diskussion habe ich nicht mitbekommen:-( 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/… > 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? Nach meinem Verständnis ist eine VD-Nummer durchaus vergleichbar mit einer ISBN. Beste Grüße, Kay Heiligenhaus

14 years, 1 month

Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC

by Kay Heiligenhaus

Liebe Frau Rühle, vielen Dank für Ihre ausführliche Erläuterung! Jetzt verstehe ich Ihren Angang besser und bin gespannt auf weitere evtl. Wortmeldungen dazu. Was ich jedoch nochmal grundsätzlich betonen möchte: 1) Ich würde für die aktuelle Überarbeitung des Profils aktuelle Mappings zwischen PICA+, MAB2, MARC21 und MODS zugrundelegen. Reflexionen über Modellierungsprinzipien, die in RDA Anwendung finden, helfen uns m.E. da aktuell nicht weiter, da diese (noch) keine (katalogisierungs- und austausch-)praktische Grundlage haben (können). 2) Schaut man sich die aktuelle Katalogisierungspraxis in den PICA- und MAB2-Verbünden sowie die vorliegenden Mappings beider Formate nach MARC21 an, dann kommt man (evtl. leider) nicht zu der von Ihnen vorgeschlagenen MODS-Modellierung. Ausgangspunkt unserer Überlegungen kann dann (evtl. leider) nur MARC21-Feld 533 sein, dahin wird nämlich aktuell bei der Beschreibung von Online-Ressourcen in konkret vorliegenden Datensätzen aus PICA+- und MAB2 gemapped (s. hierzu z.B. [1]). 3) Da das so ist, sollten wir m.E. keine "Mapping-Sonderwege" einschlagen. Unsere Ausgangsdaten sind halt zum aktuellen Zeitpunkt und auch absehbar die Titeldaten, wie sie in unseren Katalogen vorliegen. Heißt für mich unterm Strich: Entweder, wie bleiben schlicht bei den Vorgaben des APs in Vers. 1.0 oder wir ändern das in der Art, die ich bereits beschrieben hatten: MARC21-Feld 533 -> mods:note/@type="reproduction". Ich würde auf keinen Fall "zweigleisig" fahren wollen im MODS-AP 2.1! Wenn wir ändern, dann sollten wir das m.E. konsequent tun. BTW: "Interessant" an dieser Modellierung über MARC21-Feld 533 ist übrigens, daß diese im Kern dem Ansatz der beiden Nationalbibliographien VD16 und VD17 entspricht. Wie sie z.B. unter [2] sehen, wird hier der "Erscheinungsvermerk der Onlineausgabe" (und noch weitere Angaben zum digitalisierten Exemplar) rein verbal beschrieben, folgt jedoch einer eindeutigen Syntax-/Interpunktionsvorgabe: Volltext // 2008 digitalisiert von: Bayerische Staatsbibliothek, München. Exemplar der Bayerischen Staatsbibliothek mit der Signatur: Res/4 Opp. 90,III,3-- In MAB2XML sieht das so aus: <feld nr="655" ind="e"> <uf code="u">http://nbn-resolving.de/urn/resolver.pl?urn=urn:nbn:de:bvb:12-bsb00025633-2</uf> <uf code="x">Resolving-System</uf> <uf code="z">kostenfrei</uf> <uf code="3">Volltext // 2008 digitalisiert von: Bayerische Staatsbibliothek, München. Exemplar der Bayerischen Staatsbibliothek mit der Signatur: Res/4 Opp. 90,III,3--</uf> </feld> MAB2-Feld 655e$3 würde allerdings auf MARC21-Feld 856$3 gemapped. Und dieses lt. LoC-MARC21-MODS-Mapping: zu nichts. ;) Beste Grüße, Kay Heiligenhaus [1] Ein beliebiges Katalogisat aus dem BSZ zu einer Onlineausgabe aus Dresden: http://swb.bsz-bw.de/DB=2.1/PPNSET?PPN=331522233. Wenn man sich das Mapping zu MARC21 anschaut, sieht man, daß dort alle Angaben zum Erscheinungsvermerk auf MARC21-Feld 533 gemapped werden. Datensätze aus anderen Verbünden kann man sich noch nicht so praktisch anschauen, das Ergebnis ist jedoch analog und folgt damit eben den Mappings MAB2-MARC21 der DNB. [2] http://gateway-bayern.bib-bvb.de/aleph-cgi/bvb_suche?sid=VD16&find_code_1=W… > -----Original Message----- > From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- > bounces(a)dfg-viewer.de] On Behalf Of Ruehle, Stefanie > Sent: Sunday, November 28, 2010 6:02 PM > To: dv-technik(a)dfg-viewer.de; Meyer, Sebastian > Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC > > Lieber Herr Heiligenhaus, > > > ich habe mir das heute nochmal näher angeschaut. Ich hatte wohl in der > > Tat den Vorschlag falsch verstanden, was aber nichts daran ändert, daß > > ich diesem nicht folgen mag, da das <relatedItem type="original"> > > einfach anders verwendet wird in MODS als wir es hier unterstellen > > müßten. > > > Allen Verwendungen von <relatedItem> dienen nach meinem Verständnis > > dazu, Beziehungen zu anderen Datensätzen (!) auszudrücken. > > Die Beschreibug in MODS lautet: > > "<relatedItem> is a container element under which any MODS element may > be used as a subelement." > Also nicht nur und nicht unbedingt Identifier, die Datensätze miteinander > verlinken. Und auch die Beispiele in der MODS-Dokumentation sehen nicht > so aus, als sollten hier nur Beziehungen zwischen Datensätzen hergestellt > werden. > > s. http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html > > > Schaut man sich hierzu das LoC-MARC21-MODS-Mapping genauer an, dann > > sieht man, wie das Element zu verwenden ist. > > [1] Es leitet sich im Kern von den MARC21-Feldern 760-787 und 800-830 > > ab. > > Uns braucht hier nur die erste Feldsequenz zu interessieren [2] und > > hier dann speziell [3]. Schaut man nun ins Mapping, dann sieht man, > > daß die Mapping-Regeln nicht zu der Modellierung führen, die Frau > > Rühle vorschlägt. > > MARC21 Feld 786 (die MARC21-Grundlage von <relatedItem > > type="original">) ist einfach nicht dazu gedacht, Angaben zur > > Primärform in der hier vorgeschlagenen Weise zu transportieren, es > > dient vielmehr dazu, eine Beziehung zwischen Primär- und Sekundärform > > herzustellen! > > Ich gebe zu, mein Ausgangspunkt war nicht Feld 786 und auch nicht Feld 533, > sondern Feld 534 > > s. http://www.loc.gov/marc/bibliographic/bd534.html > > In den Mappings wird <mods:relatedItem type="original"> > > sowohl in dem MARC21 zu MODS Mapping > s. http://www.loc.gov/standards/mods/mods-mapping.html#relateditem > > als auch in dem MODS zu MARC21 Mapping > > s. http://www.loc.gov/standards/mods//v3/mods2marc- > mapping.html#relateditem > > der Kategorie 534 zugewiesen (wobei 534 allerdings auch auf <mods:note > type="original version"> gemappt werden kann). > > > Wenn wir an dieser Stelle Änderungen vornehmen wollen, dann hilft uns > > m.E. ein Blick in die EROMM-"Empfehlungen zur Erfassung von > > layoutgetreuen Digitalisaten (digitale Master)" > > eher weiter. [4] Hier sieht man, daß nicht die Angaben zum > > Erscheinungsvermerk der Vorlage anders kodiert werden müßten, sondern > > die Angaben zur Onlineausgabe. > > Hierzu dient in MARC21 Feld 533. (Eine solche Abbildung wäre auch > > kompatibel mit den Mapping-Regeln der zugrundeliegenden MAB-Felder > > 610ff., wie sie in [6] beschrieben sind.) > > Was als Beziehung kodiert wird, ist m. E. immer davon abhängig, was ich mit > meinem MODS-Datensatz beschreibe: > > - Beschreibe ich das Digitalisat, kodiere ich die Informationen zum Original als > Beziehung (also Feld 534). > - Beschreibe ich hingegen das Original, dann kodiere ich die Informationen > zum Digitalisat als Beziehung (in Feld 533). > > Im Moment bin ich davon ausgegangen, dass wir das Digitalisat beschreiben. > Das ergibt sich aus: <mods:physicalDescription><mods:digitalOrigin> ;-) > > Ich kann mich aber auch mit der anderen Richtung anfreunden - wir > beschreiben das Original und verweisen über eine Beziehung zum Digitalisat. > > > Ist MARC21-Feld 533 noch hinreichend differenziert, um die Angaben, > > die wir hier brauchen, zu transportieren, wird nach Anwendung des > > LoC-Mappings jedoch in etwa folgendes MODS daraus: > > <note type="reproduction">[Online-Ausg.] Göttingen : Niedersächsische > > Staats- und Universitätsbibliothek, 2010</note> > > Wie Sie schon dargestellt haben, lässt sich Feld 533 leider nicht auf > <mods:relatedItem> mappen, sondern nur auf <mods:note > type="reproduction">. > Und dass lässt sich nicht in der gewünschten Form gliedern:-( > > Darum der Vorschlag mit <mods:relatedItem type="original". Die Vorteile, > die sich daraus ergeben: > > * es ist sauberes MODS > * es entspricht dem one-to-one principle > > Ich kann die Bedenken, die Sie vorbringen allerdings gut verstehen und sehe > ebenfalls die Nachteile: > > Ein Nachteil liegt darin, dass sich diese Lösung wie auch jede andere bisher > nicht wirklich durchgesetzt hat. Es gibt von Jen Riley u.a. einen Aufsatz, der > sich auch mit dieser Frage beschäftigt und die verschiedenen Möglichkeiten > auflistet (s. http://tinyurl.com/322j27x ab S. 15). Ich habe mit Jen und Steve > Miller auf der letzten Dublin Core Tagung im Oktober über das Problem > gesprochen. Von ihnen kommt übrigens auch der Vorschlag mit > <mods:relatedItem type="original">. Jen und Steve sehen das Problem > allerdings nicht in den Metadaten, sondern in den Erfassungsystemen > begründet, die häufig nicht in der Lage sind, strukturierte Daten zu erfassen. > Entsprechend haben sie mir empfohlen, einfach das Original zu beschreiben > und auf die originInfo-Angaben zum Digitalisat zu verzichten. Die meisten > Datenlieferanten in zvdd machen es übrigens genau so:-( > > Ein anderer Nachteil ist der von Herrn Heiligenhaus in einer früheren Mail > angesprochene Umgang mit bereits vorhandenen Daten. Eine Konvertierung > wäre natürlich einfach, wenn wir davon ausgehen, dass alle originInfos, die > kein [Electronic. ed.] haben, automatisch die Daten der Originale sind. Aber > davon können wir wohl nur träumen;-) > > >> Dann sollten wir m.E. eher dafür streiten, daß das > >><mods:originInfo>-Element um ein @type-Attribut erweitert wird. > > Wollen wir das den MODS-Editoren wirklich vorschlagen? > > >> daß wir die bibliographischen Informationen dazu _ vollständig_ im > >><mods:relatedItem> wiederholen müssen. > > Sorry, ich habe mich im Anwendugsprofil offensichtlich sehr > un(miss)verständlich ausgedrückt. Egal, für welche Lösung wir uns > entscheiden, ich werde den Text natürlich überarbeiten. Auf jeden Fall gilt: > <mods:relatedItem type="original" soll tatsächlich nur die Subelemente > <mods:originInfo> und <mods:location> enthalten. > > >> Und deshalb invalidieren wir alle bislang erstellten MODS-Daten? > > Um diesem Problem aus dem Weg zu gehen, erlaube ich im Moment ja > beides: > sowohl die Lösung mit <mods:relatedItem type="original> als auch die > Lösung ohne. Beide Lösungen zu mappen ist einfach, wenn wir davon > ausgehen, dass alle originInfo-Angaben zum Digitalisat mit [Electronic ed.] > ausgezeichnet werden - so im AP gefordert - aber auch das klappt selbst in > zvdd nicht immer > - geschweige denn darüber hinaus. > > Im Moment haben wir m. E. drei Möglichkeiten: > > 1. Wir lassen es so wie im alten AP vorgeschlagen: > * originInfo-Angaben des Originals in einem separaten <mods:originInfo>, > das nicht gekennzeichnet ist. > * originInfo-Angaben des Digitalisats in einem separaten <mods:originInfo>, > das mit [Electronic ed.] gekennzeichnet ist. > In diesem Fall sollten wir aber auf jeden Fall > <mods:physicalDescription><mods:digitalOrigin> nicht mehr verwenden. > Denn in diesem Fall beschreiben wir nicht das Digitalisat, sondern das > Original. > > 2. Wir empfehlen die Verwendung von <mods:relatedItem type="original">, > bedeutet: > * originInfo-Angaben des Originals als Subelement in <mods:relatedItem > type="original"> > * originInfo-Angaben des Digitalisats in <mods:originInfo> mit der > Kennzeichnung [Electronic ed.] In diesem Fall muss > <mods:physicalDescription><mods:digitalOrigin> vergeben werden, um > deutlich zu machen, dass hier das Digitalisat beschrieben wird. > > 3. Wir nehmen die Lösung aus dem alten AP, weisen aber darauf hin, dass es > "eleganter" wäre, <mods:relatedItem type="original"> zu verwenden. Und > zeigen, wie ein Mapping von dem einen zum anderen aussehen kann. Dann > können wir in einigen Jahren noch mal schauen, was sich durchgesetzt hat;-) > <mods:physicalDescription><mods:digitalOrigin> würde ich in diesem Fall auf > conditional setzen. > > Wenn wir uns nicht auf 2. einigen können, würde ich natürlich 3. bevorzugen > - mit dem Nachteil, dass wir über die nächsten Jahre "zweigleisig" fahren. > > Viele Grüße > > 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: Sat 27.11.2010 21:29 > To: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de; Meyer, > Sebastian > Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC > > Liebe Frau Rühle, lieber Herr Meyer, > > ich habe mir das heute nochmal näher angeschaut. Ich hatte wohl in der Tat > den Vorschlag falsch verstanden, was aber nichts daran ändert, daß ich > diesem nicht folgen mag, da das <relatedItem type="original"> einfach > anders verwendet wird in MODS als wir es hier unterstellen müßten. > > Allen Verwendungen von <relatedItem> dienen nach meinem Verständnis > dazu, Beziehungen zu anderen Datensätzen (!) auszudrücken. Schaut man > sich hierzu das LoC-MARC21-MODS-Mapping genauer an, dann sieht man, > wie das Element zu verwenden ist. [1] Es leitet sich im Kern von den > MARC21-Feldern 760-787 und > 800-830 ab. Uns braucht hier nur die erste Feldsequenz zu interessieren [2] > und hier dann speziell [3]. Schaut man nun ins Mapping, dann sieht man, daß > die Mapping-Regeln nicht zu der Modellierung führen, die Frau Rühle > vorschlägt. MARC21 Feld 786 (die MARC21-Grundlage von <relatedItem > type="original">) ist einfach nicht dazu gedacht, Angaben zur Primärform in > der hier vorgeschlagenen Weise zu transportieren, es dient vielmehr dazu, > eine Beziehung zwischen Primär- und Sekundärform herzustellen! > > Wenn wir an dieser Stelle Änderungen vornehmen wollen, dann hilft uns > m.E. > ein Blick in die EROMM-"Empfehlungen zur Erfassung von layoutgetreuen > Digitalisaten (digitale Master)" eher weiter. [4] Hier sieht man, daß nicht die > Angaben zum Erscheinungsvermerk der Vorlage anders kodiert werden > müßten, sondern die Angaben zur Onlineausgabe. Hierzu dient in MARC21 > Feld 533. (Eine solche Abbildung wäre auch kompatibel mit den Mapping- > Regeln der zugrundeliegenden MAB-Felder 610ff., wie sie in [6] beschrieben > sind.) Ist MARC21-Feld 533 noch hinreichend differenziert, um die Angaben, > die wir hier brauchen, zu transportieren, wird nach Anwendung des LoC- > Mappings jedoch in etwa folgendes MODS daraus: > > <note type="reproduction">[Online-Ausg.] Göttingen : Niedersächsische > Staats- und Universitätsbibliothek, 2010</note> > > Wir hätten also die differenzierte aktuelle Codierungsform durch eine > "getypte Anmerkung" ersetzt. Ob ich das dann unterstützen würde, weiß ich > noch nicht so genau. ;) > > Beste Grüße, > Kay Heiligenhaus > > [1] http://www.loc.gov/standards/mods/mods-mapping.html#relateditem > > [2] http://www.loc.gov/marc/bibliographic/bd76x78x.html > > [3] http://www.loc.gov/marc/bibliographic/bd786.html > > [4] > http://www.eromm.org/_media/public/de/digitalemaster.pdf?id=public%3 > Ade%3Acat > aloguing&cache=cache > > [5] http://www.loc.gov/marc/bibliographic/bd533.html > > [6] http://www.d-nb.de/standardisierung/pdf/konkordanz_1.pdf > > > -----Original Message----- > > From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- > > bounces(a)dfg-viewer.de] On Behalf Of Kay Heiligenhaus > > Sent: Thursday, November 25, 2010 9:07 PM > > To: dv-technik(a)dfg-viewer.de; Meyer, Sebastian; technik(a)dfg-viewer.de > > Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC > > > > Lieber Herr Meyer, > > > > ich fühle mich an Diskussionen bei unseren Sitzungen in Halle vor zwei > Jahren > > erinnert. Da hatten wir das Thema auch schon auf der Pfanne... ;) > > > > > Die aktuelle Lösung ist meines Erachtens eben nicht immer eindeutig, > > > da es für die Angaben zur Vorlage nur ein Negativ-Kriterium (*kein* > > > <edition>[Electronic ed.]</edition>), aber kein Positiv-Kriterium > > > gibt. Worauf bezieht sich also ein <originInfo>-Abschnitt, wenn es > > > keinen Abschnitt mit diesem Kriterium gibt? Handelt er dann von der > > > Vorlage oder folgt die METS- Datei schlicht nicht unserem Profil? > > > > Dann sollten wir m.E. eher dafür streiten, daß das <mods:originInfo>- > > Element um ein @type-Attribut erweitert wird. Unterm Strich würde ich > > aber > > sagen: Wenn ein solcher Block nicht vorhanden ist, dann hat das > > zugrundeliegende digitalisierte Werk offensichtlich weder einen Umfang > > noch einen Erscheinungs-/Entstehungsort noch einen Erscheinungs- > > /Entstehungszeitpunkt. Und es existieren auch offensichtlich keinerlei > > Vermutungen darüber (was mich zumindest beim Umfang verwundern > würde). > > Also eigentlich müßte man dann sagen: Es existiert folglich gar > nicht > > und der Viewer muß es folglich auch nicht anzeigen. ;) > > > > > Mit der Lösung über <relatedItem> hätten wir dieses Problem nicht. > > > Und ich verstehe METS hier so, dass kein vollständiger > > > bibliographischer Datensatz in <relatedItem> stehen muss. (So > > > handhaben wir das ja auch bei <relatedItem type="host"> und > > > <relatedItem type="series">.) > > > > Stimmt. Das sagt der Entwurf aber so nicht. Und wenn er es sagen > > würde, würde ich einwenden: Und deshalb invalidieren wir alle bislang > > erstellten MODS-Daten? > > > > > Ihrem Vorschlag eines <dv:version>-Elements schließe ich mich an. > > > > Prima. Dann sollten wir nochmal überlegen, was noch auf unserer Agenda > > stand. Ich erinnere mich z.B. an die Forderung aus den DFG-Gremien, > > daß man das DFG-Logo gezielt überschreiben können sollte, um eine > > Nutzung auch außerhalb von DFG-Förderungen zu erleichtern... > > > > Beste Grüße, > > Kay Heiligenhaus > > > > > > > > > > >

14 years, 1 month

Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC

by Kay Heiligenhaus

Liebe Frau Rühle, vielen Dank für die Übersendung des Profil-Entwurfes, den ich bereits sehr gelungen finde! Hier meine Anmerkungen dazu: 1) Ich würde auf ein Mapping nach DC verzichten, aber das Mapping zu MAB2 und PICA+ (strenggenommen: in der Ausprägung des GBV) auf jeden Fall beibehalten wollen (S. 4). 2) Mir erschließt sich noch nicht, warum wir bibliographische Informationen zur analogen Vorlage (<mods:relatedItem type="original">) liefern sollten (S. 4). Wo sehen Sie hier einen Anwendungsfall? 3) Ich würde strenger formulieren und die Verwendung von UTF-8 nicht als "Soll-Regelung" formulieren (S. 5). Ich würde mich hier letztlich an den Vorgaben des OAI-PMH-2.0-Protokolls orientieren. [1] 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. 5) Die Ausführungen (S. 5) zu Artikeln in Titel und zur Verwendung von <mods:nonSort> sind m.E. nicht hinreichend. Da sind die zugrundeliegenden bibliographischen Regelwerke doch etwas differenzierter. Auch die Ausführungen in den MODS User Guidelines sind hier differenzierter: "'nonSort' begin and end tags surround the nonfiling text which should not be regarded in sorting. It is equivalent to the new technique in MARC 21 that uses control characters to surround data disregarded for sorting. It is used for the same purpose as the nonfiling indicator value that indicates the number of characters disregarded for sorting. Punctuation may or may not be included within the non-sort value depending upon whether it is part of the sorting or non-sorting data." [4] 6) Die Ausführungen zu <mods:genre> sind m.E. ein bißchen zu dünn geraten. Ich würde auf jeden Fall die Nutzung des kontrollierten Vokabulars nach "marcgt" [5] hier anführen, zumindest unter den Beispielen darauf hinweisen. Gleichzeitig könnte man bei der AAD im GBV anfragen, ob es evtl. kurzfristig möglich sein wird, URIs für die Terme der Liste der Gattungsbegriffe einzuführen, auf die man dann verlinken kann. 7) Bei <mods:originInfo> (S. 11ff) sollte man m.E. Beispiele für die Verwendung mehrere Erscheinungsorte und Verlage geben. Hier spielt m.E. die Reihenfolge durchaus eine Rolle! 8) Das Beispiel zur Verwendung von @keydate (S. 15) halte ich nicht für plausibel. 9) Warum ist <mods:digitalOrigin> weiterhin "mandatory" (S. 18)? Ich sehe nur einen sehr begrenzten Nutzen, den man aus dieser Information gewinnen kann. 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]. 11) Die Definition von <mods:identifier> halte ich für überarbeitungsnotwendig: "Ein Identifier muss eindeutig sein, d. h. er steht für eine und nur eine Ressource." (S. 28) Was ist mit "Ressource" gemeint? Auch bibliographische Datensätze? Denn darauf beziehen wir uns, wenn wir hier z.B. VD-Nummern eintragen. Hinter eine VD-Nummer können sich aber x "Ressourcen" (= Sekundärformen) verbergen. 12) Die Definition von mods:recordIdentifier/@source halte ich für ebenfalls überarbeitungsnotwendig: "source='Name der Organisation, deren Identifier in diesem Element verwendet wird'" (S. 33). Das zeigen schon die Beispiele, die anschließend gelistet werden: Der Wert "gvk-ppn" ist ganz sicher nicht der Name der Organisation, deren Identifier in diesem Element verwendet wird. Aus meiner Sicht muß hier schlicht ein beliebiger, innerhalb der jeweiligen Anwendung eindeutiger Bezeichner stehen. Das nach meiner ersten Durchsicht als erste Anmerkungen. So haben wir vielleicht die Zeit, auf der Liste die eine oder andere Frage noch etwas ausführlicher zu diskutieren. Beste Grüße, Kay Heiligenhaus [1] http://www.openarchives.org/OAI/openarchivesprotocol.html#XMLResponse [2] http://s2w.visuallibrary.net/ihd/oai/?verb=GetRecord&metadataPrefix=mets&id… [3] http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fs2w.visuallibrary.net%2Foai… [4] http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#nonsort [5] http://www.loc.gov/standards/valuelist/marcgt.html [6] 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 Ruehle, Stefanie > Sent: Wednesday, November 24, 2010 2:31 PM > To: dv-technik(a)dfg-viewer.de > Subject: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC > > Liebe Kolleginnen und Kollegen, > > im Anhang finden Sie den Entwurf für das MODS-Anwendungsprofil für > digitalisierte Drucke (als doc und als pdf). Es handelt sich hierbei um eine > überarbeitete Version des zvdd-MODS Anwendungsprofils Version 1.0 (s. > http://www.zvdd.de/fileadmin/AGSDD- > Redaktion/zvdd_MODS_Application_Profile_20 > 08-11-13.pdf). Dabei wurden die folgenden Änderungen vorgenommen: > > * Erweiterung des Profils, um die übergreifende Nutzung in verschiedenen > Digitalisierungsprojekten zu erleichtern > ** Einige Elemente sind nun nicht mehr verpflichtend, sondern conditional > bzw. optional > ** weitere Attribute wurden hinzugefügt (z.B. authorityURI, valueURI, etc.) > > * Der Aufbau des Profils orientiert sich nun an den MODS User Guidelines > (http://www.loc.gov/standards/mods/mods-outline.html) > > * Die in dem zvdd-MODS Anwendungsprofil mit UNE (unerwünscht) > gekennzeichneten Elemente wurden in diesem Profil nicht mehr > berücksichtigt. > > * Informationen zu der analogen Vorlage des Digitalisats / zum Original > können in Zukunft unter <mods:relatedItem type="original"> zur Verfügung > gestellt werden. > > * zvdd-spezifische Anforderungen wurden nicht übernommen und werden > in einem eigenen Papier veröffentlicht. > > * Die in dem zvdd-MODS Anwendungsprofil integrierten Mappings werden > in Anhängen zur Verfügung gestellt. > > Noch nicht fertigestellt sind die Anhänge: > > * Die Überarbeitung der METS-MODS-Beispiele - diese würde ich gerne erst > nach der Verabschiedung des APs fertigstellen. > * Die Überarbeitung des PICA+-Mappings > * Die Überarbeitung des MAB-Mappings - bitte teilen Sie mir mit, ob dieses > Mapping noch benötigt wird. > * Die Erstellung eines Dublin Core Mappings - auch dies werde ich erst nach > der Verabschiedung des APs erstellen. > > Zudem braucht das Anwendungsprofil nun einen anderen Namen. Über > Vorschläge würde ich mich freuen. > > Bitte schicken Sie Anmerkungen und Korrekturvorschläge bis zum 15. > Dezember über diese Liste, damit sie von allen Interessierten diskutiert > werden können. > > Viele Grüße > > 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 > >

14 years, 1 month

Strukturelemente ohne Bilder werden in der Navigation nicht angezeigt.

by Silvio Hermann

Liebe Liste, Bei dem unter folgender URL erreichbaren Dokument http://dfg-viewer.de/demo/viewer/?set[mets]=http%3A%2F%2Farchive.thulb.uni-… werden nicht alle Strukturelemente angezeigt. Schaut man sich die zugehörige Metsdatei an http://archive.thulb.uni-jena.de/ufb/servlets/MCRMETSServlet/ufb_derivate_0… stellt man fest, das dem (nicht angezeigten) Strukturelement 'Predigt' (log000003) selbst keine "Bilder" zugeordnet sind. Die Sektion "Predigt" dient hier also nur zur Vorstrukturierung. Warum wird dieses Element nicht mit angezeigt? Ist das gewünschtes Verhalten? Grüße, Silvio Hermann -- Silvio Hermann Friedrich-Schiller-Universität Jena Thüringer Universitäts- und Landesbibliothek Bibliotheksplatz 2 07743 Jena Phone: ++49 3641 940019 FAX: ++49 3641 940022

14 years, 1 month

Re: [DFG-Viewer] Strukturelemente ohne Bilder werden in der Navigation nicht angezeigt.

by Meyer, Sebastian

Lieber Herr Scheffler, Noch einmal: es geht hier nicht darum, ob sich die von Ihnen angeregte Vererbung innerhalb der logischen Struktur technisch im DFG-Viewer umsetzen ließe. Das wäre natürlich möglich. Ausschlaggebend ist aber nicht der Viewer, sondern das Anwendunsprofil, dem der Viewer folgen muss. Dort müsste die Vererbung also als Grundannahme definiert werden. Weshalb das nicht getan wurde, haben Herr Enders, ich und andere Kollegen versucht darzulegen. Im Klartext: es handelt sich _nicht_ um ein technisches Problem oder ein Problem der Implementierung, sondern um eine Frage der medientypologischen Freiheit des Formats und der Kompatibilität zu anderen METS-Implementierungen. Dazu ist es meines Erachtens sinnvoll, so viel wie möglich im Format explizit auszudrücken und nicht implizit über verabredete Grundannahmen. Im Idealfall sollte das Format auch dann eindeutig interpretierbar sein, wenn man das Anwendungsprofil (und damit eventuelle implizite Annahmen) nicht kennt. 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: Thomas Scheffler Sent: Freitag, 26. November 2010 08:05 An: dv-technik(a)dfg-viewer.de Betreff: Re: [DFG-Viewer] Strukturelemente ohne Bilder werden in der Navigation nicht angezeigt. Am 25.11.2010 16:55, schrieb Meyer, Sebastian: > Lieber Herr Scheffler, > >> ich verstehe ihren Einwand, dass man dies ausdrücken können muss, >> glaube aber, dass bei der aktuellen Präsentation es sehr schwierig >> sein wird dies dem Nutzer nahe zu bringen, denn dann weiß er >> nicht, ob die Blätter-Navigationselemente dann in der physischen >> oder logischen Reihenfolge blättern. Deswegen war ich dafür an der >> Stelle grundsätzlich die physische Reihenfolge zu nehmen, weil die >> am wenigsten Verwirrung stiften sollte. > > Genau so macht es der DFG-Viewer ja auch: wenn Sie blättern oder > über die Drop-Down-Navigation direkt eine Seite anspringen, dann > liegt dieser Navigation die physische Reihenfolge der Images zugrunde > (also die Reihenfolge, die sich aus der physischen structMap > ergibt). Dann haben wir uns gehörig in der Diskussion über physische und logische Reihenfolge verzettelt. Wie gesagt man kann dem Nutzer nur eines sinnvoll darstellen und das ist die physische Reihenfolge. > Die Strukturnavigation auf der rechten Seite ist aber etwas anderes, > denn hier navigieren Sie nicht durch die physische Struktur, sondern > durch die logische Struktur. Und um das gewährleisten zu können, muss > der DFG-Viewer wissen, auf welcher Seite die jeweilige Struktur > beginnt (denn dorthin verlinkt er den Eintrag) und über welche Seiten > sie sich erstreckt (denn der jeweilige Eintrag wird optisch > hervorgehoben, solange der Nutzer sich auf einer dieser Seiten > befindet). Diese Informationen können aber eben nur über die > structLinks ermittelt werden, weshalb sie explizit für jede logische > Struktur angegeben werden müssen. Muss man eben genau nicht. Um festzustellen, was die erste Seite eines logischen Strukturelementes ist bedient man sich des Mittels der Rekursion: 1.) Die gesuchte Seite ist im aktuellen Strukturelement (bisheriger Fall), wenn nicht: 2.) Das Strukturelement befindet sich im ersten Kind (Überprüfung mittels Schritt 1), wenn nicht 3.) Für alle weiteren Kinder prüfe nach Schritt 1 Das ganze lässt sich so extrem trivial implementieren, dass es um die Diskussion schon schade ist. Umgekehrt funktioniert das auch für Strukturzugehörigkeit von Seiten: 1.) Finde Zugehörigkeit von Seite mittels smLinks zu Struktureinheiten 2.) Markiere alle Elternelemente als aktiv. > Meines Erachtens ist hier wichtig, dass der DFG-Viewer eine > Implementierung des Anwendungsprofils darstellt und nicht umgekehrt, > d.h. das Anwendungsprofil stellt eine allgemeine Einigung auf ein > gemeinsames Datenformat dar und nicht bloß eine > Schnittstellendokumentation des DFG-Viewers. Tut er ja nicht! So wird die logische Reihenfolge ja nirgendwo berücksichtigt, sie ist für den Viewer irrelevant. Gleichzeitig werden aber einfache Annahmen nicht getroffen, die die METS-Dokumente sehr viel verständlicher machen würden. Der gezeigte Algorithmus arbeitet korrekt für alle bisherigen von ihnen genannten Sonderfällen und zusätzlich in dem von uns beschriebenen Standardfall. Wenn dies also möglich ist, dann ist es auch möglich das zugrunde liegende Format zu beschreiben, so dass alle Fälle abgedeckt sind - widerspruchsfrei. Die bisherigen Reaktionen zeigen mir, dass wir zwar Recht haben, weil in all den Mails dieses Threads - und der Vordiskussion mit semantics - kein einziger Grund genannt worden ist, wieso so ein Verhalten nicht umsetzbar ist. Die Folgerung muss sein: Weil es keinen Grund gibt. Trotzdem muss ein gewisser Wille zu Kooperation schon auf beiden Projektseiten vorhanden sein, damit man sich insgesamt verbessern kann. Meine Wahrnehmung ist leider, dass dies in der aktuellen Konstellation nicht möglich zu sein scheint. Es ist müßig hier weiter zu diskutieren. Die Argumente sind ausgetauscht und wenn es auf Seiten des DFG-Viewers nicht den Wunsch gibt, sich sukzessive zu verbessern und auf das Feedback der Nutzer nicht eingegangen wird, dann ist dem Projekt auch von unserer Seite nicht zu helfen. Mit freundlichen Grüßen Thomas Scheffler -- Thomas Scheffler Friedrich-Schiller-Universität Jena Thüringer Universitäts- und Landesbibliothek Bibliotheksplatz 2 07743 Jena Phone: ++49 3641 940027 FAX: ++49 3641 940022

14 years, 1 month

← Newer
1
...
13
14
15
16
17
18
19
...
33
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

DV-Technik