Liebe Kolleginnen und Kollegen,
wir haben den Anwendungsfall, dass wir vollständige Bände digitalisieren
in denen mehrere Werke zusammengebunden wurden. Die Rechteklärung und
-dokumentation erfolgt dann werkweise, was mit einer wiederholbaren
<mets:amdSec> sehr leicht ginge. Idealerweise möchte ich die Verknüpfung
zum Werk dann auch nicht über die <mets:structMap TYPE="LOGICAL">
schleusen. Schön und einfach wäre eine direkte Verknüpfung bei der
amdSec oder bei der dmdSec, also so
<mets:dmdSec ID="dmd_work1">...</mets:dmdSec>
<mets:amdSec ID="amd_work1"
DMDID="dmd_work1">...</mets:amdSec>
oder so
<mets:dmdSec ID="dmd_work1"
AMDID="amd_work1">...</mets:dmdSec>
<mets:amdSec ID="amd_work1">...</mets:amdSec>
Für die Abwärtskompatibilität könnten wir sorgen, indem wir eine
zusätzliche (z.B. <mets:amdSec ID="amd_dfg">) mit den "für den
DFG-Viewer relevanten administrativen Metadatensektionen" einfügen
würden, die weiterhin im primären, logischen Strukturelement im Attribut
AMDID verlinkt wird (gemäß Mets-Anwendungsprofil 2.1, Seite 8). Für uns
wäre dies einfach: Wir würden darin eine für den ganzen Band geltende
(kumulierte) Rechteversion formulieren (bei uns wäre dies die
restriktivste der Einzelsektionen).
Viele Grüße,
Christian Knoop
Am 09.07.2015 15:27, schrieb David Maus:
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 <maus(a)hab.de>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
--
Christian Knoop
stv. Leitung Bibliothek
Deutsches Museum
Museumsinsel 1
80538 München
Tel: +49 / (0) 89 / 2179-420
Fax: +49 / (0) 89 / 2179-262
c.knoop(a)deutsches-museum.de
http://www.deutsches-museum.de