DV-Technik

dv-technik@dfg-viewer.de

329 discussions

MODS originInfo: Abgrenzung Verleger von Drucker

by Meyer, Sebastian

Liebe KollegInnen, untenstehende Mail von Frau Overkamp hat der Mailinglisten-Server fälschlicherweise nicht zugestellt. Deshalb auf diesem Weg der erneute Versuch einer Zustellung. Viele Grüße Sebastian Meyer -- Sebastian Meyer Projekt-Mitarbeiter Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Tel.: +49 351 4677-206 Fax: +49 351 4677-711 http://www.slub-dresden.de/ > -----Ursprüngliche Nachricht----- > Von: Inga Overkamp [mailto:overkamp@mpdl.mpg.de] > Gesendet: Freitag, 20. März 2009 18:44 > An: dv-technik-bounces(a)dfg-viewer.de > Cc: Wilhelm Frank > Betreff: MODS originInfo: Abgrenzung Verleger von Drucker > > Liebe Kolleginnen und Kollegen, > > in der Max Planck Digitalen Bibliothek arbeiten wir im Rahmen des > Projektes "Virtueller Raum Reichsrecht" (s. > http://colab.mpdl.mpg.de/mediawiki/ViRR:_Virtueller_Raum_Reichsrecht) > derzeit an der Konvertierung von Katalogdaten nach MODS, um die > Digitalisate mittelfristig "DFG-Viewer tauglich" zu machen. > > Dabei sind wir auf MAB-Datensaetze gestossen, die sowohl ueber Angaben > zum Verleger als auch zum Drucker verfuegen (MAB 410/410a bzw. > 412/412a). Diese Rollen-Differenzierung wuerden wir gerne in den > MODS-Daten abbilden, haben aber im originInfo-Element keine > Moeglichkeit > dazu gefunden. Alternativ haben wir die Nutzung des Elements <name > type="corporate"> mit den entsprechenden MARC Relator Codes ueberlegt, > aber auf diese Weise wuerden die Beziehungen zum Ort/Datum verloren > gehen. > > Ich habe ein bisschen Sorge, dass wir hier evtl. etwas Offensichtliches > uebersehen - und wuerde mich daher ueber jede Empfehlung oder > Einschaetzung sehr freuen. > > Recht herzlichen Dank fuer Ihre Hilfe im voraus und beste Gruesse, > inga overkamp > -- > Inga Overkamp E-Mail: overkamp(a)mpdl.mpg.de > Tel: +49-89-38602-231 > Max Planck Digital Library (MPDL) Fax: +49-89-38602-280 > Amalienstr. 33, D-80799 Munich, GERMANY http://www.mpdl.mpg.de >

16 years, 11 months

Mehrsprachigkeit

by Jochen Barth

Sehr geehrte Damen und Herren, ich überarbeite gerade unsere Digi-Präsentation. Dabei ist mir aufgefallen, dass z. B. bei den Feldern <note> und <abstract> keine Sprache «lang="..."» und bei <abstract> auch kein «type="..."» vorgesehen ist - in der referenzierten Mods-Beschreibung bei loc.gov gibt es diese Attribute. Ist das Hinzufügen solcher Attribute und eine entspr. Wiederholung eines Feldes in mehreren Sprachen bereits angedacht? Viele Grüße aus Heidelberg, J. Barth -- J. Barth / Universitätsbibliothek Heidelberg, IT / +49 6221 54-2580

16 years, 11 months

Re: [DFG-Viewer] METS-Format für Handschriften (Beispiel)

by Meyer, Sebastian

