DV-Technik

dv-technik@dfg-viewer.de

329 discussions

by Meyer, Sebastian

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>

11 years, 6 months

WG: Arbeitstreffen Zeitungsdigitalisierung

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, darf ich Sie an meine untenstehende Mail von vergangener Woche erinnern? Bitte tragen Sie bei Interesse bis Freitag Ihre Terminwünsche ein. 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/ Von: Meyer, Sebastian Gesendet: Dienstag, 21. Mai 2013 16:43 An: 'technik(a)dfg-viewer.de' Cc: Bigga, Alexander Betreff: Arbeitstreffen Zeitungsdigitalisierung Liebe Kolleginnen und Kollegen, im Rahmen der laufenden DFG-Pilotprojekte zur Zeitungsdigitalisierung soll im Juli ein Technik-Workshop stattfinden, auf dem neben den notwendigen ZDB-Anpassungen auch die Weiterentwicklung des DFG-Viewers für Zeitungen ein Thema sein soll. Anknüpfend an die Vorüberlegungen des Techniker-Workshops Ende 2011 (Protokoll anbei) und auf Basis des Projektplans der laufenden DFG-Förderung zur Weiterentwicklung des DFG-Viewers sollen die noch nicht festgelegten Formatdetails definiert und die nächsten Schritte besprochen werden. Zur Terminfindung möchte ich alle Interessenten bitten, sich bis spätestens Ende Mai in die folgende Doodle-Umfrage einzutragen: http://doodle.com/ukp46im2czfc5y5f 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/

11 years, 7 months

Arbeitstreffen Zeitungsdigitalisierung

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, im Rahmen der laufenden DFG-Pilotprojekte zur Zeitungsdigitalisierung soll im Juli ein Technik-Workshop stattfinden, auf dem neben den notwendigen ZDB-Anpassungen auch die Weiterentwicklung des DFG-Viewers für Zeitungen ein Thema sein soll. Anknüpfend an die Vorüberlegungen des Techniker-Workshops Ende 2011 (Protokoll anbei) und auf Basis des Projektplans der laufenden DFG-Förderung zur Weiterentwicklung des DFG-Viewers sollen die noch nicht festgelegten Formatdetails definiert und die nächsten Schritte besprochen werden. Zur Terminfindung möchte ich alle Interessenten bitten, sich bis spätestens Ende Mai in die folgende Doodle-Umfrage einzutragen: http://doodle.com/ukp46im2czfc5y5f 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/

11 years, 7 months

MODS-Anwendungsprofil 2.0.1 - Bitte um Review und Kommentare

by Meyer, Sebastian

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/

11 years, 8 months

Kritischer Fehler im DFG-Viewer-Validator

by wp1029278-adrian

Hallo Mailingliste, ich habe eine METS-Datei erstellt und möchte Sie über den DFG-Vierwer nun validieren lassen. Der Validator gibt folgenden Fehler aus: Kritische Fehler Zu der ermittelten DMDID konnte kein <dmdSec>-Knoten gefunden werden In meiner METS-Datei ist dieses Element aber vorhanden: ... <mets:dmdSec ID="md00001">. <mdWrap MDTYPE="MODS"><mods:mods xmlns:mods="http://www.loc.gov/standards/mods/"/></mdWrap>. <mdWrap MDTYPE="EAD"><ead:ead xmlns:ead="http://www.loc.gov/ead/ead.xsd"/></mdWrap>. <mdRef>http://www.lwl.org/325dig-download/Lesesaal-Digitalisate/C_Adelsarchive/Dül… </mdRef></mets:dmdSec><mets:amdSec xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="amd00001"> <mets:rightsMD ID="rights00001"> ... Warum wird <mets:dmdSec ID="md00001"> nicht vom Validator erkannt? Bin für hinweise wo der Fehler liegen könnte sehr dankebar. Viele Grüße Adrian Heinemann

11 years, 9 months

Re: [DFG-Viewer] Kritischer Fehler im DFG-Viewer-Validator

by Philipp Vanscheidt

