Sehr geehrte Damen und Herren, lieber Herr Maus,
in Anschluss an
https://maillist.slub-dresden.de/pipermail/dv-technik/2015-June/000842.html
habe ich nun unsere Skripte angepasst. Das Resultat ist nun:
<mets:digiprovMD ID="S0071-DIGIPROVAMD">
<mets:mdWrap MDTYPE="OTHER" MIMETYPE="text/xml" OTHERMDTYPE="DVLINKS">
<mets:xmlData>
<dv:reference>http://zimks68.uni-trier.de/stmatthias/S0071/S0071-digitalisat.xml</dv:reference>
<dv:presentation>http://www.stmatthias.uni-trier.de/</dv:presentation>
</mets:xmlData>
</mets:mdWrap>
</mets:digiprovMD>*
Dennoch verweist die Referenz, also das Icon zwischen Logo und Kontakt
im DFG-Viewer, in unserem Fall dennoch auf die Seite des DFG-Viewers
selbst. Ich kann aber keinen prinzipiellen Unterschied zu dem Beispiel
aus der Dokumentation:
<dv:reference>http://slub-dresden.de/FOZK.pl?PPN=356448053</dv:reference>
erkennen. Was mach ich falsch? Auch <dv:presentation> wird scheinbar in
unserem Fall nicht für die Darstellung genutzt.
Mit freundlichem Gruß
Philipp Vanscheidt
* Das ganze Beispiel findet sich auf
http://zimks68.uni-trier.de/stmatthias/S0071/S0071-digitalisat.xml
--
Technische Universität Darmstadt, Institut für Sprach- und
Literaturwissenschaft
Dolivostraße 15, 64293 Darmstadt
Tel.: 06151/1657405
vanscheidt(a)linglit.tu-darmstadt.de
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>:
...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
