Lieber Herr Vanscheidt, Ich teile Ihre Einschätzung der Lösungen 1 und 2, Lösung 3 lässt sich aus meiner Sicht gut weiterentwickeln. Variante 3a: Die METS-Datei enthält eine <?xml-stylesheet ?>-Processing Instruction, die auf ein XSL 1.0 Stylesheet verweist, dass eine HTML-Ansicht der Metadate erzeugt. Die üblichen Browser unterstützen XSL 1.0 und wenden Stylesheets der o.g. PI auch an. Sprich: Der Benutzer sieht eine HTML-Ausgabe. Variante 3b: Es gibt einen Webservice, der mit einem das Objekt identifzierenden Parameter aufgerufen wird und der die gewünschte Anzeige per XSL erzeugt. In Frage käme für den Service z.B. unAPI [unAPI]. Ein solcher Webservice könnte sich auch perspektivisch als ausgesprochen hilfreich erweisen. HTH, -- David Maus [unAPI] https://web.archive.org/web/20140331060734/http://unapi.info/ On Mon, 29 Jun 2015 22:56:34 +0200, Philipp Vanscheidt wrote: > > 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 >