Sehr geehrter Herr Heinemann, möglicherweise findet sich im Dokument ein DMDID-Attribut mit einem Wert, der ins Leere weist. Zum Beispiel könnte dies in einem mets:div der logical Structure der Fall sein. Mit freundlichem Gruß Philipp Vanscheidt -- Universität Trier Center for Digital Humanities Universitätsring 15, 54286 Trier Tel.: (0651) 201-3849 pvanscheidt(a)uni-trier.de

11 years, 9 months

Technische/Source code doku zum DFG-Viewer?

by Simon Rainer

Liebe DFG-Viewer-Liste! Eine technische Frage zum DFG-Viewer: gibt es technische Dokumentation online (Wiki etc.), in der grob die Struktur des Codes umrissen wird, sowie Instruktionen zur Installation? Ich konnte es ehrlichgesagt auf der Projekt-Website nicht finden :-( Hintergrund meiner Frage ist, dass ich auf der Suche nach einer geeigneten Open Source Dokumenten Viewer-Lösung bin, in die sich ein Bildannotationssystem integrieren lässt. (http://annotorious.github.com - Disclaimer: ich bin der Maintainer des Systems). Wäre über jede Info dankbar! Herzlichen Dank, Rainer Simon

11 years, 10 months

DFG-Viewer für Handschriften

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, im Rahmen der Weiterentwicklung des DFG-Viewers für Handschriften fand im Dezember in Leipzig ein Treffen mit Vertretern der deutschen Handschriftenzentren statt. Zur Ihrer Information finden Sie anbei das Ergebnisprotokoll dieser Sitzung, das außerdem bereits einen kleinen Ausblick auf das kommende Anwendungsprofil für METS/TEI bietet. Besonders möchte ich Sie auf den dritten Punkt im Abschnitt "METS" aufmerksam machen. Hier geht es darum, im DFG-Viewer über ein grafisches Element die Lizensierung des angezeigten Digitalisats (Metadaten und Bildderivate) kenntlich zu machen. Es ist vorgesehen, für alle gängigen Creative Commons-Lizenzen jeweils die einschlägigen Symbole anzuzeigen. Der zusätzliche Wert "reserved" kennzeichnet jedwede andere Form der Lizensierung, die nicht mit einem individuellen Symbol kenntlich gemacht wird (sondern mit einem allgemeinen "Copyright"-Symbol). D.h. es ist explizit nicht gemeint, dass nur die angegebenen CC-Lizenzen zulässig sind, sondern lediglich, dass nur diese durch individuelle Symbole angezeigt werden. Auch andere Lizenzen sollen natürlich erlaubt sein, bekommen aufgrund ihrer unübersehbaren Fülle jedoch kein individuelles Symbol. Den CC-Lizenzen soll hier der Vorzug gegeben werden, da diese insbesondere im Kontext der DDB und Europeana (die nur CC0-lizensiertes Material akzeptiert) zunehmend an Bedeutung gewinnen. Die Vertreter der Handschriftenzentren waren sich jedoch einig, dass hier keine medientyp-spezifische Lösung angestrebt werden sollte, weshalb ich diesen Punkt gerne hier zur Diskussion stellen möchte. Meines Erachtens taugt der Vorschlag ebenso gut für Drucke und Zeitschriften, aber da interessiert mich auch Ihre fachkundigere Meinung. Wie sehen Sie es? Geben Sie derzeit überhaupt explizit Nutzungsbedingungen in den Metadaten an? Wenn ja, welche Lizenzen verwenden Sie? 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/

11 years, 11 months

Re: [DFG-Viewer] DFG-Viewer für Handschriften

by Philipp Vanscheidt

Lieber Sebastian Meyer, liebe Liste, eine etwas dumme Frage vielleicht: Wo kann ich denn den Anhang finden? Möglicherweise schneidet das Trierer Webmail etwas ab, aber ich finde auch im Archiv der Liste leider nichts Passendes. Herzlich grüßt Philipp Vanscheidt -- Universität Trier Center for Digital Humanities Universitätsring 15, 54286 Trier Tel.: (0651) 201-3849 pvanscheidt(a)uni-trier.de Zitat von dv-technik-request(a)dfg-viewer.de: > Um e-Mails an die Liste DV-Technik zu schicken, nutzen Sie bitte die > Adresse > > dv-technik(a)dfg-viewer.de > > Um sich via Web von der Liste zu entfernen oder draufzusetzen: > > https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/dv-technik > > oder, via Email, schicken Sie eine Email mit dem Wort 'help' in > Subject/Betreff oder im Text an > > dv-technik-request(a)dfg-viewer.de > > Sie koennen den Listenverwalter dieser Liste unter der Adresse > > dv-technik-owner(a)dfg-viewer.de > > erreichen > > Wenn Sie antworten, bitte editieren Sie die Subject/Betreff auf einen > sinnvollen Inhalt der spezifischer ist als "Re: Contents of DV-Technik > digest..." > > > Meldungen des Tages: > > 1. DFG-Viewer für Handschriften (Meyer, Sebastian) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 4 Feb 2013 17:31:05 +0100 > From: "Meyer, Sebastian" <Sebastian.Meyer(a)slub-dresden.de> > Subject: [DFG-Viewer] DFG-Viewer für Handschriften > To: "'technik(a)dfg-viewer.de'" <dv-technik(a)dfg-viewer.de> > Message-ID: > <EE198826B5CB824FAD655FAF95665168739859D39A(a)SLUBMAIL.slub-dresden.de> > Content-Type: text/plain; charset="utf-8" > > Liebe Kolleginnen und Kollegen, > > im Rahmen der Weiterentwicklung des DFG-Viewers für Handschriften > fand im Dezember in Leipzig ein Treffen mit Vertretern der deutschen > Handschriftenzentren statt. Zur Ihrer Information finden Sie anbei > das Ergebnisprotokoll dieser Sitzung, das außerdem bereits einen > kleinen Ausblick auf das kommende Anwendungsprofil für METS/TEI > bietet. > > Besonders möchte ich Sie auf den dritten Punkt im Abschnitt "METS" > aufmerksam machen. Hier geht es darum, im DFG-Viewer über ein > grafisches Element die Lizensierung des angezeigten Digitalisats > (Metadaten und Bildderivate) kenntlich zu machen. Es ist vorgesehen, > für alle gängigen Creative Commons-Lizenzen jeweils die > einschlägigen Symbole anzuzeigen. Der zusätzliche Wert "reserved" > kennzeichnet jedwede andere Form der Lizensierung, die nicht mit > einem individuellen Symbol kenntlich gemacht wird (sondern mit einem > allgemeinen "Copyright"-Symbol). > D.h. es ist explizit nicht gemeint, dass nur die angegebenen > CC-Lizenzen zulässig sind, sondern lediglich, dass nur diese durch > individuelle Symbole angezeigt werden. Auch andere Lizenzen sollen > natürlich erlaubt sein, bekommen aufgrund ihrer unübersehbaren Fülle > jedoch kein individuelles Symbol. Den CC-Lizenzen soll hier der > Vorzug gegeben werden, da diese insbesondere im Kontext der DDB und > Europeana (die nur CC0-lizensiertes Material akzeptiert) zunehmend > an Bedeutung gewinnen. > Die Vertreter der Handschriftenzentren waren sich jedoch einig, dass > hier keine medientyp-spezifische Lösung angestrebt werden sollte, > weshalb ich diesen Punkt gerne hier zur Diskussion stellen möchte. > Meines Erachtens taugt der Vorschlag ebenso gut für Drucke und > Zeitschriften, aber da interessiert mich auch Ihre fachkundigere > Meinung. Wie sehen Sie es? Geben Sie derzeit überhaupt explizit > Nutzungsbedingungen in den Metadaten an? Wenn ja, welche Lizenzen > verwenden Sie? > > 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/ > > -------------- n?ster Teil -------------- > Ein Dateianhang mit Binärdaten wurde abgetrennt... > Dateiname : winmail.dat > Dateityp : application/ms-tnef > Dateigröße : 46003 bytes > Beschreibung: nicht verfügbar > URL : > http://maillist.slub-dresden.de/pipermail/dv-technik/attachments/20130204/a… > > Ende DV-Technik Nachrichtensammlung, Band 101, Eintrag 1 > ******************************************************** >

11 years, 11 months

WG: possible future changes to originInfo

by Meyer, Sebastian

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

12 years

← Newer
1
...
9
10
11
12
13
14
15
...
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