Lieber Herr Mackert, liebe Kolleginnen und Kollegen, leider hatte sich ein kleiner Fehler in die METS-Datei eingeschlichen. Im Anhang finden Sie die korrigierte Version. Viele Grüße Sebastian Meyer -- Sebastian Meyer Projekt-Mitarbeiter Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Tel.: +49 351 4677-206 Fax: +49 351 4677-711 http://www.slub-dresden.de/ > -----Ursprüngliche Nachricht----- > Von: Christoph Mackert [mailto:mackert@ub.uni-leipzig.de] > Gesendet: Montag, 9. März 2009 10:43 > An: Meyer, Sebastian > Betreff: Re: METS-Format für Handschriften (Beispiel) > > Lieber Herr Meyer, > > erst einmal herzlichen Dank für Ihre Arbeit! Den TEI-Anhang konnte ich > öffnen, beim METS-Anhang erscheint bei mir "XML-Verarbeitungsfehler: > Schlecht formuliert". Was mache ich falsch? > > Beste Grüße > CM > > -- > Dr. Christoph Mackert > Universitaetsbibliothek Leipzig > Leiter des Handschriftenzentrums > Stellvertretender Bereichsleiter Sondersammlungen > Beethovenstr. 6 > D-04107 Leipzig > > fon: +49 (0)341 97-30509 > mail: mackert(a)ub.uni-leipzig.de > > > Am 06.03.2009 17:04 Uhr schrieb Meyer, Sebastian: > > Liebe Kolleginnen und Kollegen, > > > > anbei nun der schon lange versprochene erste Entwurf für eine > Handschrift im METS-Format. Die Datei "JeanDupin_tei.xml" enthält den > unveränderten TEI-Export aus HiDA, die Datei "JeanDupin_mets.xml" eine > darauf basierende Repräsentation im METS-Format, die denselben > Informationsgehalt besitzt und noch weitergehende Möglichkeiten bietet. > > > > Dazu ein paar Anmerkungen: > > > > - Diverse Angaben im METS-Format sind rein fiktiv, da es dazu keine > Informationen im TEI-Export gab. Das betrifft beispielsweise Links zu > den für den DFG-Viewer benötigten Logos und Kontaktadressen der SBB und > zu den Digitalisaten, einige Identifier wie URN und PURL sowie die > Paginierungssequenz. Einige dieser Angaben sind zwar optional, aber > dennoch empfehlenswert (wie die URN und PURL), andere verpflichtend, > wenn man die DFG-Praxisregeln zur Digitalisierung erfüllen möchte (die > DFG-Viewer-Elemente). > > > > - Paginierungssequenz und physische Struktur habe ich nur gekürzt > wiedergegeben. Das Prinzip wird aber glaube ich deutlich. > > > > - Die Metadaten habe ich bewusst weitestgehend in MODS untergebracht, > sofern es entsprechende Felder in MODS gab. Lediglich die Informationen > im TEI-Feld <msContent> habe ich im TEI-Format in METS eingebettet. > (Wobei man die Angaben in <filiation> ggf. sogar im MODS-Feld > <relatedItem> unterbringen könnte, wenn es einen passenden Wert für das > type-Attribut gäbe.) > > > > - Für die PND-ID einer Person gibt es meines Wissens auch im Bereich > der Drucke (noch) kein einheitlich definiertes Feld in MODS. Ich habe > sie deshalb nun im xml:id-Attribut im <mods:name>-Feld der Person > untergebracht, aber das könnte problematisch werden, wenn man dort > wirklich mal eine "echte" XML-ID vergeben möchte. > > > > Die Handschriften-Experten unter Ihnen würde ich nun bitten, sich das > Beispiel vor allem inhaltlich einmal anzusehen. Da ich mich selbst > nicht besonders gut mit Handschriften auskenne, kann ich nicht > ausschließen, dass ich diverse Angaben im TEI-Format möglicherweise > falsch interpretiert und entsprechend falsch in MODS abgebildet habe. > Wichtig ist vor allem, dass die Angaben semantisch korrekt und > vollständig sind. > > Die METS-Experten unter Ihnen möchte ich wiederum bitten, sich das > Beispiel vor allem hinsichtlich seiner METS/MODS-Konformität > anzuschauen. > > > > Hilfreich können dabei in jedem Fall die Dokumentationen auf der > Webseite des DFG-Viewers [1] und der Library of Congress [2] sein. Dort > finden Sie Anwendungsprofile für METS und MODS sowie Erläuterungen zu > den einzelnen Feldern und deren möglicher Belegung. > > > > Viele Grüße > > Sebastian Meyer > > > > [1] http://dfg-viewer.de/profil-der-metadaten/ > > [2] http://www.loc.gov/standards/mets/ bzw. > http://www.loc.gov/standards/mods/ > > > > -- > > > > Sebastian Meyer > > Projekt-Mitarbeiter > > > > Sächsische Landesbibliothek - > > Staats- und Universitätsbibliothek Dresden (SLUB) > > 01054 Dresden > > Tel.: +49 351 4677-206 > > Fax: +49 351 4677-711 > > http://www.slub-dresden.de/ > > > > > >

17 years

