Liebe Kolleginnen und Kollegen,
wie vergangene Woche bereits angekündigt, verschicke ich hiermit meinen Vorschlag für das künftige MODS-Anwendungsprofil für den DFG-Viewer und zvdd. Wie Sie bereits an der Versionsnummer erkennen können, unterscheidet es sich nur marginal von dem bereits im vergangenen Jahr auf dieser Liste diskutierten und verabschiedeten zvdd-Profil in Version 2.0. Welche Änderungen im Detail vorgenommen wurden, führe ich weiter unten aus. Die Änderungen betreffen ausschließlich den Verpflichtungsgrad einiger Felder im Kontext des DFG-Viewers sowie Formulierungen in den Erläuterungstexten, beeinflussen also nicht die Implementierung. Der Verpflichtungsgrad wurde an keiner Stelle verschärft, sondern lediglich gegenüber den ZVDD-Anforderungen gelockert, um dem Grundsatz niedriger Einstiegshürden für den DFG-Viewer gerecht zu werden. Die abweichenden Anforderungen von ZVDD sind aber natürlich weiterhin dokumentiert. Insofern hoffe ich, dass die Änderungen weitestgehend unstrittig sind.
Bitte schauen Sie sich das Profil an und geben Sie mir eine kurze Rückmeldung, wenn Sie Kommentare oder Verbesserungsvorschläge haben.
Die Änderungen im Einzelnen:
Generell wurde an mehreren Stellen die Formulierung überarbeitet. Dabei habe ich versucht, weitgehend auf Abkürzungen und Einschübe in Klammern zu verzichten. Darüber hinaus habe ich mich um eine einheitliche Formatierung bemüht, insbesondere was Element- und Attributnamen sowie Feldwerte betrifft. Teilweise befinden sich derzeit noch Seitenumbrüche etwas unglücklich inmitten von Anwendungsbeispielen oder Tabellen. Das würde ich für die finale Fassung des Profils natürlich noch korrigieren.
Abschnitt 1:
- Erwähnung der DDB als ein gewichtiger Aggregator, der ebenfalls das vorliegende Profil unterstützt.
- Berücksichtigung des künftigen METS/TEI-Anwendungsprofils für digitalisierte Handschriften.
- Hinweise auf die Anhänge A bis E wurden entfernt, da die Anhänge meines Wissens nicht existieren (zumindest konnte ich sie auf den ZVDD-Seiten nicht finden). Dafür wurde der Hinweis auf den METS/MODS-Validator und die Beispieldokumente auf den DFG-Viewer-Seiten ergänzt.
Abschnitt 2.1:
- Tippfehler in einem Anwendungsbeispiel korrigiert ("mods:subTitel" statt "mods:subTitle").
Abschnitt 2.2:
- Tippfehler in einem Attributwert für mods:namePart@type korrigiert ("termsOfAdress" statt "termsOfAddress").
- DFG-Viewer-spezifische Erläuterung zu mods:displayForm hinzugefügt.
- Tippfehler in einem Anwendungsbeispiel korrigiert ("rmods:role" statt "mods:role").
Abschnitt 2.5:
- Verpflichtungsgrad von mods:language geändert in "optional" (war: konditional, d.h. verpflichtend für Textressourcen).
Abschnitt 2.6:
- Verpflichtungsgrad von mods:physicalDescription geändert in "optional" (war: verpflichtend).
- Wert "digitized other analog" aus der Werteliste für mods:digitalOrigin mangels eindeutiger Abgrenzung zu "reformatted digital" entfernt. Beides wird laut Beschreibung verwendet, wenn es sich um eine nicht näher bezeichnete analoge Vorlage handelt. Ggf. wäre hier stattdessen die Beschreibung zu schärfen, wobei mir auch nicht klar ist, worin der Unterschied zwischen beiden Werten bestehen soll.
Abschnitt 2.11:
- Tippfehler in zwei Anwendungsbeispielen korrigiert (fehlender Namespace in schließenden Elementen).
Abschnitt 2.12:
- Liste der möglichen Identifier-Typen um "vd16", "vd17" und "vd18" ergänzt, da diese vom DFG-Viewer ausgewertet werden.
- Tippfehler in den Anwendungsbeispielen korrigiert (fehlender Namespace).
Abschnitt 2.13:
- METS-Namespace in den Beschreibungstexten ergänzt.
- URL in einem Anwendungsbeispiel gekürzt, um einen Zeilenumbruch zu vermeiden.
Abschnitt 2.15:
- Als Abschnitt 3.2 ans Ende des Profils gestellt, da optionale und proprietäre ZVDD-Elemente beschrieben werden ("zvdd:zvddWrap" und "zvdd:titleWord").
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Referatsleiter 2.1 - Digitale Bibliothek
Abteilung 2 - Informationstechnologie
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/
Liebe Kolleginnen und Kollegen,
falls Sie nicht ohnehin auch die Mailingliste des MODS Editorial Committee verfolgen, untenstehende Mitteilung für Sie zur Kenntnis.
Grundsätzlich begrüße ich die angekündigten Änderungen, allerdings ergeben sich daraus einige Auswirkungen auf das Anwendungsprofil des DFG-Viewers. So soll etwa das Element <edition> aus <originInfo> entfernt und zum Toplevel-Element "befördert" werden. Anhand dieses Elements (mit dem kontrollierten Wert "[Electronic ed.]") unterscheiden wir allerdings derzeit die Angaben zur analogen Vorlage von denen des Digitalisats. Zwar könnten wir denselben Effekt auch durch die dann mögliche Typisierung des <originInfo>- bzw. <providerEvent>-Elements erreichen, allerdings setzt das voraus, dass entsprechende Rollen bzw. Eventtypen dort erlaubt sind. In MODS 3.5 ist die Verwendung der MARC-Relator-Liste zur Festlegung der Rolle vorgesehen, was ich für sehr geschickt halte. Wie es in späteren Versionen (wenn die Rolle zum eventType wird) aussieht, weiß ich nicht.
Die übrigen Änderungsvorschläge haben zwar auch Einfluss auf das Anwendungsprofil, sind aber insofern unkritisch, als sie sich durch einfaches Mapping aus der bisherigen Implementierung herleiten lassen.
Bitte beachten Sie: Es ist derzeit nicht geplant, das Anwendungsprofil des DFG-Viewers auf MODS 3.5 oder eine spätere Version abzustimmen. Insofern sind die oben angestellten Überlegungen derzeit rein hypothetisch und sollen lediglich für den Fall vorsorgen, dass eine solche Umstellung auf MODS 3.5+ möglicherweise eines Tages erfolgen wird (wovon ich ausgehe).
Viele Grüße und einen guten Start ins Jahr!
Sebastian Meyer
--
Sebastian Meyer
Referatsleiter 2.1 - Digitale Bibliothek
Abteilung 2 - Informationstechnologie
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: Metadata Object Description Schema List
> [mailto:MODS@LISTSERV.LOC.GOV] Im Auftrag von Rebecca Guenther
> Gesendet: Donnerstag, 3. Januar 2013 20:12
> An: MODS(a)LISTSERV.LOC.GOV
> Betreff: possible future changes to originInfo
>
> The MODS Editorial Committee is considering ways to change or enhance
> MODS to fix some of the problems with consistency that have been identified
> and to make it more compatible with the direction of the Bibliographic
> Framework Transition Initiative (BIBFRAME) and RDA. One area of difficulty in
> the current and previous versions of MODS has been the originInfo element
> and its subelements. Problems that have been identified include the following:
>
> 1. Being able to specify a function within publisher.
> In MODS the <publisher> element is used in a general way to incorporate
> distributor, producer, publisher and manufacturer. The specific function is
> useful and these are separate elements in RDA. Being able to specify a function
> could remedy this situation.
> Note that the MODS-EC has already approved a change in MODS 3.5 to define
> a role attribute for originInfo to address the latter issue in the short term.
>
> 2. Name within publisher.
> Allow for the ability to reuse the mods:name definition within originInfo for the
> name of a publisher/distributor/producer, etc. This would allow for a controlled
> form of name or URI with additional attributes and subelements, such as role,
> nameType, etc.
>
> 3. Place.
> Places as subjects go under <subject><geographic>, but places under originInfo
> go under <place> and there is no way to indicate a controlled term. There is
> also the ability to provide <hierarchicalGeographic> under subject but not
> under originInfo/place. Here there is both the inconsistency and the inability to
> use a hierarchical place name that is related to the resource in another way
> than as subject.
>
> 4. originInfo as a container for unrelated elements.
> Now originInfo includes place/publisher/dates, which need to be bound
> together, but it also includes some random elements that can stand alone.
> These include: edition, issuance and frequency. This is particularly troublesome
> when there are multiple instances of originInfo: do you repeat all the stand-
> alone elements with each originInfo or just one (and which one)?
>
> 5. Dates.
> There are a number of date types, e.g. dateIssued, dateCreated, dateValid,
> dateOther (with uncontrolled type attribute.), etc. These need to be
> accommodated.
>
> The MODS Editorial Committee has been considering ways to remedy these
> problems if it were not bound by the restriction of keeping MODS backwards
> compatible with previous versions. The following details possible solutions:
>
> 1. OriginInfo as a container for various types of events related to the resource.
> Replace originInfo with an element <providerEvent> to encompass the various
> functions of making the resource available, i.e. publication, distribution,
> production and manufacture. An eventType attribute would be defined to
> specify the type of event (which would replace the new role attribute being
> defined in v. 3.5).
>
> 2. Provider with same definition as mods:name.
> A subelement, "<provider>" under providerEvent would carry the name of the
> publisher/distributor/producer/manufacturer and would use the same
> definition as mods:name.
> providerEvent is repeated for different functions with the appropriate
> eventType.
>
> 3. Place
> Place would be a subelement within providerEvent. Geographic under subject is
> another area that needs to be cleaned up for various reasons (for instance,
> should hierarchicalGeographic really be a separate element or should it just be
> a different form of geographic and use the same element?). At a later date it
> will be considered whether to 1) change place under providerEvent to
> geographic, or 2) change geographic under subject to place, or 3) to keep place
> in providerEvent, but taking the same definition as <geographic> (i.e. that it
> can be a controlled form of name).
>
> 4. Unrelated elements. Take edition, issuance and frequency out of
> originInfo/providerEvent as separate top level elements.
>
> 5. Dates.
> Define <date> under providerEvent; the type of date is implicit in the eventType
> used. That is, if the eventType is "published" (or "issued"-- these have been
> considered synonymous) the date is publication, the provider is publisher, the
> place is place of publication. There are some stray dates that aren't associated
> with places and providers generally (i.e. dateValid). For those not related to an
> event, <date> can be defined at the top level and used with the type attribute
> (uncontrolled list). This construct will also be used for other types of dates that
> aren't associated with a provider event.
>
> To accommodate the need for both transcription (how the resource presents
> itself) and access, there could be a subelement providerStatement under
> providerEvent for the transcribed form of the whole statement, i.e. place,
> provider, date.
>
> The MODS Editorial Committee would like to hear comments on these
> proposed changes. They would be in a future major new version of MODS.
>
> Rebecca
> Chair, MODS Editorial Committee
> Library of Congress
