Liebe Kollegen,
da auf der Liste während meines Urlaubs wieder rege Diskussionen liefen, möchte ich gleich etwas anschließen:
Wir hatten ja seinerzeit die Liste mit empfohlenen und vom DFG-Viewer unterstützten Strukturbegriffen diskutiert (http://dfg-viewer.de/strukturdatenset/). Bewusst enthält diese Liste auch Dokumenttypen der oberen Ebene (monograph, multivolume_work, volume, periodical, manuscript ...). In anderen Zusammenhängen ist mir nun aufgefallen, dass natürlich darüber hinaus noch weitere Dokumenttypen auch im größeren Stile verwendet werden (z.B. durch Intrandakunden), die bisher keinen Eingang in diese Liste gefunden haben. Offenbar ist der DFG-Viewer hier sehr tolerant, was ja zu begrüßen ist. Im Sinne einer standardisierten Begrifflichkeit wäre es aber aus meiner Sicht sinnvoll, wenn wir hier und jetzt mal wieder Begriffe einsammeln würden, damit gleiche Strukturen auch von verschiedenen Bibliotheken etc. gleich benannt werden. Kurz und gut, ich würde dazu gern anregen, die verwendeten Dokumenttypen zu melden, um sie anschließend in die Liste zu integrieren.
Aufgefallen sind mir hier in eben dieser Schreibung:
Series
SeriesVolume
PeriodicalVolume
Newspaper
NewspaperVolume
Bei uns definiert sind derzeit zusätzlich (ob es wirklich schon Daten dazu gibt, weiss ich nicht):
multivolume_manuscript
volume_manuscript
collection - für Nachlass
item - für Dokument eines Nachlasses
Vielleicht finden wir ja so wieder zu einer gewissen Einheit ...
Mit besten Grüßen aus Berlin
Maria Federbusch
Wissenschaftliche Referentin
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz
Abteilung Historische Drucke
Unter den Linden 8
D-10117 Berlin
Tel.: ++49-(0)30-266-43 66 01
E-Mail: maria.federbusch(a)sbb.spk-berlin.de<mailto:maria.federbusch@sbb.spk-berlin.de>
http://staatsbibliothek-berlin.de/die-staatsbibliothek/abteilungen/historis…
Lieber Herr Staecker,
"reproduction" finde ich nun wieder zu ungenau, weil das auch z.B. ein Faksimile sein könnte. Wie wäre es mit "reformatting" in Analogie zur Angabe "reformatted digital" in <physicalDescription><digitalOrigin>?
(Wobei ich immer noch "digitisation" für die treffendere Bezeichnung halte.)
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
> Referatsleiter Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden
Zellescher Weg 18 // 01069 Dresden
Postanschrift: 01054 Dresden
TEL: +49 351 4677206 // FAX: +49 351 4677711
E-MAIL: sebastian.meyer(a)slub-dresden.de
http://www.slub-dresden.de
-------- Ursprüngliche Nachricht --------
Von: Thomas Staecker <staecker(a)hab.de>
Datum:
An: dv-technik(a)dfg-viewer.de
Betreff: Re: [DFG-Viewer] WG: MODS version 3.5 released
Lieber Herr Meyer,
wie wäre es mit "reproduction"? Das ist doch gemeint, oder? Digitisation
ist mehr als reproduction.
Viele Grüße,
Ihr
Th. Stäcker
Am 10.07.2013 18:16, schrieb Meyer, Sebastian:
> Lieber Herr Staecker,
>
> die LoC empfiehlt die Werte "production", "publication", "distribution" und "manufacture", erlaubt aber auch beliebige weitere Werte. Mein Vorschlag wäre, für die Beschreibung der Vorlage "production" oder "publication" zu verwenden und für die digitale Ausgabe "digitisation".
>
> Viele Grüße
> Sebastian Meyer
>
--
---------------------------------------------
Dr. Thomas Stäcker
Stellv. Direktor
Herzog August Bibliothek Wolfenbüttel
Tel. +49+5331/808-303
Email staecker(a)hab.de
Liebe Kolleginnen und Kollegen,
untenstehende Information zu Ihrer Kenntnis. Insbesondere das Attribut @eventType für das originInfo-Element finde ich im Kontext des DFG-Viewers sehr interessant. Damit könnte die etwas unschöne Konstruktion mit edition=[Electronic ed.] zur Unterscheidung von Angaben zum Erscheinen der Vorlage und der Digitalisierung expliziter und damit verständlicher kodiert werden.
Was meinen Sie? Sollten wir darüber nachdenken, diese Möglichkeit zumindest alternativ anzubieten?
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
> Referatsleiter Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden
Zellescher Weg 18 // 01069 Dresden
Postanschrift: 01054 Dresden
TEL: +49 351 4677206 // FAX: +49 351 4677711
E-MAIL: sebastian.meyer(a)slub-dresden.de
http://www.slub-dresden.de
-------- Ursprüngliche Nachricht --------
Von: Rebecca Guenther <rguenther52(a)GMAIL.COM>
Datum:
An: MODS(a)LISTSERV.LOC.GOV
Betreff: MODS version 3.5 released
The MOD Editorial Committee and the Library of Congress is pleased to announce that a new incremental version of MODS, version 3.5, is now available on the MODS website at: http://www.loc.gov/standards/mods/v3/mods-3-5.xsd.
This revision is backwards compatible to version 3.4 and therefore only includes changes that do not result in invalidating existing MODS records. A new major revision of MODS to make more substantive changes is currently under discussion. MODS implementers may want to use this revised version to take advantage of its new features. The changes are as follows:
* Added attribute @unit in mods:extent. This change makes the extent element more granular by separating units from extent.
* Added rfc5646 as value for <language><languageTerm> . Enumerated values reflect earlier standards; RFC5646 has superceded RFC4646.
* Added @altFormat and @contentType attributes to <titleInfo>, <abstract>, <tableOfContents> and <accessCondition>. This change allows for embedding HTML in MODS, linking with @altRepGrp, and indicating the format of the alternative encoding.
* Added @eventType under <originInfo> to indicate production, publication, distribution, manufacture. This attribute allows for indicating what type of event the statement of originInfo relates to, e.g. production, publication, distribution, manufacture, or some other event.
* Added @typeURI on <identifier>, <note>, and <physicalDescripton>/<note>. This change allows for indicating that a type is in the form of a URI.
* Added @generator on <classification>. The value of this attribute indicates that the classification number was automatically generated and, if appropriate, how.
* Added<etal> element, a subelement of <name> . The <etal> subelement is added to the list of <name> subelements to indicate that there are one or more names that, for whatever reason, cannot be explicitily included in another name element.
* Added @otherType to <titleInfo> element. This allows for designating another type value for titleInfo that is not on the list of types enumerated in the schema.
For further information and examples see:
http://www.loc.gov/standards/mods/changes-3-5.html. Revised versions of the MODS User Guidelines, the MARC to MODS mapping, and the XSLT conversion that incorporate the 3.5 changes will be available on the MODS web site soon.
Please direct any comments or questions on the MODS 3.5 Schema, or MODS/MADS developments in general, to the MODS Listserv <http://listserv.loc.gov/listarch/mods.html>.
Rebecca
Rebecca Squire Guenther
Chair, MODS Editorial Committee
Library of Congress
Network Development & MARC Standards Office
rguenther52(a)gmail.com<mailto:rguenther52@gmail.com>
rgue(a)loc.gov<mailto:rgue@loc.gov>
