Interview von Karsten Süß mit Markus Schnalke (Landesarchiv Baden-Württemberg) zur Verwendung von persistenten Identifikatoren ---------------------------------------------------- 2017-12-06 Nachfolgend ist das Transkript eines Interview-Gespraechs, das Karsten Süß mit mir 2017-12-06 gefuehrt hat. Wenn ich mich recht erinnere war es fuer Teil einer Abschluss- oder Studienarbeit. An manchen Stellen sind meine Aussagen inhaltlich zu spezifisch auf den konkreten Kontext ausgerichtet, aber es war mir zu viel Aufwand, die allgemeinen Aussagen daraus zu extrahieren und allgemeiner aufzubereiten. Ehrlich gesagt bin ich froh, das Transkript nach eineinhalb Jahren ueberhaupt online gestellt zu bekommen. KS: Warum benutzt man globale PIs Deiner Meinung nach? MS: Eine ID hat aus meiner Sicht zwei wichtige Aufgaben. Das eine ist die Identität eines Objektes prüfen zu können: Ist das genau das Objekt, das ich meine? Das andere ist das Auffinden eines Objektes. Das Auffinden macht man nicht direkt mittels eines Identifiers, sondern man braucht einen Resolver. Aber ein Identifier ist die Information, die es braucht, um so ein Suchsystem wie einen Resolver nutzen zu können. Dafür braucht man Identifier. Da ist noch nicht einmal die Persistenz dabei. Identifier für unsere Zwecke sollen sich eben nicht ändern. Was ich heute identifizieren kann -- dass das das passende Objekt ist -- das möchte ich in zehn Jahren auch noch machen können oder im besten Fall eben auf endlos. Global wäre dann der Aspekt, dass das Ganze dann nicht nur im Kontext möglich ist, sondern möglichst kontextlos. Die globale Eindeutigkeit ist wichtig, aber das ganze System soll möglichst auch global nutzbar sein. KS: Gibt es Deiner Meinung nach ein Identifiersystem, von dem Du sagen könntest, das wäre genau dasjenige, das man für archivische Zwecke benutzen kann? MS: Es fängt natürlich immer irgendwo da an, wo man schon ist. Früher hat man sich da keine Gedanken gemacht und irgendwann steht man vor Problemen und denkt jetzt bräuchte man sowas wie einen Identifier und dann nimmt man erstmal das, was vorhanden ist. Das Zentrale sind Verzeichnungssysteme, also das was man heute AFIS nennt, wo die Archivalien verzeichnet sind. Zum einen hat man Signaturen, aber diese haben eben nicht die Persistenz im Normalfall. Signaturen werden geändert. Signaturen sind aus IT-Sicht schwer zu handhaben, die sind nicht so computerfreundlich. Also braucht man irgendeine Art von besseren Identifiern und dann bietet sich an, den internen Identifier aus dem Verzeichnungssystem zu verwenden. Bei uns wird ScopeArchiv verwendet. Der erste Ansatz ist, einfach die Scope-ID zu verwenden. Diese ist eine Ganzzahl, die hochgezählt wird. Mit jedem neuen Objekt, das man in Scope anlegt, wird die Zahl um eins inkrementiert. Die ist dann innerhalb der einen Scope-Installation eindeutig, also nur lokal eindeutig. Jetzt ist es so, dass das Landesarchiv Baden-Württemberg (LA-BW) ein Zusammenschluss von mehreren regionalen Archiven ist und es gibt bei uns mehrere unabhängige Scope-Installationen, die alle bei eins anfangen zu zählen. D.h., wir haben das Problem von global eindeutigen Identifiern, die man da schon ziemlich früh braucht. Hier hat man sich entschieden, den lokalen Identifier um einen Präfix zu ergänzen, um einen Teil, der globale Eindeutigkeit hat. Bei uns ist es so, dass die Scope-Installationen durchnummeriert sind und die globale Präfixnummer wird dem globalen Identifier vorangestellt und dadurch ist eine globale Eindeutigkeit gewährleistet, zumindest global im LA-BW. Das ist dann das, was bei uns AID heißt. Das System ist auch in die digitale Welt mit DIMAG übertragen worden. Das ist also genau das gleiche System. Wir haben einen lokalen Anteil und ergänzen den um einen globalen Präfix, der zentral vergeben wird. KS: Wenn ich das richtig gesehen habe, sind das doch Permalinks. Ist das das richtige Stichwort dafür? MS: Also Permalinks sagt mir nur etwas in Bezug auf unsere Website. Bei unseren Archivalien ist es, soviel ich weiß, immer so, dass die anhand der AID identifiziert sind: Irgendeine Zahl, Minuszeichen und irgendeine (meist größere) Zahl. Unsere internen Systeme kommunizieren auch mittels der AID, weil dann in allen LA-BW-Systemen klar ist, welches Objekt gemeint ist -- es ist klar, in welcher Scope-Installation und in der dann welches Objekt. KS: Wir sind also bei einer lokalen oder semilokalen Angelegenheit, wo es noch nicht darum geht, Dinge zu publizieren, sondern darum geht, zwischen Softwaresystemen zu kommunizieren. Die Frage, die für mich die zentrale ist, ist der Schritt von einem lokalen oder semilokalen System hin zur Publikation von Inhalten außerhalb des Systems z.B. für das Archivportal-D oder die DDB oder einfach nur als Präsentation auf einer Website. Da habe ich eben gesehen, dass das LA-BW Permalinks einsetzt, die grob gesagt für mich URIs sind, den typischen URI-Präfix haben und danach kommt dann die AID. Diese Konstruktion ist ja das, was der Nutzer von außen speichern kann oder benutzen kann. Das ist vielleicht jetzt schon eindeutig, genauso wie die AID intern eindeutig ist. Aber das Thema Persistenz ist ja noch nicht dabei. Es geht ja m. E. nur um die Eindeutigkeit. Wenn ich dich bisher richtig verstanden habe, geht es ja nur um die eindeutige Identifizierung und nicht um die Persistenz? MS: Genau, das muss man -- glaube ich -- als Entwicklung betrachten und der Übergang zur Publikation, das ist etwas, das erst jetzt passiert in den Archiven. Das Thema PIs für die Publikation, ist etwas, was erst im Entstehen ist, und die Kopplung von Softwarekomponenten im Archiv, das ist in den letzten Jahren schon passiert. Ich denke, das ist jetzt der nächste Schritt, mit dem Du dich beschäftigst. KS: Genau. MS: Da ist es wie immer, wenn neue Schritte gemacht werden. Es ist alles noch nicht ganz klar. Man fängt irgendwie beim Bekannten an und stellt Defizite fest, und versucht dann, die nach und nach zu lösen. Ich kenn die archivarische Publikationspraxis nicht so gut. Ich habe mich da erkundigt, was denn so üblich ist. Es scheint der Fall zu sein, dass man zitiert in recht sprechender Weise mit Archivnamen und Signatur und dann zunehmend mit URLs -- also Links in ein Onlinefindmittelsystem, das das Archiv mit anbietet. Das ist etwa die gleiche Form, wie also ob man ein Buch zitiert und schreibt hin Autor, Titel, Erscheinungsjahr und Auflage und einen Link zum Verlag mit dazu packt. Das hat Nachteile in der Eindeutigkeit. Man hätte gern eine größere Eindeutigkeit, vor allem aber auch eine maschinenverarbeitbare Eindeutigkeit und man hätte auch gern eine automatische Auflösung und Persistenz. Das ist da bislang nicht so wirklich gegeben. Die Persistenz eines Permalinks, die ist im Normalfall nur gegeben, so lang das CMS, das in der Website eingesetzt wird, oder das Onlinesystem, das man selber programmiert hat, lebt. Sobald man das umstellt, dann ist nicht klar, ob der Permalink noch funktioniert. Da geht man vielleicht von zehn Jahren aus oder so. Für mich sind PIs etwas, wo man in größeren Zeiträumen denkt und das auch Technologiewechsel überleben sollte. KS: Hast Du dich bereits mit den verfügbaren PI-System auseinander gesetzt? MS: Ich denke, es gibt zweieinhalb Arten von PI-Systemen. Es gibt zum einen die Möglichkeit, in irgendeiner Weise dezentral global eindeutige Identifier zu schaffen. Das ist der Ansatz, der mit der UUID gegangen wird. D.h., egal wo ich bin, habe ich ein Verfahren, um einen Identifier zu erzeugen, der höchstwahrscheinlich global eindeutig ist. Da ist z.B. die Zeit involviert und der Ort und irgendeine Zufallskomponente. Wenn man das alles mischt, kann man sehr wahrscheinlich sagen, dass es nicht exakt zur gleichen Zeit, nicht exakt am gleichen Ort und nicht mit exakt der gleichen Zufallskomponente nochmal einen anderen Identifier geben wird. Sobald eines von allem abweicht, ist der Identifier anders. Die Möglichkeit hat man. Der Vorteil ist, wenn man das Verfahren irgendwie implementiert hat, ist es sehr einfach, Identifier zu erzeugen. Es kann überall auf der Welt passieren, es kann dezentral passieren. Es braucht keiner Kommunikation zu einer zentralen Stelle. Der Nachteil ist, dass diese Identifier ziemlich lang sind. Die müssen lang sein, damit keine Kollisionen auftreten. Man braucht die Länge, weil man genügend Pufferraum braucht, weil sie nur deshalb eindeutig sind -- man braucht die Zufallskomponente und Zufall heißt immer, man muss ganz viel Raum zwischen den Zufallszahlen haben. Wenn ich jetzt eine Komponente von Werten auswähle, dann gibt es zu viele Kollisionen, also muss ich eine zufällige Komponente von ein paar Millionen auswählen, und deshalb werden meine Zahlen lang. Diese Art von Identifiererzeugung erzeugt immer lange Identifier, anders geht es nicht. KS: Was wäre die andere Variante von PI-Systemen? MS: Ein anderer Ansatz wäre, Identifier zentral zu vergeben. Wir können einfach sagen: An einer zentralen Stelle werden ID für die ganze Welt vergeben. Die muss man dann beantragen und dann bekommt man einen zurück. Bei so einem Verfahren ist es sehr einfach, weil ich kann das machen, wie das ScopeArchiv macht. Ich fange einfach bei eins an zu zählen und gehe immer eine Zahl weiter. Dadurch sind die ersten Identifier ziemlich kurz und sie werden länger. Aber sie werden nur so viel länger, wie es einfach notwendig ist. Also wir haben null Verlust drin. Wenn man dafür nicht nur natürliche Zahlen nimmt, sondern hexadezimal zählt, Zahlen und Buchstaben, dann erzeugt man sowas wie die Youtube-Links. Das ist einfach ein Hochzählen. Das haben die alles unter Kontrolle, das wird zentral vergeben. Dadurch werden sie ziemlich kurz. Der Nachteil ist, das ganze System hängt von einer zentralen Stelle ab. Man muss warten, bis man von da einen ID bekommt, man muss ihn da beantragen und wenn die Stelle ausfällt, kann keiner weiterarbeiten. Die dritte Variante wäre, dass man eine zentrale Stelle hat, dass die aber sowas wie Namensräume delegieren kann. Die kann dann sagen, ich vergebe nur einen Anfangsteil. Derjenige, der so einen Anfangsteil hat, kann darunter selber wieder etwas vergeben. Das ist ein hierarchischer Ansatz, den es zum Beispiel im DNS gibt, also Domain Names. Da werden die Top-Level-Domains wie ``de'', ``com'' und ``org'' zentral verwaltet und jede der Top-Level-Domains hat wieder Verwaltungen für Second-Level-Domains also für so etwas wie ``landesarchiv-bw''. Das wird dann verwaltet von der Verwaltung ``.de''. Uns gehört die Second-Level-Domain, wir können darunter weitere Domains anlegen. So wird das einfach delegiert. Wie ein hierarchisches Dateiordnersystem, wo man sagt, in dem Ordner darfst du machen was du willst, aber die Ordner daneben oder darüber werden von anderer Stelle verwaltet. Das schafft die Möglichkeit, die Zentralität runter zu brechen in kleinere Einheiten. KS: Wenn man mit der Delegation von Namensräumen arbeitet, ist es nicht so, dass man am Ende schnell wieder bei sprechenden PIs gelandet ist, weil diese Namensräume als solche aussagekräftig sind? Wenn jetzt ein bestimmter Namensraum das Kürzel ``de'' hat, dann ist es für den Nutzer, der einen PI sieht, schon eine sprechende Aussage und er weiß, ich befinde mich mit dem Kürzel in dem Namensraum einer bestimmten Institution: Der PI mit den Metadaten gehört zu dieser Institution. Aber am Ende ist es gar nicht so, weil das eben technisch verwaltet wird und es eben nichts mit dieser Institution zu tun hat. MS: Das verstehe ich. Meiner Meinung nach ist das strukturell ein anderes Problem. Was ich gerade skizziert habe, sind drei Wege, um global eindeutige Identifier zu erzeugen. Meiner Meinung nach kann man auf jedem Weg sprechende Identifier vergeben und kryptische Identifier. Wenn eine zentrale Stelle vergibt, dann kann die es erzwingen, dass die Identifier kryptisch sind. Wenn man so ein hierarchisches, delegierendes System verwendet, dann lässt es sich vielleicht nicht technisch erzwingen, aber dann kann man es per Policy erzwingen, also per Verhaltensregel. So etwas wie UUIDs könnte man auch sprechend vergeben, man macht es nicht, aber man könnte. Meiner Meinung nach ist das eine strukturell unabhängige Entscheidung. Es ist nur so, dass man es im einen Fall typischerweise auf die eine Art macht und im anderen Fall typischerweise auf die andere Art. Das ist aber keine technische Notwendigkeit. Das hat man sich so ausgesucht. Sprechende Identifier haben ein Problem, wenn sie persistent sein sollen. D.h., wenn sich irgendetwas ändert, darf sich der Identifier nicht ändern. Sobald sie sprechend sind, implizieren sie irgendetwas zu den Inhalten oder zu dem Ort, an dem sie sind usw. Weil sich das alles ändern kann, aber der Identifier sich nicht ändern darf, ist es schlecht, sprechende Identifier zu verwenden. KS: Du hast von drei Möglichkeiten der Verwaltung von Identifiern gesprochen. Das bezieht sich ja erstmal auf die Produktion eindeutiger IDs. Jetzt ist aber noch die Frage der Persistenz offen. Bei dezentraler Vergabe ist man doch schnell bei der Notwendigkeit, bei einer UUID noch irgendetwas davor zusetzen, um die in einem globalen System einzubinden. Ansonsten hat man ja das Problem, wenn dezentral eine UUID erzeugt wird durch eine Programmbibliothek, dass man dann ein Auflösungssystem davor schalten muss, um die UUID global zur Verfügung zu stellen. MS: Ich denke, das sind zwei Sachen. Zum einen die Frage der Persistenz und zum andern die Frage des Resolvers. Die Frage ist, was man zuerst angeht. KS: Das ist sowieso für mich eine grundsätzliche Frage, wie Du die Rolle eines Archivs innerhalb eines PI-Systems siehst. Wenn man die klassische Dreiteilung nimmt. Da ist dann auf der einen Seite die Datenquelle -- das Archiv --, der Resolving-Dienst und der Nutzer. Eine Frage ist zum Beispiel, ob man sein Archiv selbst einen Resolving-Dienst betreiben sollte oder ob man das trennen sollte oder welche Rolle ein Archiv beim Aufbau eines PI-Systems spielen sollte. MS: Es gibt m. E. zwei Arten, um einen Resolver zu implementieren. Die eine ist, das man diesen global hat. Wenn man UUIDs auflösen will, geht das glaube ich nur, wenn sie an einer Stelle alle verzeichnet sind. Denn die UUID kann überall auf der Welt sein und man kann anhand dieser nicht wissen, wo das sein kann. Das muss letztlich eine flache Liste sein, wo man in einer Spalte alle UUIDs stehen hat und in einer anderen Spalte die Orte, wo ich diese dann finde. Der Resolver schaut dann in der Liste nach und sagt, die UUID ist da. Ich weiß nicht, wie man da Teile delegieren sollte. Ich glaube, das funktioniert nur mit einem zentralen Resolver, wo man seine eigenen UUIDs hin melden muss, damit die da eingetragen wird. Es kann verschiedene Resolver geben, die können sich gegenseitig synchronisieren. Aber alle die UUIDs vergeben, müssten diese an einen zentralen Resolver melden. Das wäre der Weg, um Identifier von der Art ``dezentral generiert'' auflösen zu können. KS: Wenn wir nochmal über die Rolle einer UUID sprechen. Für mich ist eine UUID ein Identifikator, der nicht identisch sein muss mit dem Namen des Objektes. Wenn ich dich jetzt richtig verstehe, dann würdest Du schon sagen, das eine UUID der Name des Objektes ist, der irgendwo gespeichert wird und dieser dann dort im Resolvingdienst unabhängig vom Link, von der URL, die zum Objekt führt, verzeichnet ist. Der Nutzer würde dann sehen, hier gibt es eine UUID zu dem Verzeichnungsdatensatz und wird dann mit einem Link auf die tatsächliche UUID bei der Institution verlinkt. MS: Ja. Ich würde gerne noch wissen, weshalb Du das nicht als Namen von einem Objekt sehen würdest. KS: Der Identifiaktor ist der technische Name, der maschinenlesbar für das System hinterlegt wurde, und der kann ja einfach als xml-Metadatum eingetragen sein und kann als Identifikator genommen werden, muss aber nicht mit dem Dateinamen des Objektes übereinstimmen. MS: Genau so sehe ich das. Der Resolver würde eine Zuordnung von IDs zu Orten machen. Das ist für mich ein Resolver. KS: Ich habe bis jetzt noch nicht die Idee gehört, das man eine UUID nimmt, und dann die UUID nochmal als global eindeutigen Namen für diese Objekt verwendet. MS: Das würde ich nicht machen. Das Objekt hat einen Titel, Metadaten und die UUID. Aber der Name interessiert mich im Resolver überhaupt gar nicht. Gut, da kann ich irgendwelche Metadaten hinterlegen. Meiner Meinung nach ist die Aufgabe eines Resolver die Übersetzung von IDs zu Orten, man könnte auch sagen Auflösung von IDs zu Metadaten des Objektes. Aber in den Metadaten steckt letztlich ein Link zum Ort drin und am Ort sind ja alle Metadaten. Dass man Metadaten im Resolver hinterlegt, ist eigentlich eine Frage der Persistenz. Man will da eine Kopie halten, damit es ein bisschen sicherer ist. Aber die Hauptaufgabe eines Resolver ist für mich die Übersetzung einer ID zu einem Ort. Z.B. Ich habe eine Publikation, da ist auf irgendwas verwiesen, da steht irgendeine ID dabei. Die ID kopiere ich raus, werfe sie in den Resolver rein und finde so zu dem Objekt, egal wo es ist auf der Welt. Es könnte ein Link, sein sodass ich mir es runterladen kann, das kann eine Beschreibung sein ``in welchem Archiv mit welcher Signatur''. Das ist irgendeine Beschreibung, wie ich zum Ort komme. Im Falle von UUIDs müsste das ein globales Verzeichnis sein, in dem alle UUIDs enthalten sind. Wenn ich irgendeine UUID habe, in irgendeiner Publikation habe, dann kann ich nicht wissen, welchen der zwanzig Resolver ich verwenden soll, sondern es muss klar sein, ich verwende den UUID-Resolver für Archivalien. Ein bisschen Kontext wird man brauchen. Ich muss wissen, es ist eine Archivalie, ich verwende den UUID-Resolver für Archivalien, gebe die UUID ein und muss dann von diesem gesagt bekommen, wo es ist. Deshalb müssen alle UUIDs, die jemals für Archivalien vergeben worden sind, in dem einen UUID-Server für Archivalien drinstecken, von dem es dann vielleicht synchronisierte Klone gibt, aber es muss alles zentral gehalten werden. Das war der erste Fall: Wir vergeben IDs dezentral. Das wäre der Fall UUIDs. Der zweite Fall ist: Wir vergeben IDs zentral. D.h., wir nehmen einfach aufsteigende Zahlen, der Youtube-Fall. In dem Fall muss es auch einen zentralen Resolver geben, in dem alle drinstecken, nämlich alle, die die zentrale Stelle vergeben hat. Das wäre ein bisschen einfacher, weil die zentrale Stelle kennt sie ja schon alle, sie hat sie ja alle vergeben. Da fällt der Resolver quasi umsonst hinten raus bei diesem Ansatz, aber es muss auch den einen zentralen Resolver geben. Im dritten Fall mit dem hierarchischen dezentralen System wird die Auflösung schrittweise erfolgen. Man würde erstmal zur wichtigsten Komponente gehen und die sagt einem, wo man weiter gucken soll und dann hangelt man sich Stück für Stück weiter, bis man an der letzten Komponente ist und da ist dann der tatsächliche Ort hinterlegt. Da würde man einen Resolver hierarchisch aufbauen. Das ist genauso wie DNS, also dem Domain Name Service. Da gibt es auch Redundanzen, aber das würde man hierarchisch auflösen. Man hätte aber auch die Möglichkeit, es zentral aufzulösen. Das gibt es auch im DNS, es wird nicht alles hierarchisch aufgelöst, sondern wenn eine Anfrage im Cache ist, dann wird die gleich vom ersten Nameserver sofort beantwortet. Im dritten Fall hat man die Wahl, ob man zentral auflöst oder nicht oder einen Teil zentral auflöst oder nicht, da hat man alle Wahlmöglichkeiten. In den ersten zwei Fällen ist es nur möglich mit einem zentralen Resolver, der alle Daten kennt. KS: Das könnte jetzt deutschlandweit ein Dienst sein, der das übernimmt. MS: Ich habe vorher gesagt, es muss ein bisschen Kontext da sein. UUIDs gibt es für alles, nicht nur für Archivalien, und Ganzzahlen gibt es auch für alles. Man muss so viel Kontext haben, dass man weiß, es ist eine Archivalie und dass man weiß, es ist eine Archivalie aus Deutschland. Dann muss man zu dem passenden Resolver finden. Man muss irgendwie wissen, wie der heißt. Bei DOIs wird das so gelöst, dass die Leute in der Publikation nicht nur den Identifier angeben, sondern dass sie die URL vom Resolver mit dem Identifier als Parameter angeben. Da wird die Adresse vom Resolver immer gleich mit angegeben. Das wäre eigentlich nicht nötig, das hat sich aber so etabliert, weil es für Nichtinformatiker einfacher ist. Sonst wäre der übliche Fall, dass man das löst, indem man ``doi:'' davor schreibt oder ``urn:che:'' oder ``urn:nbn:'' oder ``http:'', das ist letztlich genau das gleiche System. Man schreibt davor, was es ist -- ``Protokoll'' heißt das in technischer Sprache -- oder die Art von Identifier und die hilft einem dabei, den passenden Resolver zu finden. Dann kann man da den hinteren Teil eingeben und der Resolver sagt einem dann, wo man das findet oder was es genau ist. KS: Wir haben uns jetzt schon sehr viel über die Syntax eines möglichen PIs unterhalten. Gehen wir zum Thema Objektassoziation. Hast Du eine Meinung zur Auffassung der Archivare, dass PIs auf abstrakte Entitäten und nicht auf konkrete digitale Objekte auflösen sollen? MS: Grundsätzlich kann man einen Identifier für alles benutzen. Je nachdem für welchen Verwendungszweck ist Unterschiedliches sinnvoll. Wir in DIMAG vergeben eine AID für jedes Objekt, das es bei uns gibt, weil wir das aus technischen Gründen brauchen. Wenn es um Publikationen geht im archivarischen Kontext, dann machen manche Identifier, die wir für Objekte vergeben, vielleicht wenig Sinn. Was ich mitbekommen habe ist das was du sagst: Der Identifier für die Intellektuelle Einheit wird benutzt für Publikationen oder sagen wir mal wird normalerweise benutzt. Aber je nachdem sind andere Identifier vielleicht auch wertvoll. Sagen wir mal, jemand würde in vielen Jahrzehnten eine Arbeit schreiben und analysieren, wie erfolgreich oder fehlerbehaftet Formatmigrationen in digitalen Archivierungssystem waren. So jemand würde einzelne Repräsentationen identifizieren wollen. Der bräuchte Identifier für Repräsentationen, weil er genau die Repräsentation 2 mit der Repräsentation 3 vergleicht und da will er nicht ``Repräsentation 3 vom Datum so und so'' hinschreiben, sondern er will einen Identifier, der eindeutig ist. Also es kommt darauf an, was man damit machen will, auf den Kontext, in dem man sich bewegt. In den meisten Fällen wird die Intellectual Entity das sein, was üblicherweise zitiert werden wird und wahrscheinlich auch sollte. Es gibt aber auch Bereiche, wo es Sinn macht, andere Einheiten zu referenzieren. Es kommt darauf an, mit was man sich dann wirklich beschäftigt. KS: Wenn wir schon bei der Assoziationsproblematik sind. Sagt Dir die Differenzierung zwischen Repräsentation und Version etwas? Bei PICHE wird ja oft von Repräsentation gesprochen. Würdest du das strikt auseinander halten? MS: Im Kontext von CHE sagt mir das jetzt nichts. Wir hatten aber bei DIMAG das Thema auch schon. Bei uns gibt es Repräsentationen und Versionen. Eine Repräsentation ist zur Bestandserhaltung da. Formatmigrationen führen zu Repräsentationen. Versionen sind da, um Fehler zu korrigieren. Wenn man feststellt, dass Metadaten falsch erfasst worden sind, dann würde man eine Version erzeugen oder wenn man feststellt, man hat aus Versehen die falsche Datei hochgeladen, dann würde man eine Version erzeugen. Version heißt im Normalfall im gleichen Format und Repräsentation heißt im Normalfall in einem anderen Format. KS: Wenn ich das richtig verstanden habe ist Version eine inhaltliche Veränderung und Repräsentation eine Veränderung der Verpackungsinformation bzw. der Dateiformatierung. MS: Ja genau, so könnte man das darstellen. Ich habe mich bisher schwer damit getan, so ganz hart zu definieren, weil in dem Bereich ist es sehr theoretisch. Bislang wurde nicht viel migriert und es sind auch sehr wenige Versionen, die erzeugt wurden. Es geht alles so in die Richtung, wie ich es jetzt skizziert habe, aber ich glaube, es ist zu früh, da ganz klare Regeln definieren zu können. In dem Fall ist es eine Version und in dem Fall sollte man eine Repräsentation machen. Da gibt es immer noch einen Spielraum, wo der Archivar entscheiden muss. Aber vielleicht werden wir in den nächsten Jahren mit mehr Praxiserfahrung dazu kommen können, das genauer festzulegen. KS: Wir hatten ja schon über sprechende Bestandteile in PIs gesprochen. Hältst Du es für sinnvoll sprechende Bestandteile überhaupt nicht in PIs aufzunehmen oder hältst Du es schon in einem gewissen Kontext für sinnvoll? MS: Was heißt sprechend? Sprechend heißt doch, dass man versteht, was da steht. Wenn Du eine UUID anguckst, verstehst Du überhaupt nichts und wenn Du eine IP-Adresse anguckst, verstehst Du auch nichts. Wenn ich eine IP-Adresse angucke, dann verstehe ich schon ein bisschen was und wenn Du eine AID anguckst, dann verstehst Du nichts und wenn ich eine AID angucke, dann verstehe ich schon ein bisschen was. Also sprechend ist nicht ja oder nein, es ist nicht binär, sondern das ist ein fließender Übergang und nicht-sprechend heißt einfach nur, dass man es nicht versteht. Aber UUIDs für jemand, der den UUID-Generierungsalgorithmus entwickelt, für den sind die sprechend. Der weiß, welcher Teil einer UUID auf dem Ort basiert und welcher Teil auf der Zufallszahl basiert usw. Deshalb darf man da nicht binär darüber diskutieren und DOIs sind aus meiner Sicht ein schönes Beispiel für eine Zwischenform. Die sind großteils ... na gut, lokal kann man dahinter irgendwas machen, was man will, das ist vielleicht nicht so gut, aber vorne werden Anteile vergeben, die einzelnen Institutionen zugeordnet sind. Das ist dann einfach irgendeine Zahl. Es heißt ja immer ``10.'' und dann kommt irgendeine Ganzzahl, dann kommt ein Slash und dann kommt der lokale Identifier. Die Ganzzahl dazwischen, die ist Institutionen zugeordnet, die den Namensraum dahinter kontrolliert. Sind die jetzt sprechend oder nicht? Wenn da ``LABW'' stünde, würden alle sagen, ja das ist sprechend, das ist das Landesarchiv. Aber wenn da ``1234'' drin steht und 1234 bedeutet LA-BW, dann kann man genauso sagen, das ist sprechend, es ist irgendwie schon klar, dass das das LA-BW ist, wenn ich das einmal weiß. KS: Genau das ist der Punkt. Vielleicht können wir uns darauf einigen, mit sprechend meine ich die Identifikation eines Ortes bzw. eines Namensraumes, zu dem ein PI gehört. Mit sprechend meine ich jetzt nicht einen Zeitstempel in einer UUID. MS: Ok, wenn ich es dann nicht-sprechend haben will, dann kann man keine Namensräume aufmachen, sondern dann gehen nur UUID-Verfahren, dezentral generiert -- etwas Kryptisches oder die zentrale Vergabe, wo alles ineinander vermischt ist, aber eine dezentrale Vergabe in einem hierarchischen System wird immer eine Komponente haben, die Rückschlüsse erlaubt. Das ist letztlich eine Interpretationsfrage. Wenn da ``LABW'' steht, heißt das ja nicht, dass da Ding uns gehört, sondern das heißt nur, wir haben es vergeben. Ich sehe schon das Problem, dass es falsch interpretiert wird, aber das ist vielleicht auch ein Problem der Lehre. Bei unseren AIDs ist es ganz klar, das wir den Präfix haben und der Präfix bedeutet nur, in dem System ist es geboren worden und bei uns gibt es in der Realität Fälle, wo Inhalte in andere Systeme gewandert sind und das heißt, in der DIMAG-Installation gibt es verschiedene Präfixe. Entscheidend ist nur: da ist es geboren worden. Das ist letztendlich bei DOIs genauso. Es wird meiner Meinung nach nicht angemessen kommuniziert, dass das die Bedeutung ist und weil das auch schwierig ist, unbedarften Leuten, die das zum ersten Mal sehen, klar zu machen, deshalb würde ich auch gegen natürlich-sprachliche Bezeichner sein. Da sollte nicht ``LABW'' drin stehen, weil das garantiert missverstanden wird. Ab wenn es irgendwelche Zahlen sind, dann wird es von Personen, die keine Ahnung haben, nicht missverstanden, und von Personen, die Ahnung haben, die sollen in dem Zug auch gelernt haben, was die Bedeutung ist, nämlich dass es da generiert worden ist. KS: Du würdest Dich also nicht festlegen wollen auf eine klare Strategie, spechende oder nicht-sprechende Identifier? MS: Genau, ich würde mich nicht festlegen, weil das aus meiner Sicht eine nachrangige Entscheidung ist. Für mich gibt es viel wichtigere Sachen, nämlich die Frage von zentral und dezentral. Denn ich denke, die sind sehr viel bedeutender als die Frage, ob man da irgendwelche Rückschlüsse von Zahlen auf Bedeutungen haben kann oder nicht. Ich nehme die Diskussion eher anders wahr, dass es für die Leute eher wichtiger ist, ob es jetzt sprechend oder nicht-sprechend ist, als Aspekte von Zentralität/Zentralisierung und Dezentralität. Wo wir uns einigen können: Dass es recht schlecht ist, wenn ein natürlich-sprachlicher Anteil drin ist. Da würde ich auch zustimmen. Es sollte nicht ``LABW'' drin stehen. KS: Warum ist Deiner Meinung nach die Diskussion zwischen zentral und dezentral viel wichtiger als die Diskussion über sprechende und nicht-sprechende PIs? MS: Zentral bedeutet doch, dass man einen Single-Point-of-Failure hat. Wenn die Vergabe wegbricht, wenn da etwas nicht funktioniert, aus welchen Gründen auch immer, dann kann kein anderer mehr arbeiten. Da kann man schon Redundanzen schaffen. Beim Resolver ist es recht einfach, da setzt man mehrere auf, die sich gegenseitig synchronisieren usw. Bei der Vergabe ist das ein bisschen schwieriger. Nehmen wir mal an, da möchten jetzt aus irgendeinem Grund innerhalb von kürzester Zeit sehr viele Systeme sehr viele PIs registrieren, dann kommt es zu Überlastungen. Man könnte sagen, ich registriere nur einen PI, wenn ich eine Publikation mache, ich als Techniker würde aber sagen: jedes Objekt, das ich habe, sollte einen haben, damit es einheitlich ist. Wenn ich schon PIs registriere, dann will ich die auch für meine interne Kommunikation nutzen, weil sonst habe ich ja einen internen Identifier und einen externen Identifier, dann muss ich die synchron halten usw. -- am liebsten also nur einen Identifier. Dann bedeutet das aber, wenn ich ein Objekt bei mir lokal anlegen will, muss ich in Echtzeit mich an die zentrale Stelle wenden und sagen, ich hätte gern einen Identifier, kriege den zurückgeliefert, speichere bei mir das Objekt in Echtzeit ab. Wenn es erfolgreich abgespeichert ist, dann aktualisiere ich die Metadaten nach oben an die zentrale Stelle. Das muss alles in Echtzeit passieren und wenn es da Verzögerungen gibt, kann ich meinen Import von 10.000 Objekten nicht machen oder dann braucht der eben Tage, weil die zentrale Stelle irgendwie eine Lastbegrenzung drin hat, damit sie nicht überlastet wird usw. Also da sehe ich einfach einige Probleme, die zentralen Systemen immer inhärent sind. Man kann technische Maßnahmen ergreifen, um das abzumildern, aber ein zentrales System hat einfach immer solche Probleme. KS: Wenn man globale PIs dem Nutzer bereitstellen möchte, ist es nicht so, dass man immer auf eine gewisse Ebene der Zentralität gehen muss? MS: Das stimmt schon. Eine gewisse Zentralität braucht man und sowas wie ein DNS hat auch 14 Root Name Server. Es sind 14 Stück, damit die gewisse Redundanzen schaffen, aber die müssen bekannt sein und die sind in jeder Nameserver-Implementierung mit IP-Adressen hinterlegt. Also die müssen überall bekannt sein. Das ist das zentrale Element und in einer solchen Weise ist das auch für dezentrale Resolver nötig ... Dezentral vergebene IDs, die muss man auch irgendwann mal melden an irgendeine Stelle, und man muss ja auch irgendwann mal Namensräume beantragen. Ich bin der Meinung, man darf nicht so schwarz-weiß über das Thema diskutieren. Ich bin der Meinung, dass die Frage zu Zentralität und Dezentralität, wichtig ist, aber ich bin auch da nicht der Meinung, dass sie binär ist. Ich glaube nur, dass es der wichtigere Aspekt ist im Vergleich zu der Sache, ob man jetzt irgendwie wissen kann, dass ``1234'' für das LA-BW steht. Das ist aus meiner Sicht ziemlich nebenrangig. Meine Wahrnehmung ist eher, dass die Diskussion anders herum ist, und da bin ich nicht ganz einverstanden. Man muss schon unterscheiden, ob da ``LABW'' dran steht oder ``1234'' dran steht, also so offensichtlich natürlich-sprachliche Anteile im PI, wie ``LABW'', das glaube ich, ist schlecht. KS: Mich interessiert immer noch die Unterscheidung zwischen Innen und Außen bei lokalen Systemen, die PIs verwenden. Ich glaube, wir reden immer noch sehr stark von der Innenperspektive eines Systems. Ich stelle mir jetzt verschiedene Archive vor, die miteinander kommunizieren bzw. deren digitale Archive, die mit einander kommunizieren. Dort gibt es dann für die verschiedenen Objekte diese IDs, das können dann UUIDs sein und die werden dann irgendwie hin und her geschickt. Aber mir fehlt immer noch ein bisschen die Bewegung im Internet. Wie stellst Du Dir vor, könnte ein Resolving-Dienst funktionieren, der entweder zentral oder dezentral die PIs verwaltet? Wie könnte der aufgebaut sein, welche technischen Komponenten könnten da enthalten sein? MS: Ich muss zugeben, mit Resolvern habe ich mich bisher am wenigsten beschäftigt, weil das aus meiner Sicht der einfachste Teil ist. Ich kann mir zwei Modelle vorstellen. Das eine Modell ist ein hierarchisches Modell, da würde ich mich einfach an das DNS anlehnen. Das ist etabliert, das gibt es seit Jahrzehnten und das funktioniert. Da gibt es eine große Community, die sich damit befasst. Das ist standardisiert, da gibt es RFCs dazu, also Definitionen und Spezifikationen, und da gibt es Weiterentwicklungen, die auf Defizite eingehen, z.B. Vertrauenswürdigkeit. Da würde ich mich einfach an die anlehnen, das als Ausgangsbasis nutzen, wenn ich den dezentralen Ansatz fahren wollen würde, oder wenn meine anderen Entscheidungen so sind, dass die den nahe legen. Wenn ich den zentralen Ansatz wählen würde, dann würde ich mich an PGP Keyservern orientieren, weil das ein zentrales System ist und weil die eine starke Ausfallsicherheit hat. Das sind beliebig viele Server, die sich gegenseitig synchronisieren. Man kann seine Daten bei einem beliebigen Server einspielen und nach einer gewissen Zeit tauchen die überall auf. Da kenne ich die RFCs jetzt nicht auswendig, aber da gibt es garantiert auch welche, wie man solche Server aufsetzt und in welcher Weise die kommunizieren. Das wäre aus meiner Sicht die Ausgangsbasis, wenn ich ein zentrales System aufsetze. Ich würde gucken: Wie sieht das konzeptionell aus? Wenn es so ist wie bei Keyservern, dann würde ich es gleich machen. Natürlich speichere ich andere Daten rein, aber für den strukturellen Aufbau, für das System, wäre es jenes System, an dem ich mich orientieren würde, weil es existiert, weil man da Erfahrungswerte hat und weil es da eine Community gibt, die sich darum kümmert. Das ist für mich eine wichtige Komponente. Man sollte gucken, nicht alles selber zu erfinden, sondern das zu nutzen, was es schon gibt und was etabliert ist und wo andere, vor allem Spezialisten, sich damit befassen, es besser zu machen und sich drum kümmern. Dann würde man versuchen, das ganze konzeptionelle Wissen, das die schon erarbeitet haben, zu übertragen auf die eigene Fachdomäne. KS: Siehst Du Schwierigkeiten bzw. Probleme für PICHE, die noch nicht gelöst sind? MS: Ich habe das so mitbekommen, dass man angefangen hat mit einem dezentralen hierarchischen Ansatz und ist davon weggekommen zu einem zentralen Ansatz und hat sich jetzt zu einem abgeschwächten zentralen Ansatz weiterentwickelt. Das finde ich im Rahmen der Gegebenheiten ganz in Ordnung. Das kann so funktionieren. KS: Wo siehst Du den Vorteil zu dem komplett zentralen oder komplett dezentralen Ansatz? MS: Der dezentrale Ansatz hat durchaus die Schwäche, dass einiges über Policies gelöst werden muss also durch Vorgehensvorgabe und man kann nicht so einfach technisch verhindern, dass klartextsprechende ID-Anteile vergeben werden. Wenn ich mir das Fach-Know-How anguck in kleinen Archiven und Museen, kann ich mir gut vorstellen, dass das schlecht funktioniert. In 10 Jahren oder 15 Jahren, wenn dann das Know-How da ist, wenn dann die Erfahrung da ist, dann sieht das vielleicht nochmal anders aus. Dann kann man auch mehr über Policies regeln. Aber in so einer Anfangsphase, wo sehr viele Beteiligte eigentlich noch gar nicht verstanden haben, wie das eigentlich funktioniert, weil es einfach zu neu ist, weil sie da erst reinkommen, also verständlicherweise das Know-How noch nicht haben und die Erfahrung nicht haben, da ist es vielleicht besser, wenn man mehr technisch erzwingt. Deshalb kann ich den Übergang zu einem zentraleren Ansatz verstehen. Der ist nicht ganz abwegig. Wo ich Probleme gesehen habe und wo ich Probleme bei uns im Landesarchiv gesehen habe, war, dass man dann von einem Ende des Spektrums in das andere Ende gesprungen ist: von ``wir machen alles frei in den Unternamensräumen und alles sprechend'' zu ``wir vergeben nur noch UUIDs''. Gerade in der DIMAG-Community hat das eben doch ein sehr großes Akzeptanzproblem, weil bei uns seit Jahren AIDs genutzt werden und erfolgreich genutzt werden und die bei uns alle Anforderungen erfüllen, die ein globaler Persistenter Identifier haben muss und es für uns natürlich auch schwierig ist, wenn wir hier etablierte funktionierende Systeme haben seit einigen Jahren, die die Probleme innerhalb der DIMAG-Welt alle schon gelöst haben, und jetzt sollen wir bei einem System mitmachen, das die Probleme auf eigene Art und Weise neu löst, und wir müssen dann alles doppelt halten. Das ist etwas schwierig. Da ist schon die Frage, mit welchen IDs man intern arbeitet und wenn unsere Systeme mit AIDs arbeiten, dann sagt die Erfahrung, nutzen die Nutzer auch AIDs. Dann zitieren sie eben doch nicht mit der URN:CHE, mit der UUID. Da muss man nur in die Wikipedia gucken! Wie wird die Wikipedia zitiert? Mit URL und Datum und nicht mit dem Permalink, der aber in der linken Leiste von Wikipedia extra erwähnt ist. Da gibt es ein Verfahren, wie es gemacht werden sollte, aber keiner macht es so. Alle machen es stattdessen wie sie es gewohnt sind, und ich glaube, das zieht sich immer durch. Es funktioniert nicht, gegen die Gewohnheit der User irgendetwas tolles Neues einzuführen, von dem sie keine direkten Vorteile haben. Und so denke ich auch, wenn ein Archivnutzer immer AID verwendet bei uns, dann machen die das auch, weil die Mitarbeiter das so machen, dann werden sie das auch in ihrer Publikationspraxis so machen. Also muss der interne Identifier auch der *persistente* Identifier sein. Wenn man bloß etwas zusätzlich macht, dann muss es genug Mehrwert bieten, aber unsere AIDs sind schon persistent. Der URN:CHE bietet dann keinen Mehrwert, wenn die AID da nicht eingebettet sein kann. Also wird es sich nicht durchsetzen und dann denke ich, dann wird es eine Totgeburt. Dann braucht man nicht anfangen. Das ist mein Erfahrungswissen und meine Meinung, wie es nachher laufen wird. Für welche, die noch gar keinen persistenten Identifier haben, da würden sich URN:CHE UUIDs durchsetzen, weil das dann die einzige Art ist, wie man persistente IDs hinkriegt, aber in einer Welt, wo es das alles schon gibt, und wo die neue ID zudem noch viel mehr Zeichen hat und noch viel schwieriger abzutippen ist, wird sich das einfach nicht durchsetzen, denke ich. KS: Ich bin gerade noch an diesem Punkt der Persistenz hängen geblieben. MS: Ja, da haben wir noch gar nicht darüber geredet. KS: Mich interessiert schon sehr, inwiefern Du die AIDs als persistent bezeichnest, gerade im Hinblick auf externe Nutzer. MS: Was heißt Persistenz? Es heißt, dass das gleiche Objekt dauerhaft unter dem Identifier identifizierbar ist oder erreichbar ist. Dass das abstrakte Objekt dauerhaft diesen Identifier hat. Das ist Persistenz. Meistens, wenn es um Persistenz geht, wird als erstes an den Resolver gedacht. Wenn man den Identifier da eingibt, dann soll der auflösen. Das sei Persistenz. KS: Genau. Das ist auch meine Vorstellung von Persistenz. MS: Aber Persistenz fängt da an, dass das abstrakte Objekt dauerhaft den Identifier hat. D.h. also, das fängt mit einer Policy an, dass niemand in seinem System irgendwie das Objekt wegmachen kann und neu hinmachen kann und dann hat es einen anderen Identifier. Sondern es muss in den Vorgängen und in dem Verständnis der Archivare klar sein, was so ein persistenter Identifier bedeutet, nämlich dass er der dauerhafte Name von dem Abstrakten Objekt ist, egal wie er technisch aussieht \&... oder das technische System muss so angelegt sein, dass er eben erhalten bleibt. Das zweite ist dann, dass er über den Zeitraum der Existenz des Systems erhalten bleibt. Das kann man dann am Einfachsten vielleicht so lösen, dass man die wichtigste Beschreibung einfach kopiert in einen Resolver und der Resolver kümmert sich um die Persistenz. Wenn man den Resolver nicht abschaltet und da dort die Metadaten hinterlegt sind, dann können alle lokalen Systeme draufgehen -- völlig egal -- das Objekt ist ja immer noch da. Es ist nämlich da, weil da irgendwelche Metadaten in dem Resolver drin sind. Aber das ist eigentlich recht oberflächlich -- es ist wertvoll und einfach umzusetzen, das spricht dafür, aber eigentlich sollte das Konzept tiefer gehen, nämlich das Verständnis, dass das Objekt selber, also nicht nur irgendein Resolver, der nur Metadaten hat, sondern das Objekt selber Dauerhaftigkeit hat, egal in welchem technischen System es steckt. Die Dauerhaftigkeit sollte eigentlich im Archiv schon gegeben sein und wenn sie im Archiv gegeben wäre, dann bräuchte sie der Resolver gar nicht bieten, dann wäre sie schon da. Wir sind ja noch sehr früh in der Entwicklung und wie ich gerade schon gesagt habe, die Archive sind oft noch gar nicht soweit und die IT-Systeme in den Archiven auch nicht. Also ist es sicher ein guter Ansatz zu sagen, ein paar Experten bauen einen Resolver und sorgen dafür, die Persistenz zu bieten, quasi übergangsweise so lange bis die Archivsysteme mal soweit sind, bis diese das bieten. KS: Ich bin ein wenig durcheinander gekommen. Wenn wir von der Persistenz eines abstrakten Objektes sprechen, dann ist das abstrakte Objekt nur repräsentiert durch Metadaten und durch seine Repräsentationen. D.h., wenn da irgendetwas persistent vorhanden ist, dann in erster Linie die Repräsentation der Metadaten bzw. verschiedene Repräsentationen mit diesen Metadaten bzw. selbst im Resolver hinterlegt sind. Das geht ja wieder auf die Frage zurück, was ist eigentlich das zu identifizierende Objekt. Damit dann verbunden auch die Frage, was dann da vorgehalten wird. MS: Das abstrakte Objekt mit seiner Beschreibung ist in erster Linie im Archivinformationssystem existent und im Resolver ist eine Kopie davon. Ich bin der Meinung, die primäre Datenhaltung, die sollte die Persistenz bieten. Dort sollte der Identifier dauerhaft mit der Objektbeschreibung verknüpft sein. Der Resolver ist aus meiner Sicht ein Hilfsmittel, der ist nachgelagert. Jetzt ist es aber eher so, dass die Archivinformationssysteme das heutzutage noch nicht bieten und deshalb versucht man die Persistenz in erster Linie über den Resolver bereitzustellen. So würde ich das bewerten. Das ist eine Übergangslösung. Das ist für mich nicht das Ziel, wo wir hinwollen. Sondern das Ziel, wo wir hinwollen, wäre aus meiner Sicht da, wo das Objekt primär lebt und das wäre das Archivinformationssystem. Da sollte die Persistenz geleistet werden und nur wenn man es da nicht schafft, und das ist momentan der Fall, weil wir am Anfang von dem Ganzen sind, machen wir es daher an anderer Stelle. Aber es wäre viel besser, wenn das AFIS das schon bieten würde. KS: Ist das nicht genauso das zentrale Thema eines Users. Ich kopiere einen Link und möchte dann den über den Browser auflösten und ich bekomme den 404er, Objekt nicht mehr aufzufinden. Das ist doch jetzt schon primär eine Frage der Persistenz der Verlinkung. Insofern die Verlinkung gegeben ist, ist es doch möglich bei einem Metadatensatz vor Ort irgendwelche Änderungsangaben in diesen Metadatensatz oder eine neue Version dieses Metadatensatzes dem Nutzer anzugeben. Ich verstehe nicht ganz, warum das jetzt zentraler sein soll als die Verlinkung, warum das der bedeutendere wichtigere Punkt ist. MS: Die Verlinkung hat für mich gar nichts mit persistenten Identifiern zu tun. Permalinks sind für mich auch keine persistenten Identifier. Der persistente Identifier ist nur das Ding hintendran, die Zahl, die AID, die UUID. Und das davor -- irgendeine http-Adresse -- hat nichts mit dem Identifier zu tun. Wenn da ein Permalink verwendet wird, dann ist das für mich nur ein lokaler Resolver, aber wenn da dran steht ``aid:'' und irgend so eine AID kommt, das ist der Identifier. Und der Identifier hat keinen eingebauten Resolver, sondern man braucht einen Resolver, um den aufzulösen. Der Resolver kann sein eine zentrale Website, der kann sein die Website von dem entsprechenden Archiv, der Resolver kann auch ein Archivar sein, der das im Kopf macht, oder ein Magaziner, also das Auflösen, das ist ein technischer Vorgang. Aber der Identifier ist wirklich nur der Identifier und immer wenn da ``http:'' davorsteht, dann ist das ein Resolver. Permalinks brechen deshalb, weil der Resolver mit eingebaut ist. Der vordere Teil ist der Resolver, also die Adresse vom Resolver, und hinten dran ist der Identifier, der bei einem Permalink irgendeine Zahl oder so etwas ist. Aber der Identifier ist nur das Hintere. Dass der eingebaute Resolver irgendwann einmal nicht mehr funktioniert, davon muss man ausgehen. Auch die zentrale Website, die das Bundesarchiv oder so betreibt, die wird in 30 Jahren vielleicht nicht mehr da sein, weil es kein HTTP mehr gibt, dann heißt es HTTPS ... weil es vielleicht gar kein HTTPS mehr gibt ... weil es kein Web mehr gibt ... weil man zukünftig über Whatsapp resolved oder über Facebook -- völlig egal. Resolver sind an Technologien gebunden und die veralten. Aber Identifier, das ist etwas Abstraktes, das ist losgelöst der String, die Zeichenfolge, die kann man in 30 Jahren auf Variante y auflösen und in 50 Jahren auf Variante z. KS: Ich frage mich aber immer noch, inwiefern sich das mit Uniqueness bzw. Einzigartigkeit nicht doch ein bisschen überschneidet. Der PI, der als Name vergeben wurde und eindeutig ist, der unabhängig von einem Resolving-Dienst existiert, ist genau das nicht damit gemeint? Und wird dann Persistenz nach Deiner Aussage nicht einfach hergestellt, indem der Identifier unique ist bzw. weltweit eindeutig oder würdest Du das anders sehen. Für mich hat sich bisher die Persistenz bisher immer auf die Auflösbarkeit bezogen. Es ist klar, dass die Auflösung verschiedene Dienste haben kann, das DNS kann veralten oder es in 20 Jahren gar nicht mehr, und dass ein PI in 20 Jahren anders aufgelöst werden muss und wir nicht wissen, wie es aussehen wird. Diese Art von Persistenz verstehe ich einfach noch nicht. MS: Ich glaube Persistenz ist etwas, was entsteht, wenn alle beteiligten Personen und Systeme gewissen Verhaltensweisen folgen. Dann entsteht Persistenz. Wenn sie sich nicht so verhalten, dann ist keine Persistenz da. Wenn ich mich heute Markus nenne und morgen Tom, dann ist da keine Persistenz da, und wenn irgendein System mich heute Markus nennt und morgen Tom, dann genauso wenig, oder wenn die Gesellschaft plötzlich der Meinung wäre, dass die Namen jedes Jahr wechseln sollten. Ich glaube, das hängt an Verhaltensweisen und wenn die gegeben sind, dann entsteht Persistenz. Das ist eine Verpflichtung, wie eine Verpflichtung zu Ehrlichkeit oder stimmigen Verhalten oder so. Es müssen alle mitspielen nach den gleichen Regeln. Deine Perspektive auf Persistenz ist technischer geprägt und aus meiner Sicht wäre das dann der Fall: man will eine dauerhafte Zuordnung von dem Identifier zu der Beschreibung und die Zuordnung will man in irgendeiner Weise haben, dauerhaft. Da könnte man sagen, dass irgendein Resolver die dauerhaft bietet und wenn es die Technologie nicht mehr gibt, dann muss irgendein neuer Resolver die Daten übernehmen und das dauerhaft anbieten. Ich bin der Meinung, das kann man so machen. Ich bin aber der Meinung, dass es am sinnvollsten wäre, an der Quelle anzusetzen, an den Master-Daten, und dass man da genau das bieten sollte ... dass unser AFIS dauerhaft die Zuordnung von dem Identifier zu den beschreibenden Metadaten leistet und wenn wir ein neues AFIS haben, dann muss die Zuordnung weiterhin gewährleistet werden. Das widerspricht dem Resolver gar nicht. Das kann beides parallel sein. Das ist auch gut. Je öfter es da ist, desto mehr Ausfallsicherheit haben wir. Es sind einfach Kopien vom Gleichen. Aus meiner Sicht ist das lokale AFIS, also dort wo die Daten zum ersten Mal erfasst werden, das ist der Master, und es ist am besten wenn der Master sich schon richtig verhält, und nur wenn er sich nicht richtig verhält, dann sind wir auf irgendwelche nachrangigen System angewiesen. Die können sonst auch dabei sein, aber ich würde immer an der Quelle ansetzen. KS: Es kommt mir vor, als ob wir nur einfach da unterschiedlich gewichten. Du würdest jetzt sagen, Persistenz liegt bei der Quelle. Die Datenquelle muss in sich erstmal die Persistenz generieren, damit ist es gar nicht so wichtig, wie ein Resolving-Dienst von außen darauf zugreifen kann. Ich würde sagen, der Resolving-Dienst ist das zentrale und die Verlinkung zur Quelle hin ist entscheidend. MS: Du guckst mehr aus Nutzersicht drauf. Da macht das Sinn, weil der Nutzer hat mit dem AFIS nichts zu tun, der hat mit dem Resolver etwas zu tun. Ich finde, du hast das noch einmal gut zusammengefasst. Ich glaube, es ist größtenteils eine Frage der Perspektive und ich habe schon sehr abstrakt und grundsätzlich darüber gesprochen. Du beschäftigst Dich ja doch ein bisschen mehr mit einer konkreten Situation. Ich würde sagen, solange der Resolver die Persistenz bietet, dann ist das in Ordnung. KS: Vielleicht kann man versöhnlich für beide Perspektiven sagen, ich glaube, man muss beide Perspektiven durchsetzen. Sowohl die lokale Persistenz, das etwas ist, was man langfristig bei den Archiven als eine Art Haltung oder als ein Verhalten fördern muss und als Wert weiter beizubehalten. Das andere ist vielleicht auch, dass ein technischer Rahmen geschaffen wird, der dem Nutzer eine eineindeutige Zitierweise möglich macht für z. B. e-Publikationen, die dann auch langfristig das lokale Objekt verlinken. Ich glaube, das sind wirklich zwei Aspekte, die sich da nicht in die Quere kommen, sondern beide sind wirklich gleich bedeutsam. MS: Ja, da gibt es meiner Meinung nach keinen Konflikt zwischen den beiden Bereichen. Man sollte auch beide Wege weitergehen. Und das ist meiner Meinung nach sowieso das beste Vorgehen in so einem neuartigen Bereich. Bei der Digitalen Archivierung, da ist ja alles neu. KS: Am spannendsten finde ich den Punkt der Ausfallsicherheit und darauf zu achten, dass bei einem zentralen Resolving-Dienst durch eine Überlastung des Systems Ausfälle verursacht werden können. MS: Das ist schon ein sehr technischer Aspekt. Damit beschäftigen sich Informatiker, wenn sie Kopplungen zu solchen Systemen herstellen. Es kommt ein bisschen darauf an, ob man sagt, wir probieren mal ein bisschen was, oder ob man sagt, wir versuchen das System der Zukunft zu designen. Wenn man sagt, man probiert einfach mal was, dann kann man gucken, was passiert und dann wird man eben nachkorrigieren. Aber ich sehe bei PICHE eher, dass sehr viel Energie investiert wird in etwas Langfristiges. In dem Fall bin ich der Meinung, dass es sehr wichtig ist, dass man Handlungsoptionen hat, Sachen auch umzustellen, wenn nämlich die Praxis zeigt, dass etwas nicht so einfach ist, wie man es gedacht hat. Jetzt kann man sagen, Archivalien interessieren ja niemanden. Aber wer weiß ... stellen wir uns mal einen gezielten Angriff vor durch Überlastung, wo der Resolver angegriffen wird durch eine massive Überlastung durch Anfragen, sowas wie Botnetze, die von verschiedenen IP-Adressen derart viele Anfragen stellen, die der Server einfach nicht beantworten kann. Dann haben wir eine Denial-of-Service-Attacke und der Resolver ist nicht mehr nutzbar. Da muss man zwangsläufig Redundanzen schaffen. Genauso kann so ein Denial-of-Service-Angriff erfolgen bei der Registrierung von IDs. Da kann man die Redundanz nicht so einfach schaffen. Ich glaube, man muss so etwas im Blick behalten und man sollte, wenn man mit einer langfristigen Perspektive designt, sich Hintertüren offenhalten. Als Telefonnummernvorwahlen vergeben worden sind, ist der Nummernbereich 01 nicht vergeben worden. Den hat man sich mal reserviert und später ist der dann für Handys genutzt worden. Man braucht immer wieder Räume, um nachjustieren zu können, wenn man langfristig denkt. Wenn man kurzfristig denkt, wird man das Alte einfach wegwerfen und was Neues machen. Genauso ist es mit dem UUIDs. Da denkt man jetzt: UUIDs das ist super. Aber wie lange werden UUIDs unique sein? Ich habe gesagt, da ist viel Zufall drin und man hat da Pufferräume, dass es keine Überschneidungen gibt, aber es werden ständig UUIDs geboren. Die sind jetzt nicht alle im Archivumfeld verortet, aber wann werden die Kollisionen zu viele? Ist das in fünf Jahren? Ist das in zwanzig Jahren? Wenn man ein System einführt, das nur UUIDs kann, dann muss man in 20 Jahren vielleicht sagen, jetzt müssen wir es wegwerfen. Deswegen war mir an der Sache wichtig, dass es die Möglichkeit gibt, den Identifiertyp auszutauschen, was es für uns dann ermöglicht, dass man UUIDs und AIDs parallel nutzt, aber zukünftig auch erlaubt, UUID2 -- oder was auch immer dann in fünf Jahren entwickelt wird -- zu nutzen und umzusteigen. Das ist etwas, was eigentlich alle technischen Systeme haben, z.B. dass Verschlüsselungsalgorithmen austauschbar sind. Alle, die mit nur einem angefangen haben, die haben irgendwann mal umgestellt, weil man mehrere braucht. Das hat mir gefehlt, als man bei URN:CHE auf die zentrale UUID hingezielt hat. Das ist natürlich das einfachste, ich glaube es ist aber auch wichtig, immer die Handlungsmöglichkeiten für die Zukunft offen zu halten. Was machen wir, wenn die zentrale Vergabe nicht funktioniert? Und das stellen wir in fünf Jahren fest. Was machen wir dann? Müssen wir unser System dann wegwerfen oder können wir unser System so anpassen, dass es auch dezentral nutzbar ist. Das ist für mich ein wichtiger Aspekt, dass man das bedenkt und möglichst wenig harte Ausschlussentscheidungen am Anfang trifft, wenn das möglich ist. Ich glaube, man könnte zum Beispiel sagen, wir fahren das zentrale System, aber wir legen einfach einen Unternamensraum an und da legen wir alles rein und wenn wir feststellen, dass wir dezentral gehen wollen, dann können wir beliebig weitere Unternamensräume anlegen und hätten die Möglichkeit, das Ganze auch dezentral zu fahren. Manchmal hat man Möglichkeiten, sowas zu machen wie beim Telefon, dass man sagt, man vergibt alles, aber die 01 als Vorwahl nicht und dann kann man später alles umstellen und anpassen. KS: Mhm ... MS: Aus meiner Sicht nochmal eine kurze Zusammenfassung von dem, was wir besprochen haben. Ich glaube, ich habe ziemlich viel auf die strukturelle Analyse von Persitent Identifiern geguckt. Ich habe versucht, das strukturell runter zu brechen, welche Varianten man zur Auswahl hat, welche Vor- und Nachteile es gibt. Ich habe versucht zum Ausdruck zu bringen, dass man an verschiedenen Stellen Wahlmöglichkeiten hat und dass die Wahlmöglichkeit in den seltensten Fällen binär ist, sondern dass es im Normalfall ein Abwägen ist und dass es Zwischenformen gibt. Ich habe keine großen Empfehlungen gegeben. Ich habe sowas gesagt, wie dass klartextsprechende Namen eher schlecht sind, aber ich habe das ganze Thema eher auf einer abstrakten Ebene analysiert. An ein paar Stellen bin ich auf konkrete Fälle eingegangen mit beispielhaftem Charakter und dann habe ich immer wieder gesagt, dass das Ganze ein neues Feld ist, dass man in der Entwicklung ist, dass man Sachen ausprobieren muss, dass nicht immer alles ideal ist und dass es auch Zwischenformen braucht, um voran zu kommen. Ich wollte auch insgesamt den Eindruck erwecken, dass man hier nicht unbedingt mathematisch vorankommt, sondern dass da ein Prozess im Laufen ist, wo auch gelernt werden muss von allen Beteiligten, wo es mir aber schon wichtig ist, dass man versucht, die richtigen Ziele anzustreben und einen klaren Blick zu bewahren auf das, was passiert. KS: Vielen Dank für das Gespräch!