Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0

Lieber Markus, die Aufgabe der METS-Validierung soll künftig nicht mehr der Viewer übernehmen. Wir haben jedoch die Entwicklung eines METS/MODS-Validators auf Grundlage der aktuellen Profile in Auftrag gegeben. Dieser wird als Webservice auf der Viewer-Webseite zur Verfügung stehen. Viele Grüße Sebastian -- ___________________________________________________ Sebastian Meyer Abteilung Informationstechnologie Referat Entwicklung Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Besucheradresse: Zellescher Weg 18 Tel.: +49 351 4677-206 Fax: +49 351 4677-711 Mail: smeyer(a)slub-dresden.de Web: http://www.slub-dresden.de/ ___________________________________________________ > -----Ursprüngliche Nachricht----- > Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg- > viewer.de] Im Auftrag von Enders, Markus > Gesendet: Dienstag, 25. November 2008 18:13 > An: technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0 > > Hallo liebe Kollegen und Kolleginnen, > > > Wenn ich ihren Ausführungen hier richtig folge, dann sagen Sie in der > Konsequenz: "Wir regeln hier etwas, was wir eigentlich gar nicht regeln > müßten. Dem Viewer ist das technisch ziemlich gleich." Darum stellt sich mir > die Frage: Warum schreiben wir dann auf den Seiten überhaupt etwas dazu? Aus > welchem Grund haben wir eine lange Diskussion über die Normierung eines > kontrollierten Vokabulars geführt, wenn sich zum Schluß kein technisches > System mit diesem Vokabular tatsächlich beschäftigt? > > > Berechtigte Frage - die wuerde mich auch interessieren. IMHO ist es schon so, > dass bestimmte Funktionalitaeten aus Konsistenzgruenden an den Strukturtypen > haengen sollten. > > Die Granularitaet eines Inhaltsverzeichnisses bspw. fuer eine Zeitschrift oder > eines Mehrbaendigen Werkes koennte man von dieses Strukturtypen abhaengig > machen. Fuer eine konsistente Darstellung dieser Verzeichnisse ist es m.E. > sinnvoll die Strukturtypen zu nutzen und nicht die Granularitaet der METS > Datei. > Wenn ich das derzeit richtig verstehe koennte der Viewer auch ein > Inhaltsverzeichnis einer kompletten Zeitschrift anzeigen (bis hinunter zur > Artikelebene), falls das komplette Inhaltshaltsverzeichnis in einer METS Datei > enthalten waere. > Ich koennte mir auch gut vorstellen, dass die Anzeige der bibliographischen > Daten von dem jeweiligen Strukturtyp abhaengen koennte. > > Das wir solche "Auswuechse" derzeit nicht sehen, hat IMHO damit zu tun, dass > wir es noch mit sehr homogenen METS Dateien zu tun haben. > > Ansonsten machen die Strukturtypen natuerlich vor allem bei der Suchen und > beim Browsen Sinn. Also nicht relevant fuer den DFG Viewer - jedoch weiterhin > fuer ZVDD. > > > > > > Genau so verhält es sich! Nur wie soll zvdd "erkennen", welches Mapping hier > anzuwenden ist? > > Im Prinzip bleibt nicht viel uebrig als ein Pointer auf die entsprechende > Mapping-Information zu setzen. Es gibt zum Speichern des pointers leider nicht > so richtig viele Moeglichkeiten. > Man koennte es in der <techMD> speichern - bspw. einer techMD mit einem > bestimmten ID-Wert. Dies wuerde einen schnellen Zugriff auf den Pointer > ermoeglichen. > > > > b) Wir sollten uns auf eine formale Beschreibungssprache einigen (Herr > Stäcker hatte dazu bereits auf Möglichkeiten im TEI-Format hingewiesen), die > die verschiedenen Ansprüche automatisiert bedienen kann (Übersetzungen für den > Viewer, Mappings für zvdd). Damit hätten wir eine Lösung, die aus meiner Sicht > a) hinreichend generalisiert ist und b) vollkommen transparent zu > implementieren ist. > > Vielleicht haetten wir dann auch ne Loesung die Kaffee kochen kann und Socken > stopfen ;-) TEI hat sicherlich seine Berechtigung. Worum es hier jedoch geht, > ist das mappen unterschiedlicher "Controlled Vocabularies". > > SKOS ist dafuer eigentlich recht schoen geeignet: > > <rdf:Description rdf:about="http://www.dfg- > viewer.org/registry/divtypes/zvdd/chapter"> > <rdf:type rdf:resource="http://www.w3.org/2008/05/skos#Concept"/> > <skos:prefLabel xml:lang="x-notation">chapter</skos:prefLabel> > <skos:altLabel xml:lang="en-latn">Chapter</skos:altLabel> > <skos:altLabel xml:lang="de-latn">Kapitel</skos:altLabel> > <skos:notation rdf:datatype="xs:string">chapter</skos:notation> > > <skos:definition xml:lang="en-latn">Ganz viel Erklaerung, was ein > Kapitel ist, und was nicht ;-)</skos:definition> > <skos:inScheme rdf:resource=" http://www.dfg- > viewer.org/registry/divtypes/zvdd"/> > <vs:term_status>stable</vs:term_status> > <skos:historyNote rdf:datatype="xs:dateTime">2008-11-25T16:42:00.000- > 00:00</skos:historyNote> > <skos:exactMatch rdf:resource=" http://www.dfg- > viewer.org/registry/divtypes/dfg-viewer/chapter"/> > <skos:changeNote rdf:datatype="xs:dateTime">2008-11-25T16:47:00.000- > 00:00</skos:changeNote> > </rdf:Description> > > Das waere bspw. ein SKOS Concept fuer ein Chapter des ZVDD-Concept Schemas. > Interessant hierbei ist, das <skos:exactMatch> dieses SKOS-Concept zu dem > entsprechenden DFG-Viewer-Concept in Verhaeltnis setzt (exactMatch). > > Fuer jedes Concept gibt es einen entsprechenden Record, der unter URL wie in > <rdf:about> angegeben verfuegbar sein muss. Dieser Records kann vom DFG- > Viewer, ZVDD oder sonst wem abgerufen werden. Neben entsprechenden > Sprachangaben (en, de) koennen auch entsprechende Beziehungen zu anderen, > weiteren Concept Schemas (bspw. GDZ, DigiZeit etc.) aufgenommen werden. > Neben einem "exactMatch" sind auch "narrowMatch" und "broadMatch" moeglich. > > > Alle Concepts fuer ZVDD und fuer den DFG-Viewer sind in getrennten Concept- > Schemas gespeichert. D.h. die Registry sollte eine Liste ausgeben koennen, die > alle Typen des ZVDD und des DFG-Viewer Concept Schemas zeigt. > Wenn ich das nun richtig verstanden habe, kommt oben nur ein kleiner Header > fuer das Concept Schema selber davor und anschliessend werden alle > entsprechenden Concepts aneinander gehangen. > > Jedes Projekt, welches ZVDD und/oder den DFG Viewer nutzen moechte koennte als > eigene ConceptCollection gepflegt werden. Hierin sind unterschiedliche > Concepts (aus unterschiedlichen ConceptSchemas) enthalten, so dass sich ein > Projekt aus unterschiedlichen Concepts bedienen kann und nicht zwangslaeufig > alle Concepts aus ZVDD nutzen muss. > > Diese Collection wuerde ich sinnvollerweise aus der einzelnen METS Datei > verlinken. > > Nur mal so meine Gedanken. Das ist jetzt nicht gross ausgearbeitet und > wirklich viel hab ich mit SKOS auch noch nicht gemacht (nichtmal ein zehntel > von dem, was Herr Staecker mit TEI gemacht hat). Nur scheint es mir etwas > zukunftstraechtiger, da u.a. Registry-Sfotware existiert, die die einzelnen > Concepts in unterschiedlicherweise Serialisieren kann. Obige RDF/XML > Serialisierung ist ja nur eine Moeglichkeit. Denkbar waere auch eine > Serialisierungs als JSON-Object fuer den direkten Einsatz auf der Webseite > entsprechend der Spracheinstellung des Benutzers. > > Alles in allem denke ich, dass man sich SKOS fuer diesen Zweck nochmal naeher > anschauen sollte. > > Meinungen? > > Ciao > Markus > > ************************************************************************** > > Experience the British Library online at www.bl.uk > > The British Library's new interactive Annual Report and Accounts 2007/08 : > www.bl.uk/knowledge > > Help the British Library conserve the world's knowledge. Adopt a Book. > www.bl.uk/adoptabook > > The Library's St Pancras site is WiFi - enabled > > ************************************************************************* > > The information contained in this e-mail is confidential and may be legally > privileged. It is intended for the addressee(s) only. If you are not the > intended recipient, please delete this e-mail and notify the postmaster(a)bl.uk > : The contents of this e-mail must not be disclosed or copied without the > sender's consent. > > The statements and opinions expressed in this message are those of the author > and do not necessarily reflect those of the British Library. The British > Library does not take any responsibility for the views of the author. > > *************************************************************************