DV-Technik June 2015

dv-technik@dfg-viewer.de

2 participants
2 discussions

Re: [DFG-Viewer] Vorschlag: Wiederholbarkeit von dv:license

by Meyer, Sebastian

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

8 years, 10 months

dv:reference

by Philipp Vanscheidt

Sehr geehrte Damen und Herren, liebe Kollegen, eines unserer Projekte erhält eine neue Weboberfläche und vervollständigte METS-Dateien mit TEI-Headern. Dabei bin ich auf eine Frage gestoßen, die das verpflichtende Element dv:reference betrifft. Dieses verweist auf Katalogeinträge, zum Beispiel in einem eigenen OPAC. Unser Fall hat nun folgende Besonderheiten: Voraussetzung 1: Es gibt eine Datenbank, aus der dynamisch Einträge in einem Webportal erzeugt werden. Die Informationen aus der Datenbank werden ferner in die TEI-Header der METS-Dateien geschrieben. Das neue Webportal bietet aber nicht per se eine Adresse, um den vollständigen Katalogeintrag zu öffnen. Dieser lässt sich stattdessen in einer Trefferliste über einen Knopf jeweils auf- und zuklappen. Der Link bleibt dabei unverändert. Voraussetzung 2: Es gibt bei uns getrennte Katalogeinträge zu jedem Kodex und zu jedem Inhalt, die aber aufeinander verweisen. Zwischen beiden läßt sich entsprechend zwar navigieren, aber es erscheint wünschenswert, einen Katalogeintrag zu haben, der alle Information zu einem Kodex und zu allen seinen Inhalten umfasst. In unseren neuen METS-Dateien ist das der Fall. Es bieten sich, soweit ich sehe, drei Lösungen an: Lösung 1: Es wird auf die Katalogsuche selbst verweisen. Contra Lösung 1: Der Link wäre für alle Kodizes identisch. Man müsste erst noch nach dem jeweiligen Kodex suchen. Wenn man ihn gefunden hat, muss man sich gegebenfalls erst zu den Inhalten bewegen. Lösung 1 bietet keine Antwort auf den Wunsch aus Voraussetzung 2. Lösung 2: Man kann vielleicht versuchen, die Ereignisse, die zum Öffnen der Detailansicht führen, als Paramter in einem Link mitzugeben. Contra Lösung 2: Das wäre wahrscheinlich aufwendig. Ferner bildet es die Navigation auf der Oberfläche ab. Ändert sich diese, müssen auch die Parameter geändert werden. Es scheint mir sinnvoller, Adressen stabil zu halten als Weboberflächen. Auch Lösung 2 bietet keine Antwort auf die zweite Voraussetzung. Lösung 3: Wir verweisen direkt auf die METS-Datei mit dem TEI-Header, der alle Informationen aus der Datenbank enthält. (Alternativ können wir natürlich auch ein XML/TEI-Dokument erzeugen, das keine METS-Anteile enhält.) Diese Lösung kommt auch dem unter Vorausssetzung 2 geäußerten Erfordernis entgegen. Conta Lösung 3: Dies entspricht nicht den Beispielen in der Dokumentation. Nutzer könnten irritiert sein, wenn Sie einen OPAC erwarten und sich stattdessen eine XML-Datei öffnet. Trotz dieses Einwandes präferiere ich deutlich Lösung 3. Ich bin mir aber nicht sicher, ob das im Sinne des Erfinders ist. Der Definition von dv:reference widerspricht es m.E. allerdings auch nicht. Mit freundlichem Gruß Philipp Vanscheidt -- Technische Universität Darmstadt Institut für Sprach- und Literaturwissenschaft Dolivostraße 15, 64293 Darmstadt vanscheidt(a)linglit.tu-darmstadt.de

8 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

DV-Technik June 2015