Lieber Herr Maus, Sie haben recht, dass es in METS bereits eine Möglichkeit gibt, weitere Rechteinformationen zu hinterlegen. Auch wir haben in einer Variante überlegt, <amdSec> als wiederholbar zu deklarieren und dort weitere Lizenzinformationen zu hinterlegen. Wenn ich Ihren Vorschlag richtig verstehe, müssten u.a. alle <dmdSec> mit einer weiteren <amdSec> verknüpft werden, um dessen Gültigkeitsbereich für "Metadaten" festzulegen. Das würde aber die bisherige Definition im METS-Anwendungsprofil, nur in der logischen <structMap> das <div> des vorliegenden Werkes mit der <amdSec> zu verknüpfen, in Frage stellen. Um Lizenzinformationen für das Digitalisat auszudrücken, müssten dann z. B. alle <fileGrp> Elemente mit der "alten" <amdSec> verlinkt werden. Die beiden <structMap> Elemente würde ich im Bereich "Metadaten" sehen und daher mit "Metadaten <amdSec>" verlinken. Diese Variante ist relativ komplex und wäre nicht abwärtskompatibel. Da das DFG-Viewer Format eine Entwicklung für unser METS-Anwendungsprofil ist, beeinflusst die Erweiterung von <dv:license> dessen Interoperabilität nicht. Das neue Attribut type wird optional und ist damit abwärtskompatibel. Wir finden diese Lösung deshalb pragmatischer. Viele Grüße Timo Schleier Am 22.05.2015 um 07:59 schrieb David Maus: -- Timo Schleier Gruppe Metadaten und Datenkonversion Georg-August-Universität Göttingen Niedersächsische Staats- und Universitätsbibliothek Göttingen D-37070 Göttingen Papendiek 14 (Historisches Gebäude, Raum 1.603) +49 551 39-10905 (Tel.) +49 551 39-3468 (Fax) timo.schleier(a)sub.uni-goettingen.de http://www.sub.uni-goettingen.de http://www.eromm.org

