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

Hallo liebe Kollegen und Kolleginnen, 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. Ich sehe den DFG Viewer jedoch immer in einem Paket mit ZVDD. Im Zweifelsfall werden die Inhaltsanbieter mittels des DFG-Viewers checken, ob ihre Daten valide sind und annehmen, dass diese dann auch durch ZVDD verarbeitet werden koennen. Genau das halte ich auch fuer sinnvoll, auch wenn der DFG-Viewer nicht unbedingt als Validator fuer ZVDD geplant war. 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. 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&qu… <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. *************************************************************************