Lieber Herr Meyer, lieber Herr Schaßan,
besten Dank für die Bereitstellung des Beispiels! Das sieht doch schon mal, nach erster Sichtung, sehr vielversprechend aus! Erste Anmerkungen / Nachfragen von meiner Seite:
1) Aktuell finden sich ja noch keine Strukturdaten im Beispiel. Hier sehe ich eigentlich der größten Klärungsbedarf, denn anders als bei Druckschriften haben wir im Handschriftenbereich keine so klare "Aufgabenteilung" zwischen TEI und METS wie zwischen MODS und METS. In welche Richtung gehen da aktuell Ihre Überlegungen?
2) Entsprechend fehlt die log. structMap (und damit auch die persistente Adressierung der Handschrift via @ CONTENTIDS). Die Verlinkung unter structLink
<mets:structLink>
<mets:smLink xlink:from="log_mss_278-helmst_tei-msDesc_Lesser" xlink:to="phys_mss_278-helmst_tei-msDesc_Lesser"/>
</mets:structLink>
ist deshalb auch noch ein Fake, denn ein Element mit der ID "log_mss_278-helmst_tei-msDesc_Lesser" fehlt ja im Dokument. (Eigentlich dürfte der Viewer so was überhaupt nicht anzeigen, aber wenn die zugrundeliegende Frage noch nicht geklärt ist, kann man damit vorerst leben).
3) Das Element <mets:digiprovMD> enthält einen interessanten Hinweis von Herrn Schaßan:
<mets:digiprovMD ID="digiprov_mss_278-helmst_tei-msDesc_Lesser">
<mets:mdWrap MIMETYPE="text/xml" MDTYPE="OTHER" OTHERMDTYPE="DVLINKS">
<mets:xmlData>
<dv:links xmlns:dv="http://dfg-viewer.de/">
<dv:reference>zu_berechnen_oder_als_Parameter_zu_übergeben</dv:reference>
<dv:presentation/>
</dv:links>
</mets:xmlData>
</mets:mdWrap>
</mets:digiprovMD>
Hm. Da erlaube ich mir doch die Nachfrage, ob das wirklich z.Z. eine Überlegung ist in der Community? An welchen "Berechnungsalgorithmus" haben Sie denn so gedacht?
Beste Grüße,
Kay Heiligenhaus
Liebe Kolleginnen und Kollegen,
als kleines Weihnachtsgeschenk habe ich gerade einen ersten Prototypen des DFG-Viewers fertiggestellt, der neben METS/MODS auch METS/TEI interpretieren kann. Damit können neben Drucken und Zeitschriften auch mittelalterliche und frühneuzeitliche Handschriften präsentiert werden.
Es handelt sich ausdrücklich um eine erste Machbarkeitsstudie, die sicher noch viele Ungereimtheiten enthält - also bitte haben Sie Nachsicht, wenn noch nicht alles wie erwartet funktioniert.
Die zugrundeliegende METS/TEI-Datei wurde freundlicherweise von Torsten Schassan (HAB Wolfenbüttel) zur Verfügung gestellt und findet sich hier:
http://dfg-viewer.de/fileadmin/groups/dfgviewer/tei_example.xml
Den Prototypen erreichen Sie über folgende URL:
http://dfg-viewer.de/tei-prototyp
Es wird nach Aufruf des Links standardmäßig obige Handschrift angezeigt, Sie können den URL-Parameter "set[mets]" aber natürlich wie gehabt anpassen, um auch andere METS-Dateien zur Anzeige zu bringen.
Noch ausstehende Arbeiten sind unter anderem:
- Klärung der Frage, welcher Titel bzw. Autor vorrangig angezeigt werden soll: die der Handschriftenbeschreibung (in /teiHeader/fileDesc/titleStmt) oder - sofern vorhanden - die der Handschrift (in /teiHeader/fileDesc/sourceDesc/msDesc/head)?
- Abbildung der Struktur aus /teiHeader/fileDesc/sourceDesc/msDesc/msContents in einer logischen structMap in METS und Verknüpfung der deskriptiven Metadaten.
- Verknüpfung der Beschreibungen in /teiHeader/fileDesc/sourceDesc/msDesc/physDesc mit der physischen structMap in METS.
- Anzeige handschriftenspezifischer Metadaten. Bislang ist nur die Anzeige der Foliierung in der Dropdown-Seitennavigation umgesetzt.
Neben technischen Arbeiten sind auch noch zahlreiche Formatfragen offen, die in der Handschriften-Community in den nächsten Monaten angegangen werden sollen.
Viele Grüße und Ihnen allen frohe Festtage!
Sebastian Meyer
PS: Ich werde den Januar und Februar (mal wieder) auf der südlichen Hemisphäre verbringen und bin daher nur sehr sporadisch erreichbar. Meine Vertretung in Sachen DFG-Viewer wird in dieser Zeit mein Kollege Ralf Claußnitzer übernehmen, den Sie auch über diese Mailingliste erreichen.
--
Sebastian Meyer
Referatsleiter 2.1 - 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/
Lieber Herr Heiligenhaus,
Vielen Dank für den Hinweis. Der DFG-Viewer geht nun wieder. Woran es lag, kann ich allerdings noch nicht sagen.
Bezüglich einer Verbesserung der Ausfallsicherheit hatten wir ja im Frühsommer bereits Maßnahmen beschlossen. Der entsprechende DFG-Antrag ist jedoch noch immer in Begutachtung. Wir sind jedoch bereits dabei, den verteilten Betrieb gemeinsam mit der SUB Göttingen vorzubereiten.
Viele Grüße und einen schönen Restsonntag
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: Sonntag, 5. Dezember 2010 13:27
An: dv-technik(a)dfg-viewer.de
Betreff: [DFG-Viewer] Ausfall DFG-Viewer seit 11:35h
Lieber Herr Meyer,
unseren Logs zufolge ist der DFG-Viewer seit heute morgen, 11:35h, ausgefallen. Offensichtlich betrifft das aktuell das gesamte SLUB-Netz. Wir hatten das in diesem Jahr bereits mehrfach beobachtet. Wenn ich mich recht entsinne, dann ebenfalls immer sonntags. Ich denke, wir müssen uns bei unserem nächsten Treffen mal intensiver mit Fallback-Szenarien beschäftigen.
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Meyer,
unseren Logs zufolge ist der DFG-Viewer seit heute morgen, 11:35h, ausgefallen. Offensichtlich betrifft das aktuell das gesamte SLUB-Netz. Wir hatten das in diesem Jahr bereits mehrfach beobachtet. Wenn ich mich recht entsinne, dann ebenfalls immer sonntags. Ich denke, wir müssen uns bei unserem nächsten Treffen mal intensiver mit Fallback-Szenarien beschäftigen.
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Heiligenhaus,
Die Tücken der Katalogisierung... Da haben sie mich wieder einmal erwischt.
Vielen Dank für das anschauliche Beispiel aus dem SWB, damit habe jetzt sogar ich es kapiert. ;-)
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: Dienstag, 30. November 2010 18:37
An: dv-technik(a)dfg-viewer.de
Betreff: Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC
Lieber Herr Meyer,
> Richtig, aber ich habe den Druck _digitalisiert_ und nicht gedruckt, weshalb
> das _Digitalisat_ auch keinen Druckort besitzt, die Vorlage aber schon. Den
> Inhalt hat aber in beiden Fällen derselbe Autor verfasst, denn einen Inhalt
> hat auch das Digitalisat und dieser ist auch gegenüber der gedruckten
> Vorlage unverändert.
Wollen Sie das dann auch im Header im Viewer anzeigen? Also z.B. bei diesem Druck
http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fs2w.visuallibrary.net%2Foai…
Anstatt:
Luther, Martin: Widder den Meuchler zu Dresen gedrueckt Wittemberg 1531 [VD16 L 7428]
Eben:
Luther, Martin: Widder den Meuchler zu Dresen gedrueckt Aachen 2010 [VD16 L 7428]
> Eben nicht. Meines Erachtens handelt es sich dann um eine Streitschrift
> Martin Luthers, digital publiziert von Kay Heiligenhaus 2010 in Aachen, die auf
> einer 1531 von Hans Lufft in Wittenberg gedruckten Vorlage basiert. Und
> genau so geben wir das doch bislang auch in den Metadaten an, nur dass wir
> die Angaben zur Vorlage und die abweichenden Angaben zum Digitalisat in
> zwei separate <mods:originInfo>-Blöcke kapseln, statt - wie es Frau Rühle
> vorschlägt - die Angaben zur Vorlage in <mods:relatedItem type="original">
> unterzubringen.
> Ich hatte die Tatsache, dass wir für die Digitalisate auch eigene Katalogisate
> im Verbund anlegen, bisher auch immer so verstanden, dass das Digitalisat
> tatsächlich als eigenständige Publikation betrachtet wird. Ist dem nicht so?
Nehmen wir einfach ein Beispiel aus dem Dresdner VD18-Bestand:
http://swb.bsz-bw.de/DB=2.1/PPNSET?PPN=331522233
In der Sekundärform finden Sie die Angaben zum Erscheinungsvermerk in PICA+ 033A$pLeipzig$nBauch und 011@$a1716. Die Angaben zur Sekundärausgabe stehen in 033N$pDresden$nSLUB und 011B$a2010. Nun sehen Sie sich die Primärform an:
http://swb.bsz-bw.de/DB=2.1/PPNSET?PPN=061720305
Auch hier finden Sie die Angaben zum Erscheinungsvermerk ganz analog zur Sekundärform in PICA+ 033A$pLeipzig$nBauch und 011@$a1716. _Das_ ist die aktuelle Katalogisierungspraxis. Hierzu existieren Mappings zu MARC21, die vom BSZ auch ziemlich weitreichend umgesetzt wurden. Von hier aus kommen Sie via existierender Mappings zu MODS (hatte ich alles bereits, denke ich, hinreichend hier vorgestellt). Und wenn Sie das nun alles durchspielen, zerfallen alle Ihre Überlegungen: zu bibliographischem Staub. Es sei denn, man möchte einen proprietären Sonderweg einschlagen, der einfach die bibliographischen Tatsachen ignoriert und vollkommen inkompatibel ist mit dem, was der Rest der Welt so treibt. Ich denke nicht, daß Sie das wirklich möchten.
Wie gesagt, wenn man das alles konsequent durchspielt, dann bleibt zum Schluß: Entweder, wir lassen es, wie es ist. Oder, wir machen es via Abbildung auf MARC21 533 mit note/@type="reproduction" (das würde aus dem Mapping PICA+/MAB2 zu MARC21 folgen). Alles andere ist schlichtweg nicht haltbar, da mögen Sie noch so lange argumentieren, daß Sie das anders _sehen_. Es _ist_ nicht anders. Vielleicht sprechen Sie darüber einfach mal mit einem Katalogisierer Ihres Vertrauens. ;)
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Meyer,
> Richtig, aber ich habe den Druck _digitalisiert_ und nicht gedruckt, weshalb
> das _Digitalisat_ auch keinen Druckort besitzt, die Vorlage aber schon. Den
> Inhalt hat aber in beiden Fällen derselbe Autor verfasst, denn einen Inhalt
> hat auch das Digitalisat und dieser ist auch gegenüber der gedruckten
> Vorlage unverändert.
Wollen Sie das dann auch im Header im Viewer anzeigen? Also z.B. bei diesem Druck
http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fs2w.visuallibrary.net%2Foai…
Anstatt:
Luther, Martin: Widder den Meuchler zu Dresen gedrueckt Wittemberg 1531 [VD16 L 7428]
Eben:
Luther, Martin: Widder den Meuchler zu Dresen gedrueckt Aachen 2010 [VD16 L 7428]
> Eben nicht. Meines Erachtens handelt es sich dann um eine Streitschrift
> Martin Luthers, digital publiziert von Kay Heiligenhaus 2010 in Aachen, die auf
> einer 1531 von Hans Lufft in Wittenberg gedruckten Vorlage basiert. Und
> genau so geben wir das doch bislang auch in den Metadaten an, nur dass wir
> die Angaben zur Vorlage und die abweichenden Angaben zum Digitalisat in
> zwei separate <mods:originInfo>-Blöcke kapseln, statt - wie es Frau Rühle
> vorschlägt - die Angaben zur Vorlage in <mods:relatedItem type="original">
> unterzubringen.
> Ich hatte die Tatsache, dass wir für die Digitalisate auch eigene Katalogisate
> im Verbund anlegen, bisher auch immer so verstanden, dass das Digitalisat
> tatsächlich als eigenständige Publikation betrachtet wird. Ist dem nicht so?
Nehmen wir einfach ein Beispiel aus dem Dresdner VD18-Bestand:
http://swb.bsz-bw.de/DB=2.1/PPNSET?PPN=331522233
In der Sekundärform finden Sie die Angaben zum Erscheinungsvermerk in PICA+ 033A$pLeipzig$nBauch und 011@$a1716. Die Angaben zur Sekundärausgabe stehen in 033N$pDresden$nSLUB und 011B$a2010. Nun sehen Sie sich die Primärform an:
http://swb.bsz-bw.de/DB=2.1/PPNSET?PPN=061720305
Auch hier finden Sie die Angaben zum Erscheinungsvermerk ganz analog zur Sekundärform in PICA+ 033A$pLeipzig$nBauch und 011@$a1716. _Das_ ist die aktuelle Katalogisierungspraxis. Hierzu existieren Mappings zu MARC21, die vom BSZ auch ziemlich weitreichend umgesetzt wurden. Von hier aus kommen Sie via existierender Mappings zu MODS (hatte ich alles bereits, denke ich, hinreichend hier vorgestellt). Und wenn Sie das nun alles durchspielen, zerfallen alle Ihre Überlegungen: zu bibliographischem Staub. Es sei denn, man möchte einen proprietären Sonderweg einschlagen, der einfach die bibliographischen Tatsachen ignoriert und vollkommen inkompatibel ist mit dem, was der Rest der Welt so treibt. Ich denke nicht, daß Sie das wirklich möchten.
Wie gesagt, wenn man das alles konsequent durchspielt, dann bleibt zum Schluß: Entweder, wir lassen es, wie es ist. Oder, wir machen es via Abbildung auf MARC21 533 mit note/@type="reproduction" (das würde aus dem Mapping PICA+/MAB2 zu MARC21 folgen). Alles andere ist schlichtweg nicht haltbar, da mögen Sie noch so lange argumentieren, daß Sie das anders _sehen_. Es _ist_ nicht anders. Vielleicht sprechen Sie darüber einfach mal mit einem Katalogisierer Ihres Vertrauens. ;)
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Meyer,
> Grundsätzlich gebe ich Ihnen recht: natürlich sollten alle bibliographischen
> Angaben zur Vorlage in <relatedItem type="original"> stehen. Dass das der
> Idealzustand wäre, wir ihn aber mit unserer aktuellen Katalogisierungspraxis
> nicht erreichen, ist mir bewusst - dennoch halte ich es für sinnvoll, auf diesen
> Idealzustand hinzuarbeiten.
Jetzt kommen Sie ins Philosophieren. ;) - - - Vor lt. Digitalisierung scheinen Sie zu verkennen, daß es einen guten Grund gibt, warum Sekundärformen so nicht katalogisiert werden: Wenn wir eine Streitschrift Martin Luthers, gedruckt von Hans Lufft 1531 in Wittenberg, heute auf den Scanner legen und ins Internet stellen, dann bleibt das eine Streitschrift Martin Luthers, gedruckt von Hans Lufft 1531 in Wittenberg (rsp. deren layoutgetreue Reproduktion)!
> Speziell beim Verfasser würde ich Ihnen allerdings widersprechen, denn der
> Verfasser ist der Urheber des Inhalts eines Werks - und der ändert sich doch
> durch die Digitalisierung nicht, sollte also bei Vorlage und Digitalisat identisch
> sein.
Und so ist das auch beim Erscheinungsvermerk, denn Sie haben genau diesen Druck digitalisiert, nicht den Nachdruck aus Leipzig von 1551.
> Richtig, allerdings sollte ein AP das meines Erachtens nur dort tun, wo es
> notwendig ist. Wenn sich die Zugehörigkeit eines Metadatums zu Vorlage
> bzw. Digitalisat in MODS nicht ausdrücken ließe, dann müsste eine
> entsprechende Festlegung im AP getroffen werden, die das ermöglicht. Nun
> haben wir aber in MODS eine (wie ich finde) sehr naheliegende Möglichkeit,
> die gegenüber unserer bisherigen Festlegung keine Nachteile hat, dafür aber
> den großen Vorteil, auch von jedem anderen MODS-Anwender ohne
> Kenntnis unseres AP verstanden zu werden. Deshalb halte ich es in jedem
> Fall für erstrebenswert, diese Möglichkeit künftig zu nutzen.
Ja. Sie befinden sich damit nur sehr allein auf dem Metadatenfeld. Kein bestehendes Mapping gibt diese Modellierung her. Wir müßten sie ins AP schreiben, damit das jemand verstehen kann (insbesondere eine Maschine, die das Mapping dann abweichend ausführen muß). Und wir müßten dem Rest der Welt erklären, daß er einem großen Irrtum unterliegt und doch bitte unserem, überlegenen Mapping folgen.
Nee. Das ist und bleibt m.E. grundsätzlich falsch gedacht. Es sieht nur mit Ihrer XPath-Brille rosafarben aus. ;)
Beste Grüße,
Kay Heiligenhaus
Liebe Frau Rühle,
ich habe mir das mal weiter angeschaut - und es gibt eine knappe Diskussion zum Thema auf der MODS-Mailingliste unter [1]. Das Ergebnis kann man sehen im Vergleich der XSLT-Versionen für MODS v3.2 [2] und MODS v3.3 [3]: Das Mapping von MARC21-Feld 752 gibt es seit MODS v3.0. Erst mit MODS v3.3 wird dann ein paralleles Mapping von MARC-Feld 662 eingeführt. Man kann also m.E. eindeutig davon ausgehen, daß es sich hier nicht um einen Fehler handelt, sondern eben um eine bewußte Entscheidung. Diese scheint mir auch begründet, den es gibt eine reichhaltige Diskussion über die Verwendung von MARC21-Feld 752. Schaut man sich z.B. den "Guide to Rare Book Records in Online Systems" an, dann liest man:
"NOTE (c): According to the USMARC format documentation, field 752 (Added Entry-Hierarchical Place Name) may be used 'to give access to a bibliographic record through a hierarchical form of a place name related to a particular attribute (e.g. for newspapers, the name of the community served; for rare books, the place of publication or printing).' Because of the range of situations in which this field may be used, it is advisable to give it a fairly general label, such as 'Place' or 'Associated place' rather than 'Place of publication'." [4]
Bedeutet unterm Strich, daß in MARC21 die Verwendung von Feld 752 so vielfältig ist, daß man schlicht nicht davon ausgehen kann, daß hier ausschließlich normierte Verlags-/Druckorte stehen. Diese Differenziertheit haben wir jedoch in MAB2 und PICA+ (wobei sie verloren ginge, sollten die Verbünde irgendwann auf MARC21 als Katalogisierungsformat umsteigen). Würde man so mappen, wie von mir vorgeschlagen, würde man mit dieser Einschränkung leben müssen, hätte aber den Vorteil, internationalen Standards zu folgen und nicht zwanghaft an der Differenziertheit unserer nationalen Erschließung zu kleben. Man sieht am MAB2-MARC21-Mapping der DNB, daß dieser Kompromiß hier eben eingegangen wurde.
Nun haben wir uns entschieden, das für digitalisierte Drucke noch weiter zu vereinfachen, indem wir MODS als Datenformat gewählt haben. Und gleichzeitig kleben wir an einer Reichhaltigkeit der bibliographischen Beschreibung, die es nicht mal in MARC21 gibt. Wie gesagt, ich bin damit auch nicht wirklich glücklich. Aber es macht auch m.E. keinen Sinn, bei unseren Diskussionen diese Grundentscheidung zur Simplifikation durch die Verwendung von <mods:extension> auszuhebeln oder schlicht wichtige Informationen dann eben gar nicht zu liefern.
Das nun wirklich abschließend von meiner Seite zu dieser Diskussion. Wenn wir uns für das MODS AP v2.1 nicht einigen können - wie es aussieht -, dann bliebe wohl tatsächlich nur, hier eben separate Vereinbarungen für z.B. das VD18 zu treffen und sich im AP v2.1 über das Thema einfach auszuschweigen.
Beste Grüße,
Kay Heiligenhaus
[1] http://comments.gmane.org/gmane.comp.text.mods/872
[2] http://www.loc.gov/standards/mods/v3/MARC21slim2MODS3-2.xsl
[3] http://www.loc.gov/standards/mods/v3/MARC21slim2MODS3-3.xsl
[4] http://www.rbms.info/committees/bibliographic_standards/committee-docs/guid…
> -----Original Message-----
> From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-
> bounces(a)dfg-viewer.de] On Behalf Of Kay Heiligenhaus
> Sent: Tuesday, November 30, 2010 11:14 AM
> To: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de
> Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC
>
> Lieber Frau Rühle,
>
> > Ich bin weiterhin der Meinung, dass sich die Kollegen, die das Mapping
> > gemacht haben, entweder geirrt haben oder einen Anwendungsfall im
> Kopf
> > hatten, der mir nicht bekannt ist. Aber
> > Verlags- und Druckort an dieser Stelle zu speichern, ist m. E. ein
> > semantischer Fehler, den wir vielleicht in bestimmten Projekten über
> > die Verwendung kontrollierter Vokabulare steuern könnten, aber gewiß
> > nicht in allen Projekten.
>
> Um uns herum also offensichtlich lauter Irrtümer, denn auch die Schweizer
> Kollegen scheinen sich schlicht geirrt zu haben, wenn sie ebenfalls MARC21-
> Feld 752 genau zu diesem Zweck nutzen [1] und dem LoC-MARC21-MODS-
> Mapping folgend zu <mods:hierarchicalGeographic> mappen? [2] Daß die in
> MAB2 hier verwendete Segmentgruppe "Segment zusätzliche Suchkriterien"
> heißt, ist ebenfalls ein Irrtum. Daß wir bei Hochschulschriften den
> Hochschulort mit der GKD verknüpfen ebenfalls.
>
> Da wir also von lauter Irrtümern umzingelt sind, schließe ich mich Ihrer
> Schlußfolgerung an, daß wir im DV-MODS-AP v2.1 zu diesem
> Themenkomplex einfach keine Aussagen machen sollten.
>
> Beste Grüße,
> Kay Heiligenhaus
>
> [1]
> http://www.informationsverbund.ch/fileadmin/user_upload/dokumente/k
> atalogisierung/kids/kids_deutsch/bib.pdf - S. 134.
>
> [2] http://www.e-
> rara.ch/bau_1/oai?verb=GetRecord&metadataPrefix=mods&identifier=1062
> 363
Lieber Frau Rühle,
> Ich bin weiterhin der Meinung, dass sich
> die Kollegen, die das Mapping gemacht haben, entweder geirrt haben oder
> einen Anwendungsfall im Kopf hatten, der mir nicht bekannt ist. Aber
> Verlags- und Druckort an dieser Stelle zu speichern, ist m. E. ein semantischer
> Fehler, den wir vielleicht in bestimmten Projekten über die Verwendung
> kontrollierter Vokabulare steuern könnten, aber gewiß nicht in allen
> Projekten.
Um uns herum also offensichtlich lauter Irrtümer, denn auch die Schweizer Kollegen scheinen sich schlicht geirrt zu haben, wenn sie ebenfalls MARC21-Feld 752 genau zu diesem Zweck nutzen [1] und dem LoC-MARC21-MODS-Mapping folgend zu <mods:hierarchicalGeographic> mappen? [2] Daß die in MAB2 hier verwendete Segmentgruppe "Segment zusätzliche Suchkriterien" heißt, ist ebenfalls ein Irrtum. Daß wir bei Hochschulschriften den Hochschulort mit der GKD verknüpfen ebenfalls.
Da wir also von lauter Irrtümern umzingelt sind, schließe ich mich Ihrer Schlußfolgerung an, daß wir im DV-MODS-AP v2.1 zu diesem Themenkomplex einfach keine Aussagen machen sollten.
Beste Grüße,
Kay Heiligenhaus
[1] http://www.informationsverbund.ch/fileadmin/user_upload/dokumente/katalogis… - S. 134.
[2] http://www.e-rara.ch/bau_1/oai?verb=GetRecord&metadataPrefix=mods&identifie…
Lieber Herr Meyer,
> Genau so verstehe ich es auch. Wir beschreiben das Digitalisat und
> verweisen auf die Vorlage. Das entspricht auch unserem
> Digitalisierungsworkflow, der auf dem Verbund-Katalogisat des Digitalisats
> aufsetzt und nicht auf dem des Originals.
Dann sollten wir in der Konsequenz _alle_ bibliographischen Informationen der Vorlage in dieses <mods:relatedItem type="original"> packen, nicht nur die Angaben zum Erscheinungsvermerk. Einen Verfasser des Digitalisates gibt es ja ebenfalls nicht, den hat "nur" die Vorlage. - - - Ich muß ehrlich sagen, daß ich nicht verstehen kann, warum Sie hier unsere aktuelle Katalogisierungspraxis von Sekundärformen schlicht ignorieren und neue bibliographischen Tatsachen erfinden.
> Das veranschaulicht meines Erachtens sehr schön das Problem unserer
> aktuellen Kodierung: sie ist uneindeutig. Wenn kein <originInfo>-Element
> mit <edition>[Electronic ed.]</edition> existiert, sehr wohl aber eines ohne
> <edition>, dann können wir nicht sagen, worauf sich letzteres bezieht -
> Vorlage oder Digitalisat?
Warum das denn?
> Streng nach Anwendungsprofil ist die Sache zwar
> klar, aber auch nur, wenn man das Anwendungsprofil kennt - die Information
> ist nicht explizit in der METS-Datei verfügbar.
Okay. Es ist richtig, daß man an dieser Stelle das AP kennen muß. Aber das ist eben auch der Sinn von APs: spezifische Vereinbarungen zu dokumentieren.
> Insofern würde ich mich Frau Rühle anschließen: Variante 2 gefällt mir am
> besten, ich könnte aber auch mit Variante 3 leben (wobei bei Variante 3 sich
> letztlich die Praxis durchsetzen wird, die DFG-Viewer & Co. unterstützen -
> letztlich läge die Entscheidung also immer noch bei uns).
Ich halte beide Varianten - wie beschrieben - nach wie vor für nicht formal herleitbar. Und das hat mit gefallen oder nicht nichts zu tun!
Beste Grüße,
Kay Heiligenhaus