METS-Format für Handschriften (Beispiel)

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, anbei nun der schon lange versprochene erste Entwurf für eine Handschrift im METS-Format. Die Datei "JeanDupin_tei.xml" enthält den unveränderten TEI-Export aus HiDA, die Datei "JeanDupin_mets.xml" eine darauf basierende Repräsentation im METS-Format, die denselben Informationsgehalt besitzt und noch weitergehende Möglichkeiten bietet. Dazu ein paar Anmerkungen: - Diverse Angaben im METS-Format sind rein fiktiv, da es dazu keine Informationen im TEI-Export gab. Das betrifft beispielsweise Links zu den für den DFG-Viewer benötigten Logos und Kontaktadressen der SBB und zu den Digitalisaten, einige Identifier wie URN und PURL sowie die Paginierungssequenz. Einige dieser Angaben sind zwar optional, aber dennoch empfehlenswert (wie die URN und PURL), andere verpflichtend, wenn man die DFG-Praxisregeln zur Digitalisierung erfüllen möchte (die DFG-Viewer-Elemente). - Paginierungssequenz und physische Struktur habe ich nur gekürzt wiedergegeben. Das Prinzip wird aber glaube ich deutlich. - Die Metadaten habe ich bewusst weitestgehend in MODS untergebracht, sofern es entsprechende Felder in MODS gab. Lediglich die Informationen im TEI-Feld <msContent> habe ich im TEI-Format in METS eingebettet. (Wobei man die Angaben in <filiation> ggf. sogar im MODS-Feld <relatedItem> unterbringen könnte, wenn es einen passenden Wert für das type-Attribut gäbe.) - Für die PND-ID einer Person gibt es meines Wissens auch im Bereich der Drucke (noch) kein einheitlich definiertes Feld in MODS. Ich habe sie deshalb nun im xml:id-Attribut im <mods:name>-Feld der Person untergebracht, aber das könnte problematisch werden, wenn man dort wirklich mal eine "echte" XML-ID vergeben möchte. Die Handschriften-Experten unter Ihnen würde ich nun bitten, sich das Beispiel vor allem inhaltlich einmal anzusehen. Da ich mich selbst nicht besonders gut mit Handschriften auskenne, kann ich nicht ausschließen, dass ich diverse Angaben im TEI-Format möglicherweise falsch interpretiert und entsprechend falsch in MODS abgebildet habe. Wichtig ist vor allem, dass die Angaben semantisch korrekt und vollständig sind. Die METS-Experten unter Ihnen möchte ich wiederum bitten, sich das Beispiel vor allem hinsichtlich seiner METS/MODS-Konformität anzuschauen. Hilfreich können dabei in jedem Fall die Dokumentationen auf der Webseite des DFG-Viewers [1] und der Library of Congress [2] sein. Dort finden Sie Anwendungsprofile für METS und MODS sowie Erläuterungen zu den einzelnen Feldern und deren möglicher Belegung. Viele Grüße Sebastian Meyer [1] http://dfg-viewer.de/profil-der-metadaten/ [2] http://www.loc.gov/standards/mets/ bzw. http://www.loc.gov/standards/mods/ -- Sebastian Meyer Projekt-Mitarbeiter Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Tel.: +49 351 4677-206 Fax: +49 351 4677-711 http://www.slub-dresden.de/

17 years

OT regelwerk

by Thomas Stäcker

...auch noch einmal zum Regelwerk eine Nachfrage. Wir haben das Feld <originInfo>/<dateIssued> in der MODS Sektion als Pflichfeld deklariert. Wie behandeln wir den Fall, wenn es kein Jahr in der Quelle gibt? Soll das in a) Pflicht, wenn vh. geändert werden b) leer bleiben <dateIssued/> c) explizit als nicht vh. charakterisiert werden <originInfo>/<dateIssued>ohne Jahr Viele Grüße, Ihr Th. Stäcker

17 years

Frage zu Validierung

by Thomas Stäcker

