...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
--
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
--
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