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