Lieber Herr Meyer, liebe Kollegen, können Sie mir in einer Sache helfen. Ich habe beigefügte Datei dem Validator übergeben. Er hat folgende <mets:structLink> <mets:smLink xlink:to="physMD_586140484" xlink:from="logMD_586140484"/> </mets:structLink> beanstandet als Fehler in der strukturellen Integrität des Dokuments [1] *Fehler!* Das 1. smLink Element des structLink Blocks verweist im Attribut xlink:to nicht auf eine gültige div Sektion structMap vom TYPE PHYSICAL. bzw, TYPE LOGICAL Da die ZuordnungsIDs vorhanden sind, ist mir nicht klar, was der Parser hier moniert. Können Sie mir helfen? Habe ich Tomaten auf den Augen? Dann auch noch einmal explizit die Frage (nur noch einmal zur Selbstvergewisserung): Die Verlinkungsrichtung ist die von LOGICAL auf PHYSICAL? Theoretisch kann es ja auch andersherum sein, je nachdem, ob man einer Seite Daten oder Daten einer Seite zuordnet bzw. ob man eher ein eBind oder TEI Konzept verfolgt. Oder stellen wir das frei? Viele Grüße und Dank im voraus, Ihr Th. Stäcker

17 years

Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17-Projekten

by Kay Heiligenhaus

Liebe Frau Federbusch, > Ich denke, man sollte es nicht ganz so schwarz-weiß malen. Das finde ich auch immer gut. > Immerhin haben wir mit der ZVDD-Liste ja bereits ein weiteres Strukturdatenset > ... und nun gilt es, maßvoll mit den Möglichkeiten umzugehen. Auch > halte ich es für die Akzeptanz von Strukturdatentypologien für > günstiger, nicht auch noch Strukturen der Medientypen zu vermengen, da > auch die Beziehungen zwischen den Strukturen von Bedeutung sind und > sich mit einer Typologie für z.B. Handschriften ein klareres Bild > ergibt als wenn alles in einem Topf schwimmt. Das lese ich nun aber als Plädoyer für die Nutzung der vorhandenen Typologie für Druckwerke sowie der Entwicklung (mindestens einer weiteren) für z.B. Handschriften. Verstehe ich Sie da richtig? Beste Grüße, Kay Heiligenhaus

17 years

Re: [DFG-Viewer] Nochmal zum Validator

by Kay Heiligenhaus

Lieber Herr Stäcker, > wenn ich recht sehe, geht es doch nur um Kleinkram, den man problemlos > noch in die Datei bringen kann (smLinks). Entscheidend ist, dass es > valide durchläuft, sprich METS valide ist. So hatte ich Herrn Meyer > verstanden. Ja, es geht letztlich um Kleinkram. Aber an dem scheiden sich ja zuweilen die Geister. ;) Gegenüber dem METS-Schema der LoC sind beide Varianten, die wir bislang auf den Viewer-Seiten dokumentiert haben, valide. Auch gehe ich davon aus, daß sich nach und nach eher das erweiterte Profil durchsetzen wird, da es einen deutlich erweiterten Ausdrucksraum besitzt. Institutionen tun also gut daran, direkt diese Variante zu implementieren. Was m.E. jedoch wichtig ist: wir haben für die Version 1 des Viewers beschlossen, daß "METS light" unterstützt wird. Wenn man sich im Netz so umschaut, hat das recht schnell zu einer breiteren Akzeptanz des Formates in den Communities geführt. Damit sollte man m.E. nicht ohne Not brechen, sondern das in der Dokumentation auf den Viewer-Seiten nur entsprechend deutlich machen. > Im Übrigen hat der UA der DFG formal bislang kein in einem Schema > abbildbares Applikation Profile beschlossen, sondern nur die gleichsam > generische METS Kompatibilität plus eine Beschreibung, was in den MODS > Feldern minimal stehen sollte. Da bin ich mal gespannt auf die genaue Formulierung. METS kann alles mögliche sein. Erst mit einem echten AP wird daraus etwas, was man wirklich sinnvoll nutzen kann. > Kurz- bis Mittelfristig sollte sich das ändern, indem z.B. von Seiten > der DFG Schemata vorgegeben werden. Für diesen Zweck müsste auch die > Community noch etwas Finetuning übernehmen, z.B. ist m.E. der dv- > Bereich noch nicht abschliessend diskutiert (was ist verbindlich, z.B. > emailadresse oder eine lokale Homepage?). Aber es sieht mit den > vorhandenen Schema-Dateien schon ganz gut aus und wir rücken ja > minütlich ein Stück weiter an ein AP für den Viewer heran ;-) So ist es. Allerdings sehe ich die Diskussion für Vers. 2.0 des Viewers eigentlich schon als abgeschlossen an. Es geht mir hier also nicht um Erweiterungen, die über da bereits beschlossene und implementierte hinausgehen, sondern um einige Implementierungsdetails auf Seiten des Viewers (Layoutbugs, Anzeige der Seitenidentifier (sofern vorhanden), Anzeige von bibliographischen Nachweisen (sofern vorhanden)), die m.E. für eine Version 2.x noch zu leisten sind. Dazu kommen dann Details der Dokumentation, die hier im Kern den Validator betreffen. Funktionale Erweiterungen sehe ich eher einer Version 3.0 vorbehalten. Beste Grüße, kay Heiligenhaus

