Liebe Kollegen und Kolleginnen, Um die Diskussion um die Weiterentwicklung des METS Anwendungsprofils im Hinblick auf heterogene Rechteangaben von der abstrakten Ebene herunter zu bringen schlage ich vor, dass wir anhand der konkreten zur Diskussion stehenden Anwendungsfälle eine METS-konforme Lösung via @ADMID entwickeln und dann die Frage beantworten, wie wir diese Lösung in die bestehende Software integrieren. Ich bin zuversichtlicht, dass wir wenn nötig auch die Regeln formulieren können, nach denen eine @ADMID-Lösung in die @type-Lösung umgewandelt werden kann. Mit besten Grüßen, -- David Maus On Thu, 28 May 2015 15:57:29 +0200, Meyer, Sebastian wrote: > [1 <text/plain; iso-8859-1 (quoted-printable)>] > [2 <text/html; iso-8859-1 (quoted-printable)>] > > Liebe Kolleginnen und Kollegen, > > dem schließe ich mich an, weshalb ich zu entschuldigen bitte, dass ich > die Diskussion zwar angestoßen, mich bisher aber nicht weiter selbst > beteiligt habe. > > Beste Grüße vom Bibliothekartag, > Sebastian Meyer > > Am 28.05.2015 15:22 schrieb David Maus &lt;maus(a)hab.de&gt;de>: > ...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: >> Lieber Herr Schleier, >> >> On Fri, 22 May 2015 15:54:51 +0200, >> Timo Schleier wrote: >>> Lieber Herr Maus, >>> >>>> Wenn unterschiedliche Lizenzen für unterschiedliche Teile des >>>> digitalen Objekts zugelassen werden sollen, dann *muss* <amdSec> >>>> wiederholbar sein, damit auch unterschiedliche Lizenzgeber > (dv:owner) >>>> angegeben werden können. Oder unterschiedliche <digiprovMD>. >>> 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. >>> >> Es ließe sich auch die <rightsMD> in der <amdSec> wiederholen und > die >> betreffenden Teile über das @ADMID-Attribut mit den <rightsMD> >> verbinden. >> >> Ich sehe nicht, wie die <dv:license>/@type-Variante einfacher ist: >> Anstatt expliziter Zuweisungen wählen Sie implizite Zuordnungen von >> Lizenzen zu Bestandteilen des digitalen Objekts. Das wird Ihnen >> mittelfristig auf die Füße fallen. >> >> Bis gerade eben wurde vorausgesetzt, dass die Lizenz der > verschiedenen >> Teile identisch ist. Die Entscheidung, diese Zuordnung über ein >> Attribut des <dv:license>-Elements auszudrücken setzt voraus, dass > der >> Owner und der Sponsor identisch sind. Auf welcher Grundlage machen > Sie >> diese Voraussetzungen? Mir erscheint das ausgesprochen kurzsichtig. >> >> In Verbindung mit dem Anwendungsprofil, in dem eine Wiederholung von >> <amdSec> et al. nicht vorgesehen ist verhindert die Lösung, dass die >> Rechteangaben in METS-konformer Form zugewiesen werden können. Damit >> ist das METS nur für den DFG-Viewer geeignet. Deswegen ist die >> Attributlösung nicht interoperabel. >> >>>> Auch das ist abwärtskompatibel: Wer die <div> des Werkes mit der >>>> <amdSec> verknüpft gibt an, dass die in der <amdSec> angegebenen >>>> Lizenzinformationen für das gesamte digitale Objekt gilt. >>> 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. >>> >> Es kann sein, dass die METS-konformen Angaben *für den DFG-Viewer* >> schwieriger zu verarbeiten sind. Dann muss der DFG-Viewer >> umprogrammiert werden. >> >> Mit besten Grüßen, >> -- David >> >>>> Nein: Die <structMap> gehört zur METS-Datei. Sie könnten IIRC > den >>>> <metsHdr> mit einer <amdSec> verbinden. >>> Ü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