Lieber Herr Maus, Das ist richtig, wiederholbare <amdSec> erlauben darüber hinaus noch viel feinere Angaben, sind dafür aber auch komplexer. Wir haben hatten uns für die einfache Variante entschieden. Ja, aber das Parsen und die Darstellung der Angaben wird schwieriger, wenn weitere <amdSec> erlaubt sind und diese für Teile des digitalen Objekts andere Rechteinformationen beinhalten. Über die Möglichkeit, den <metsHdr> mit einer <amdSec> zu verknüpfen hatten wir auch nachgedacht. Aus unserer Sicht wäre dies ebenfalls eine gute Lösung. Damit müsste die <amdSec> im METS-Anwendungsprofil wiederholbar werden. Darüber hinaus wäre es sinnvoll entsprechende Vorgaben zum <metsHdr> zu definieren, da es bisher im Anwendungsprofil dazu keine Angaben gibt. Viele Grüße Timo Schleier Am 22.05.2015 um 13:54 schrieb David Maus: > Lieber Herr Schleier, > >> Sie haben recht, dass es in METS bereits eine Möglichkeit gibt, >> weitere Rechteinformationen zu hinterlegen.Auch wir haben in einer >> Variante überlegt, <amdSec> als wiederholbar zu deklarieren und dort >> weitere Lizenzinformationen zu hinterlegen. > >> Wenn ich Ihren Vorschlag richtig verstehe, müssten u.a. alle >> <dmdSec> mit einer weiteren <amdSec> verknüpft werden, um dessen >> Gültigkeitsbereich für "Metadaten" festzulegen. > Ja. > >> Das würde aber die bisherige Definition im METS-Anwendungsprofil, >> nur in der logischen <structMap> das <div> des vorliegenden Werkes >> mit der <amdSec> zu verknüpfen, in Frage stellen. > >> Um Lizenzinformationen für das Digitalisat auszudrücken, müssten >> dann z. B. alle <fileGrp> Elemente mit der "alten" <amdSec> verlinkt >> werden. > Ja und nein. Kommt darauf an, worauf sich die "alte" <amdSec> bezieht. > >> Die beiden <structMap> Elemente würde ich im Bereich "Metadaten" >> sehen und daher mit "Metadaten <amdSec>" verlinken. Diese Variante >> ist relativ komplex und wäre nicht abwärtskompatibel. > >> Da das DFG-Viewer Format eine Entwicklung für unser >> METS-Anwendungsprofil ist, beeinflusst die Erweiterung von >> <dv:license> dessen Interoperabilität nicht. > Es ist nicht die Erweiterung von <dv:license>, die die Interop negativ > beeinflusst. Es ist die Kodierung essentieller Informationen auf eine > Weise, für die in METS ein anderes Verfahren vorgesehen ist. > > Wir möchten METS produzieren, dass auch andere mit möglichst wenig > Aufwand nutzen können. Und speziell Informationen über Nutzungsrechte > sollten so einfach und deutlich wie möglich angegeben werden. > >> Das neue Attribut type wird optional und ist damit >> abwärtskompatibel. Wir finden diese Lösung deshalb pragmatischer. > Ich denke, dass der Schein trügt. Wenn Herr Meyer andeutet, dass die > Heterogenität der Lizenzen nach oben hin offen ist (für OCR, ...), > dann heisst das, dass die gesamte Komplexität eines jetzigen und > zukünftigen digitalen Objekts in ein einziges Attribut eines > Metadatenformats gesteckt wird. > > Mit besten Grüßen, > -- David Maus > > On Fri, 22 May 2015 11:57:03 +0200, > Timo Schleier wrote: >> Lieber Herr Maus, >> >> Sie haben recht, dass es in METS bereits eine Möglichkeit gibt, >> weitere Rechteinformationen zu hinterlegen. >> Auch wir haben in einer Variante überlegt, <amdSec> als wiederholbar >> zu deklarieren und dort weitere Lizenzinformationen zu hinterlegen. >> >> Wenn ich Ihren Vorschlag richtig verstehe, müssten u.a. alle <dmdSec> >> mit einer weiteren <amdSec> verknüpft werden, um dessen >> Gültigkeitsbereich für "Metadaten" festzulegen. Das würde aber die >> bisherige Definition im METS-Anwendungsprofil, nur in der logischen >> <structMap> das <div> des vorliegenden Werkes mit der <amdSec> zu >> verknüpfen, in Frage stellen. Um Lizenzinformationen für das >> Digitalisat auszudrücken, müssten dann z. B. alle <fileGrp> Elemente >> mit der "alten" <amdSec> verlinkt werden. Die beiden <structMap> >> Elemente würde ich im Bereich "Metadaten" sehen und daher mit >> "Metadaten <amdSec>" verlinken. Diese Variante ist relativ komplex und >> wäre nicht abwärtskompatibel. >> >> Da das DFG-Viewer Format eine Entwicklung für unser >> METS-Anwendungsprofil ist, beeinflusst die Erweiterung von >> <dv:license> dessen Interoperabilität nicht. Das neue Attribut type >> wird optional und ist damit abwärtskompatibel. Wir finden diese Lösung >> deshalb pragmatischer. >> >> Viele Grüße >> Timo Schleier >> >> >> Am 22.05.2015 um 07:59 schrieb David Maus: >>> Liebe Kolleginnen und Kollegen, >>> >>> Nach meinem Verständnis wird der Anwendungsfall, dass unterschiedliche >>> Lizenzen für unterschiedliche Teile des Dokuments gelten sollen, in >>> METS durch die Verwendung des @ADMID-Attributs abgedeckt (vgl. METS >>> Primer [PRIMER]). >>> >>> Dieses Attribut kann in einer <dmdSec>, einer <fileGrp> und einem >>> <div> verwendet werden. >>> >>> Die Vorgeschlagene Variante, diesen Sachverhalt über eine @type des >>> <dv:license> auszudrücken ist daher nicht nötig. >>> >>> Den Gültigkeitsbereich der Lizenz über ein @type des <dv:license> >>> auszudrücken wirft auch Problem der Interoperabilität und der >>> Nachnutzung des <dv:rights> auf. >>> >>> Interop: Die Verwendung von @AMDID ist von METS vorgesehen, die >>> Semantik von <dv:license>/@type ist eine rein lokale Konvention. >>> >>> Nachnutzung: Das <dv:license>-Element wird durch das @type-Attribut >>> ohne Notwendigkeit an die Nutzung im Kontext von METS gebunden. >>> >>> Mit besten Grüßen, >>> -- David >>> >>> [PRIMER] : http://www.loc.gov/standards/mets/METSPrimerRevised.pdf >>> >>> On Thu, 21 May 2015 17:20:30 +0200, >>> Meyer, Sebastian wrote: >>>> Liebe Kolleginnen und Kollegen, >>>> >>>> Ich möchte daher in Abstimmung mit der DDB Fachstelle Bibliothek (SUB >>>> Göttingen) vorschlagen, das METS-Anwendungsprofil in folgender Weise >>>> zu erweitern: >>>> >>>> 1. Das Element dv:license darf wiederholt werden. >>>> >>>> 2. Das Element dv:license erhält ein Attribut "type", in dem angegeben >>>> werden kann, ob die Lizenzangabe sich auf das gesamte Dokument, die >>>> Metadaten oder die Images (oder die Volltexte oder ...) bezieht. Dazu >>>> werden normierte Attributwerte vorgegeben, damit diese einheitlich >>>> verwendet werden. Wird kein type-Attribut angegeben, wird die Lizenz >>>> auf das gesamte Dokument angewendet. >>>> >>>> Dadurch ist gewährleistet, dass existierende Implementierungen nicht >>>> verändert werden müssen. D.h. wer dieses Element nach aktuellem >>>> Anwendungsprofil bereits verwendet, muss seine Implementierung nicht >>>> anpassen, um weiterhin dieselbe Aussage zu treffen. Gleichzeitig >>>> besteht aber optional die Möglichkeit, die Aussagen zu präzisieren und >>>> verschiedene Teile des Digitalisats unterschiedlich zu lizensieren. >>>> >>>> Was meinen Sie? Haben Sie ergänzende oder abweichende Vorschläge? Wie >>>> handhaben Sie ggf. jetzt schon die Angabe verschiedener Lizenzen >>>> innerhalb Ihrer Digitalisate? >>>> >>>> Viele Grüße >>>> >>>> Sebastian Meyer >>>> >>>> -- >>>> >>>> Sebastian Meyer >>>> >>>> Referatsleiter Digitale Bibliothek >>>> >>>> Sächsische Landesbibliothek - >>>> >>>> Staats- und Universitätsbibliothek Dresden (SLUB) >>>> >>>> Abteilung IT, Referat Digitale Bibliothek >>>> >>>> 01054 Dresden >>>> >>>> Besucheradresse: Zellescher Weg 18 >>>> >>>> Tel.: +49 351 4677 206 | Fax: +49 351 4677 711 >>>> >>>> E-Mail: sebastian.meyer(a)slub-dresden.de >>>> >>>> http://www.slub-dresden.de >>>> >> >> -- >> Timo Schleier >> Gruppe Metadaten und Datenkonversion >> >> Georg-August-Universität Göttingen >> Niedersächsische Staats- und Universitätsbibliothek Göttingen >> D-37070 Göttingen >> >> Papendiek 14 (Historisches Gebäude, Raum 1.603) >> +49 551 39-10905 (Tel.) >> +49 551 39-3468 (Fax) >> >> timo.schleier(a)sub.uni-goettingen.de >> http://www.sub.uni-goettingen.de >> http://www.eromm.org >> >> > -- Timo Schleier Gruppe Metadaten und Datenkonversion Georg-August-Universität Göttingen Niedersächsische Staats- und Universitätsbibliothek Göttingen D-37070 Göttingen Papendiek 14 (Historisches Gebäude, Raum 1.603) +49 551 39-10905 (Tel.) +49 551 39-3468 (Fax) timo.schleier(a)sub.uni-goettingen.de http://www.sub.uni-goettingen.de http://www.eromm.org

...und ein kurzer Nachtrag: Ich bin leider bis 26. Juni außer Haus und stehe erst dann wieder zur Verfügung. -- David Maus On Sat, 23 May 2015 12:39:50 +0200, David Maus wrote: -- David Maus Herzog August Bibliothek - D-38299 Wolfenbuettel Bibliothekarische IT / Digital Humanities Phone: +49-5331-808-317 Email: maus(a)hab.de PGP Key 0x7B4F5A762AF6FBA6 Fingerprint DD38 8D2E 34C1 94DE 2058 69BE 7B4F 5A76 2AF6 FBA6