17 years

Re: [DFG-Viewer] Nochmal zum Validator

by Kay Heiligenhaus

Lieber Herr Meyer, > ja, da rächt es sich nun, dass wir dieses elende METS light > unterstützen... Nur um eine structLink-Sektion mit einem einzigen > smLink-Eintrag und eine structMap-Sektion mit einem einzigen logischen > Eintrag einzusparen, müssen wir nun an zig Stellen Sonderbehandlungen > einbauen. Ich bin ja nach wie vor der Meinung, dass diese zwei Zeilen > XML die Sache auch nicht unzumutbar kompliziert gemacht, uns dafür aber > technisch sauberes METS beschert hätten. Hm, das sehe ich nicht so. "Sauber" ist das "METS light" auch. Es entspricht sogar eher den Implementierungen, die ich im METS-Umfeld so kennen. > Der Validator kann METS light nicht validieren, Version 2.0 des Viewers > kann es nicht anzeigen, die Beispiele und Dokumentation sorgen mit > Ausnahmen und Sonderregeln für Verwirrung und der Anwender glaubt METS > zu erzeugen, das in Wahrheit aber kein valides METS ist (und deshalb > ausschließlich im Kontext des Viewers brauchbar ist). Das stimmt so nicht. Der Validator zeigt beim "METS light" ja nun auch an, daß es sich um valides METS handelt. Er bemängelt nur, daß keine smLinks usw. vorhanden sind. > Und das führt dann letztlich zu solchen Trugschlüssen wie denen von Herrn Graf und > dem Kommentator Markus. > Natürlich kann (und werde) ich nun einen Hinweis beim Validator > anbringen, dass dieser sich nicht für METS light eignet, letztlich wird > das die Verwirrung aber eher noch vergrößern. Die Verwirrung entsteht aktuell aus den Diskrepanzen zwischen Dokumentation und Implementierung. > Der DFG-Unterausschuss für Kulturelle Überlieferung hat vor anderthalb > Wochen die Verabschiedung des Praxisregel-Entwurfs beschlossen. Damit > wird es nun also langsam wirklich ernst für den Viewer. Meiner Meinung > nach sollten wir die letzte Gelegenheit nutzen und die offizielle > Unterstützung von METS light wieder einstellen. Inoffiziell kann der > Viewer es ja auch weiterhin interpretieren, damit Anwender wie die BSB > nicht schon wieder ihr Format umstellen müssen, aber es sollte eben > nirgendwo mehr dokumentiert oder validiert werden. Künftige Anwender > würden dann gleich echtes METS erzeugen, wovon letztlich beide Seiten > nur profitieren. Wenn er die Entwurfsfassung beschlossen hat, dann hat er "METS light" beschlossen. Ein Grund mehr, dem Validator beizubringen, daß er das Format auch interpretieren kann. So schwer ist das m.E. nicht. Beste Grüße, Kay Heiligenhaus > > Viele Grüße > Sebastian Meyer > > -- > > Sebastian Meyer > Projekt-Mitarbeiter > > Sächsische Landesbibliothek - > Staats- und Universitätsbibliothek Dresden (SLUB) > 01054 Dresden > Tel.: +49 351 4677-206 > Fax: +49 351 4677-711 > 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 Kay Heiligenhaus > > Gesendet: Sonntag, 22. Februar 2009 12:26 > > An: dv-technik(a)dfg-viewer.de > > Betreff: [DFG-Viewer] Nochmal zum Validator > > > > Lieber Herr Meyer, > > > > ich habe gesehen, daß Sie nun den Validator auf den Viewer-Seiten > aktiv > > geschaltet haben: > > > > http://dfg-viewer.de/profil-der-metadaten/validator/ > > > > Leider wird der Nutzer an keiner Stelle darauf hingewiesen, daß der > > Validator keine METS/MODS-Dateien der Version 1 (Light-Profil) > > validieren kann, obgleich unsere eigenen Beispiele auf den Viewer- > > Seiten diesem Schema folgen. Wohin das führt, konnte vor kurzem die > BSB > > am eigenen Leibe erfahren: > > > > http://archiv.twoday.net/stories/5525850/ > > > > Im Kommentar vom 19.2. heißt es: > > > > "In dem angegebenen Link zum DFG-Viewer muss die URL, die zur METS > > Datei fuehrt encoded werden. > > Der derzeitige Link gibt lediglich eine Fehlermeldung des DFG-Viewers > > aus; die METS Datei der BSB wird nichtmal geladen. > > > > http://dfg-viewer.de/v1/?set%5Bmets%5D=http%3A%2F%2Fmdz10.bib- > > bvb.de%2F%7Edb%2Fmets%2Fbsb00025408_mets.xml > > > > waere die richtige URL - die allerdings auch nicht funktioniert, da > die > > METS Datei nicht den Spezifikationen des DFG Viewers entspricht." > > > > Die BSB-METS-Datei entspricht sehr wohl den Vorgaben des DFG-Viewers > im > > Light-Profil (wie übrigens fast alle mir bisher bekannten Umsetzungen > > der Viewer-Anforderungen an zig Standorten). Das Problem steckt hier > > woanders (nämlich darin, daß die Image-URLs nicht mehr gültig sind). > > Man sieht aber an diesem Beispiel, wie schnell aus solchen > technischen > > Wirrnissen Anwürfe generalisierender Art werden: "BSB missachtet ihre > > Pflichten gegenüber der DFG". Das kann nicht im Interesse der > Community > > sein... > > > > Beste Grüße, > > Kay Heiligenhaus >

17 years

Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17-Projekten

by Kay Heiligenhaus

Lieber Herr Meyer, > Richtig, so sollte es sein. Darauf hatten wir uns auch zuletzt > geeinigt, ich habe es lediglich noch nicht umgesetzt. Das habe ich so auch in Erinnerung. > Ich würde die Sache allerdings nur ungern weiter verkomplizieren, in > dem der Viewer künftig auch noch eine Vielzahl verschiedener > Strukturdatensets unterstützen soll. Das wäre aus meiner Sicht auch > nicht besonders zielführend: > Wenn auch externe Strukturdatenlisten unterstützt werden sollen, müsste > erst wieder ein Standard geschaffen werden, wie solche Listen > auszusehen haben. Wir müssten uns auf Format und Übertragungsweg > einigen und auch wieder alle Eventualitäten beachten. Wie soll der > Viewer beispielsweise reagieren, wenn die Liste nicht erreichbar ist > oder in einem ungültigen Format vorliegt? Ich würde die Listen zentral pflegen wollen, auf den Viewer-Seiten selbst. Bzgl. des Formats gab es hier schon ein paar Vorschläge. Das könnte man sich in Ruhe überlegen. > Außerdem bedeuten extern gepflegte Listen, dass im Grunde jeder sein > eigenes Strukturdatenset anfertigen und in den eigenen METS-Dateien > verlinken kann. Das würde zwar die Abstraktion des Viewers erhöhen, > umgekehrt aber auch jede Bemühung um ein standardisiertes > Strukturdatenset zunichte machen. Wie gesagt, ich sehe es eher so, daß man - analog zur VD16/17-Liste - eben weitere in den jeweiligen Communities diskutieren und standardisieren könnte. > Ich würde sogar so weit gehen, nicht einmal für verschiedene > Medientypen jeweils eigene Strukturdatensets zu pflegen, sondern nur > genau _ein_ Set zu unterstützen, dass jedoch passende Strukturdaten für > verschiedene Medientypen enthält. Statt also für Handschriften ein > eigenes Strukturdatenset zu erstellen, würde ich lieber dem vorhandenen > einige handschriften-spezifische Strukturdaten hinzufügen. (Zumal es > ohnehin eine Schnittmenge zwischen beiden Sets gäbe.) Das hätte den > Vorteil, dass der Viewer nicht auch noch vor der Darstellung der > Strukturdaten erst anhand irgendwelcher Kriterien eine Auswahl des > passenden Sets treffen müsste. Die technische Komplexität bei einer zentralen Pflege halte ich für gering. Demgegenüber würde ein einziges Strukturdatenset m.E. Gefahr laufen, unendlich zu wuchern. Beste Grüße, Kay Heiligenhaus

17 years

← Newer
1
...
22
23
24
25
26
27
28
...
33
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

DV-Technik