TextGrid Architektur

Transkript

1 TextGrid Architektur Versin Januar 2007 Arbeitspaket AP 3, Reprt 3.2 verantwrtlicher Partner SUB, DAASI TextGrid wissenschaftliche Textdatenverarbeitung ein Cmmunity Grid für die Geisteswissenschaften

2 Prjekt: TextGrid Teil des D Grid Verbundes und der deutschen e Science Initiative BMBF Förderkennzeichen: 07TG01A H Laufzeit: Februar 2006 Januar 2009 Dkumentstatus: stabil und eingefrren, wird kntinuierlich weiterentwickelt Verfügbarkeit: öffentlich Autren: Andreas Aschenbrenner, SUB Peter Gietz, DAASI Martin Haase, DAASI Frank Knll, DAASI Christph Ludwig, FH Wrms Wlfgang Pempe, Saphr Markus Sst, Saphr Thrsten Vitt, TU Darmstadt

3 Inhaltsverzeichnis Inhaltsverzeichnis....3 Überblick Benutzerumgebung Service Layer Middleware Abstraktinsschichten TextGrid API WSDL WSRF GAT/SAGA TextGrid spezifische Basisdienste zur Datenverwaltung...13 Datenhaltung DMS Metadaten Textanntatinen und Adaptren Schichten übergreifende Grid Dienste Authentifizierung, Autrisierung, Rechte, Sicherheit wrkflw, scheduling, resurce brkerage Service Level Management Archive Metadatenintegratin Archiveinbindung Datenimprt Grid Anschluss Cnclusi Anhang: Architektur Skizze ( )

4 Überblick TextGrid ist ein Infrastrukturprjekt, das auf Grid Technlgien aufbaut. Es bedient eine Cmmunity aus den Geisteswissenschaften und versteckt dabei die Kmplexität der Technlgie weitestgehend. Angelehnt an das Paradigma der Service Oriented Architecture, kmbiniert TextGrid dazu Grid Technlgien und Web Services in einer ffenen Schichtenarchitektur. Dieses Dkument gibt einen glbalen Überblick über die TextGrid Architektur. Es baut dabei auf die Analyse der Bedürfnisse der Cmmunity in den "TextGrid Szenarien" 1 genaus wie auf die aktuellen Entwicklungen in der Grid / (Semantic) Web Cmmunity. Diese Referenzarchitektur definiert den technischen Rahmen und die Terminlgie, nach der die weiteren Prjektphasen arbeiten, auf einem entsprechenden Abstraktinsgrad. Eine Feinspezifikatin für die in den Szenarien und in diesem Dkument identifizierten Einzelkmpnenten existiert bereits ansatzweise an separater Stelle und wird während der TextGrid Prjektlaufzeit sukzessive frtgeführt (s.a. die Reprts zu AP2). Aus den in den Szenarien entwickelten Anwendungen und Kntexten ergeben sich aus technischer Sicht flgende Ziele für die Referenzarchitektur: TextGrid ist eine ffene, generische Infrastruktur Dem Benutzer werden nur drt Vrgaben gemacht, w dies unumgänglich ist. Datenfrmate, Metadaten und dergleichen können weitgehend den jeweiligen Anfrderungen entsprechend angepasst werden. Anwendungen sind knfigurierbar, und es können sgar eigene Anwendungen in die TextGrid Umgebung integriert werden. ermöglicht spezialisierte Anwendungen und tiefgehende Erschließung Wie der erste Punkt schn sagt, muss TextGrid die spezifischen Anfrderungen der Textwissenschaften und der Wissenschaftler unterstützen, um akzeptiert zu werden. Die Anwendungen der Textwissenschaftler sind ft hinreichend kmplex, und deren übergreifende Umsetzung in einem ffenen Umfeld ist entsprechend eine Herausfrderung (die diese Referenzarchitektur über die stufenweise Integratin vn Inhalten und Anwendungen bewältigt). und mtiviert Partizipatin Die Cmmunity ist wichtig für TextGrid, zum Aufbau der Datenbasis, für die Breite der Anwendungen, und zum Erhalt der Infrastruktur. Die Architektur erlaubt die aktive Teilnahme an TextGrid auf jeder Ebene. Die Verwendung vn verbreiteten Standards sind nur ein Aspekt davn. Je größer die Cmmunity dest größer der Nutzen vn TextGrid für die Cmmunity. Alle diese Ziele sind in jeder Kmpnente der Gesamtarchitektur manifest. Die Kmpnenten sind in vier Schichten eingeteilt 1. Benutzerumgebungen Dies ist das Tr zu TextGrid. Unterschiedlichen Benutzern mit ihren speziellen Anfrderungen werden spezifische Benutzerumgebungen angebten(z.b. Offline Funktinalität, zugeschnitten auf Arbeitsprzesse in der 1 TextGrid Szenarien sind in einem separaten Dkument entwickelt wrden, das über die TextGrid Webseite verfügbar gemacht wird. Die Szenarien gehen auf die Arbeitsweisen verschiedener Zielgruppen ein, und entwickeln daraus eine mögliche Einbettung in TextGrid. Seite 4 vn 29

5 literaturwissenschaftlichen Editin). Neue Benutzerumgebungen können mit geringem Aufwand auf die anderen Schichten der TextGrid Architektur aufgesetzt werden. 2. Service Layer Hier werden kmplexe fachspezifische Funktinalitäten mittels Web Services (basierend auf gängigen Standards wie SOAP, WSDL, etc.) gekapselt, und können in beliebiger Zusammensetzung in beliebigen Benutzerumgebungen eingebunden werden. Die Service Ebene ist auch durch externe Initiativen erweiterbar. 3. Middleware Ohne die TextGrid Basisdienste in der Middleware geht nichts. Die Middleware verknüpft Grid Technlgien mit anderen (u.a. semantischen) Technlgien, um die grundlegenden Funktinalitäten eines verteilten Datengrids nach den Anfrderungen der Textwissenschaften umzusetzen. 4. Archive Externe, hetergene Textarchive werden in TextGrid integriert und in der Middleware virtualisiert. Textarchive lassen sich stufenweise integrieren, wbei jede Stufe höhere technische Anfrderungen aber auch durch die stärkere Integratin mehr Möglichkeiten bietet. TextGrid Gesamtarchitektur Während die Grundarchitektur gängigen Schichtenmdellen in dem Bereich flgt, gibt es eine Reihe vn Tls, die schichtenübergreifend spezielle Funktinalitäten umsetzen. interaktive Tls haben ein Benutzerinterface und sind auf Benutzereingaben ausgerichtet [Benutzerschnittstelle] Streaming Tls bestehen aus zwei Teilen: einem im Batchbetrieb steuerbaren "Enactr" und einem GUI Frntend, mit dem Aufträge (bzw. Knfiguratinen) für den Enactr entwickelt werden können. Die GUI Kmpnenten sind eng mit den interaktiven Tls integriert. Die Enactrs können jeweils swhl im Rahmen eines Wrkflws durch den Wrkflw Enactr als auch direkt aus ihren jeweiligen GUI Frntends angestßen werden. [Service Layer, Benutzerschnittstelle] Seite 5 vn 29

6 Basistls wie das Recherche Tl haben Kmpnenten in allen Schichten [Middleware, Service Layer, Benutzerschnittstelle] Hilfstls, werden nur als Bestandteil eines anderen Werkzeugs aufgerufen hne eine eigene Benutzerschnittstelle anzubieten [Service Layer der Middleware] Im Flgenden werden alle Schichten kurz charakterisiert, und die Kmpnenten in der Middleware swie die stufenweise Integratin der Archive beschrieben. Seite 6 vn 29

7 Benutzerumgebung Eine Benutzerumgebung ist quasi das Tr zu TextGrid. Über sie kann ein Benutzer auf die für ihn relevanten Teile vn TextGrid zugreifen. Mehrere unterschiedliche Benutzerumgebungen können auf den anderen Schichten vn TextGrid aufsetzen. Dabei ist jede Benutzerumgebung auf einen bestimmten Nutzerkreis ausgerichtet, um sie möglichst intuitiv und effektiv bedienbar zu machen. Dazu werden Funktinalitäten gezielt ausgewählt und auf die Aufgaben und Przesse des Nutzers angepasst. Eine Benutzerumgebung bettet interaktive Tls und Streaming Tls ein. Interaktive Tls sind direkt in der spezifischen Technlgie der Benutzerumgebung implementiert, während die Kernfunktinalität der Streaming Tls in Services (eine Ebene tiefer in der Referenzarchitektur) umgesetzt wird. Da der Service Layer durch standardisierte Schnittstellen weitgehend technlgieunabhängig arbeitet, kann ein Service in verschiedene Benutzerumgebungen eingebunden werden. Es muss lediglich der Teil zur Bedienung des Services in der Technlgie der Benutzerumgebung umgesetzt werden. Wegen der Wiederverwendbarkeit vn Services und der damit einhergehenden Reduktin des Implementierungsaufwands wird möglichst viel Funktinalität in Services umgesetzt. Der Service Layer wächst unabhängig vn den Benutzerumgebungen, und idealerweise sind Benutzerumgebungen um durch neue Services hinzukmmende Funktinalitäten erweiterbar. Während Services und damit auch Streaming Tls eine Anbindung an das Grid brauchen, können interaktive Tls in einer Benutzerumgebung auch weitgehend in einem ffline Mdus bedient werden. Den XML Editr, zum Beispiel, ein interaktives Tl, kann der Benutzer für manuelle Editinsund Anntatinsarbeiten auch hne permanente Netzanbindung betreiben. Die für die Arbeiten nötigen Objekte (TEI gesetzte Transkriptinen, etc.) lädt der Benutzer dazu im Vrfeld in seinen Client, und synchrnisiert sie im Anschluss wieder mit den Daten im Grid. 2 Das Recherche Tl, auf der anderen Seite, hlt sich bei jeder Benutzeranfrage die Ergebnisse aus der Grid Umgebung und kann deshalb nur nline benutzt werden. Ebens können Streaming Tls wie der Lemmatisierer der der Kllatinierer durch die Benutzerumgebung im Online Mdus eng mit dem XML Editr verknüpft werden, stehen jedch hne Netzanbindung nicht zur Verfügung. Während einfache Bedienbarkeit ein Ziel für jedes Tl ist, sind die Aufgabenstellungen vn einzelnen Nutzern ft hinreichend kmplex und spezialisiert. Die Gratwanderung zwischen einfacher Bedienbarkeit und Flexibilität spiegelt sich in jedem Tl wider. Generell sind Textwissenschaftler durchaus kmplexe Tls gewhnt (vgl. z.b. TUSTEP). Während der Prjektzeit vn TextGrid wird hauptsächlich eine auf Editin, Anntatin und Analyse ausgerichtete, Eclipse basierte Umgebung 3 für Editinswissenschaftler und Linguisten entwickelt. In dieser Umgebung sind mehrere interaktive Tls (XML Editr, grafischer Link Editr, etc.) und Streaming Tls verknüpft (Kllatinierer, etc.). 2 Empfhlene Auszeichnungen, Metadaten, Versinierung, Knsistenzsicherung und andere Aspekte werden derzeit in einem TextGrid Objektmdell entwickelt. 3 Durch die Rich Client Plattfrm vn Eclipse ( kann ein Stand alne Client mit Offline Funktinalitäten geschaffen werden. Eclipse ist leicht zu installieren, plattfrmunabhängig, und gut erweiterbar. Aus der grßen Eclipse Cmmunity sind bereits eine Vielzahl vn Plugins verfügbar. Seite 7 vn 29

8 Die genaue Beschreibung der Aufgabenbereiche und Arbeitsprzesse, die ein Tl abdeckt, sind in den TextGrid Szenarien beschrieben. Die Spezifikatin der einzelnen Tls ist im TextGrid Funktinskatalg 4 umgesetzt. 4 Ein Funktinskatalg aller im Rahmen der Prjektlaufzeit umzusetzenden Kmpnenten (Tls) wird parallel zu deren Entwicklung geführt. Dieser Katalg wird öffentlich verfügbar gemacht, sbald die Spezifikatin und Entwicklung frtgeschritten ist. Seite 8 vn 29

9 Service Layer Ein "Service" ist eine Sftware Einheit, die in einem Netzwerk eindeutig identifizierbar ist, über standardisierte Prtklle angesprchen, und dadurch in ein anderes System und die drtige Benutzerschnittstelle eingebunden werden kann. Ein Service kann dementsprechend an jedem Ort in dem Netzwerk gehstet sein, und auf einer beliebigen Plattfrm laufen bzw. in einer beliebigen Prgrammiersprache implementiert sein slange der Service identifizierbar und die Schnittstelle zur Kmmunikatin bekannt ist, kann der Service vn überall im Netzwerk angesprchen werden. In einer "Service Registry" können Services ihre Dienste registrieren und beschreiben, sdass sie vn anderen Prgrammen entdeckt werden können. 5 Dadurch können jederzeit neue Services in die TextGrid Umgebung aufgenmmen werden. Z.B. könnte ein Lemmatisierer für Griechisch neben dem TextGrid Lemmatisierer für Deutsch hinzugefügt werden, der es könnten sgar mehrere Lemmatisierer für Deutsch registriert werden, die jeweils verschiedene Algrithmen benutzen und smit für unterschiedliche Anwendungsfälle einsetzbar sind. Services können beliebig untereinander kmbiniert und wieder verwendet werden. Ein "Wrkflw Mdul" kann autmatisch der nach den Vrgaben eines Benutzers den Datenfluss zwischen einer Reihe vn Services dirigieren, und smit eine kmplexe, auf spezifische Anfrderungen zugeschnittene Funktinalität aus wiederverwendbaren Bausteinen zusammenstellen. Üblicherweise versteht man unter "Web Services" die vm Wrld Wide Web Cnsrtium (W3C) 6 definierten Standards, die eine Serviceumgebung definieren. Unter den Standards sind SOAP und WSDL, XML basierte Prtklle. Der TextGrid Service Layer ist über diese Prtklle definiert, und smit theretisch mit allen SOAP basierten Services interperabel. Services in TextGrid sind z.b. der Srtierer, der Daten anhand gängiger Standards und/der manueller Knfiguratin srtiert. Um ein möglichst generisches System zu erreichen, gibt jeder Service für die Input Daten möglichst wenige Vrgaben. S erwartet der Srtierer nicht ntwendigerweise eine TEI Datei in einem speziellen TEI Schema, sndern er arbeitet auch mit einer Liste vn Wörtern. Der Kllatinierer hingegen, ein weiterer TextGrid Service, 7 erwartet zwei TEI Dateien als Input. Generell kann man zwischen unterschiedlichen Arten vn Services unterscheiden: rein Algrithmus basierte Services, die ihre gesamte Funktinalität in ihrem Prgrammcde umsetzen. z.b. der Tkenizer Services, die auf eine Wissensbasis aufbauen. Die Wissensbasis ist unveränderlich, bzw. wird nur vm Erzeuger des Services gelegentlich aktualisiert, z.b. der Lemmatisierer Services mit einem Gedächtnis, das durch Aktivitäten der Benutzer entsprechend angepasst wird. z.b. das Bibligrafie Tl 5 All dies sind wichtige Bausteine einer "Service Oriented Architecture", einem besnders rbusten und flexiblen Sftware Architektur Paradigma, nach dem auch aktuelle Grid Middleware Systeme mdelliert sind. 6 Wrld Wide Web Cnsrtium (W3C), 7 Siehe die TextGrid Szenarien, bzw. den Funktinskatalg für eine detaillierte Beschreibung der Services. Seite 9 vn 29

10 Services können relativ schnell erzeugt und in die TextGrid Umgebung eingebettet werden. Bei manchen Services könnte es Sinn machen, sie langfristig tiefer in die Grid Umgebung zu integrieren und zu einem Teil der Basisdienste in der Middleware zu machen. Slche Dienste könnten z.b. die Metadatenverwaltung der die TextGrid weite Suche sein. Als Teil der Grid Middleware und technlgisch knfrm mit Grid Service Paradigmen, prfitieren diese Dienste vr allem vn der möglichen Verteilbarkeit (Skalierbarkeit, Rbustheit) und dem direkten Zugriff auf die Hardware Ressurcen. In dieser zweistufigen Integratin kann der Schritt zur Aufnahme als ein TextGrid Basisdienst rganisatrisch gesteuert und technisch unterstützt werden, um den Aufwand s gering wie möglich zu halten. Um Hmgenität innerhalb der Services in der TextGrid Umgebung zu erzeugen, wird eine Art Servicehierarchie als Empfehlung für Service Entwickler etabliert. 8 Jede Schicht gibt hierbei eine Reihe vn Knventinen vr. Je nachdem w in dieser Hierarchie ein Service klassifiziert wird, setzt er die spezifischen Knventinen um. Dadurch wird z.b. garantiert, dass verschiedene Streaming Tls ähnliche Schnittstellen haben und analg angesprchen werden können. Allgemeine Knventinen für alle Services beinhalten z.b. die für die Authentifizierung und Sicherheit ntwendigen Mechanismen. Eine dkumentierte Klassenhierarchie könnte den Service Layer strukturieren und zur Wiederverwendbarkeit vn Mdulen beitragen, die Standardisierung vn Interfaces/APIs fördern, Prgrammierarbeiten und das Andcken vn neuen Services (evtl. vn externen Initiativen) erleichtern. Die einzelnen vm Benutzer (entweder direkt der über den Wrkflw Editr) aufgerufenen Services erhalten die Zugriffsrechte des Benutzers, die insbesndere bei Datei Zugriffen in Kraft treten. Slche authentifizierungs und autrisierungsrelevante Infrmatinen werden den Services mitgegeben. Über SOAP eigene Methden können diese auch vn einem Service auf den nächsten übertragen werden. Die Services selbst können sich zusätzlich über X.509 Zertifikate authentifizieren. Zusammenfassend lässt sich sagen, dass die atmaren Funktinalitäten vn Services beliebig ausgewählt und zu kmplexen Anwendungen kmbiniert, und in eine der mehrere Benutzerumgebungen integriert werden können. Jeder neue Service erweitert den Funktinskatalg und smit auch die Nutzerkreise, die durch TextGrid angesprchen werden können. Die Offenheit des Service Layers sll auch die Partizipatin vn externen Initiativen mtivieren, bwhl gewisse Knventinen für eine effektive Arbeitsumgebung ntwendig sind. Externe Service Prvider könnten langfristig sgar auf einer kmmerziellen Basis ihre Services anbieten, der Unterstützung bei der Integratin vn neuen Funktinalitäten in die TextGrid Umgebung anbieten. 8 Ein ähnlicher Ansatz wird vm e Framewrk, eine Standardisierungsinitiative vn JISC in Grßbritannien und DEST in Australien, verflgt. Drt wird unterschieden zwischen Service Genres und Service Expressins. siehe framewrk.rg Seite 10 vn 29

11 Middleware Die Middleware verwaltet verteilte Ressurcen in TextGrid und virtualisiert diese für hmgenen Zugriff. Als ein Kernaufgabengebiet in TextGrid srgt die Middleware für die Virtualisierung der vrhandenen Speicherressurcen (Strage) in gegraphisch verteilten Knten und erzeugt ein hmgenes virtuelles Archiv. Hierbei versucht die Middleware die Brücke zwischen einer möglichst generischen Ausrichtung (Andcken an die D Grid Integratinsplattfrm und Vernetzung mit anderen Grid Prjekten) und spezifischen Anfrderungen (eine möglichst kmfrtable Schnittstelle für die TextGrid spezifischen Dienste) zu schlagen. Es gibt verschiedene Ausprägungen vn Grid Knzepten und Technlgien in TextGrid. Ein zentraler Fkus liegt in der Schaffung eines Datengrids zur Verknüpfung externer Archive, Datenreplikatin und Metadatenverwaltung. Die Schaffung eines "Service Grid" eine ffene Plattfrm vn Funktinalitäten, die beliebig untereinander kmbiniert werden können wurde im letzten Kapitel vrgestellt. Zentrale Funktinalitäten können als Basisdienste schrittweise in die TextGrid Middleware integriert werden, w für ihre Verfügbarkeit und Skalierbarkeit besnders gesrgt werden kann (z.b. mittels verteilter, evtl. redundanter Datenbanken, etc.). Basisdienste bieten generische Funktinalitäten, die möglichst nicht auf spezielle inhaltliche Knzepte (z.b. Objektmdelle, bestimmte Schemata der Metadaten) festgelegt sind. Nachhaltiger Datenspeicher ("Data Grid") und der Aufbau einer ffenen Diensteplattfrm ("Service Grid") ist Teil der Kernmissin vn TextGrid und in der ersten Phase gegenüber Ansätzen zur Verteilung der Rechenlast ("Cmputatinal Grid") pririsiert. Aber es gibt auch eine Reihe vn Szenarien, in denen umfangreiche Rechenleistungen nötig sind. Darunter sind die autmatische Segmentierung vn Digitalisaten, die Anwendung vn Infrmatin Retrieval und Mining Technlgien, etc. Obwhl diese Szenarien nicht Teil der ersten Prjektphase sind, wird deren Umsetzung durch die Verwendung einer generischen Middleware vrbereitet, in der auch ein Cmputing Grid realisiert werden kann. Die TextGrid Middleware wird mit dem Glbus Tlkit aufgebaut und einigen zusätzlichen Kmpnenten zum Datenmanagement. Wie bei der darüberliegenden Schicht "Service Layer" beschrieben, gibt es zwischen den beiden Schichten nch eine Abstraktinsschicht. In dieser Abstraktinsschicht wird übersetzt zwischen der Web Service basierten Umgebung des Service Layers (i.e. WSDL, SOAP; ist HTTP basiert und statusls), und der WSRF basierten Gridinfrastruktur (statusbehaftete, sessinbasierte Services). Zusätzlich wurde als Teil der Middleware SAGA bzw. GAT zwischengezgen, das den Zugriff auf Glbus Grid Services kapselt und vereinfacht, swie einen zukünftigen Wechsel der Grid Infrastruktur ermöglicht.. Einige Grid Kmpnenten interagieren mit mehreren Schichten in der TextGrid Gesamtarchitektur der überbrücken diese. In der Skizze erkennt man z.b. die AAR (Authenticatin, Authrisatin, Rights Management) Kmpnente, die in allen Schichten manifest ist. Für das Wrkflw Management ist swhl ein Wrkflw Enactr im Service Layer als auch die Scheduling Kmpnente in der Middleware ntwendig; die Benutzerschnittstelle Wrkflw Editr ist zwar bedacht aber in der Architekturskizze nicht verzeichnet (der Balken unter "wrkflw" überdeckt lediglich die beiden Schichten "Middleware" und "Service Layer"), da sie rein die Benutzerschnittstelle darstellt. Alle diese Kmpnenten werden im Flgenden einzeln beschrieben. Seite 11 vn 29

12 Abstraktinsschichten TextGrid API Die TextGrid API ist eine aus reinen Web Services bestehende Sftwareschicht, die dem Service Entwickler der Service Layer eine TextGrid spezifische Schnittstelle zu den flgenden Gridfunktinalitäten anbietet: Datenmanagement: Die Bearbeitung der in einem verteilten Dkumenten Management System vrliegenden Texte und Binärdaten werden durchdie flgenden Web Services ermöglicht: InputStreamService bzw. InputStreamBinaryService zum sequentiellen Lesen vn Text bzw. Binärdaten, OutputStreamService bzw. OutputStreamBinaryService zum sequentiellen Schreiben vn Text bzw. Binärdaten und RandmAccessService zum Lesen und Schreiben vn Binärdaten an beliebigen Psitinen. Metadatenmanagement: Für das Veröffentlichen und Wiederfinden vn TextGrid Objekten mitsamt beschreibenden Metadaten gibt es den AdvertService Web Service. TextGrid Objekte können dabei unter einem absluten der relativen Pfad veröffentlicht werden. Beim Veröffentlichen eines Objektes können das Objekt beschreibende Metadaten mitgegeben werden (Register), über die das Objekt auch wiedergefunden werden kann (Index). Die API stellt hierfür Dienste zur Registrierung und zum Retrieval vn Infrmatinsbjekten zur Verfügung. In einer späteren Versin der Architektur werden neben den Datenressurcen auch die zur Verfügung stehenden Dienste über Metadaten recherchierbar sein, swie die Rechenressurcen, auf denen die Dienste betrieben werden können. Knfiguratin: Die Web Services der Serviceschicht haben eine gemeinsame Knfiguratinsinfrastruktur, die über den File Service der Middleware zur Verfügung Seite 12 vn 29

13 gestellt wird. Hierdurch wird es möglich, ausgetestete und bewärte Knfiguratinen der einzelnen Web Services in Dateien, die vn der Míddleware wie andere Infrmatinsbjekte verwalten und vn den Web Services zur Knfiguratin geladen werden können. Ein einheitliches Knfiguratinsfrmat srgt für eine weitere Hmgenisierung der TextGrid Web Services. Selbstverständlich können die Web Services auch direkt über die durch SOAP gegebenen Möglichkeiten der Parameterübergabe knfiguriert werden. Lgging: Die TextGrid Middleware stellt ein zentrales Lgging zur Verfügung, welches vn den Web Services über eine API verwendet werden kann. Dies ermöglicht auch ein einfaches zentrales Mnitring der Web Services. Security: Grundlage der Security Infrastruktur der Grid Middleware sind X.509 basierte Zertifikate. Diese kmplexe Technlgie sll vr dem Benutzer gekapselt werden, um den Aufbau einer aufwendingen PKI für User Zertifikatezu vermeiden. Die Textgrid API muss als zwischen einer einfachen Authentifizierung über UserID/Passwrt und einer Zertifikatsbasierten Authentifizierung, wie sie vn der Grid Infrastruktur wie Glbus Tlkit (Grid Security Infrastructure, GSI) erwartet wird, ebenfalls mderieren. Darüberhinaus wird die Middleware eine Benutzerverwaltung realisieren (s.u. 4.3) und über die API deren Administratin ermöglichen, als Accunts anzulegen, bzw. zu löschen, swie Benutzern Attribute und Rllen zuweisen, die für Zugriffsrechte relevant sind. WSDL WSRF Für den Aufbau der TextGrid Middleware wird die Middleware Glbus Tlkit 4 (GT4) eingesetzt. GT4 bietet in seiner API Web Services an, die auf der Basis vn WSRF (siehe Beschreibung in R3.1) erstellt wurden und smit Web Services Addressing (WSA, siehe ebenfalls R3.1) für ihre Adressierung verwenden. Da WSA jedch den Rahmen vn einfachen, reinen Web Services sprengt, können mit GT4 erstellte Web Services nicht unmittelbar in der TextGrid API angebten werden, die ja möglichst einfache Web Services anbieten will. Smit benötigt die Implementierung der TextGrid API eine Zwischenschicht, die zwischen reinen Web Services und WSRF Web Services vermittelt. Technisch bedeutet dies eine Übersetzung zwischen URLs und WSA EndpintReferences, die in dieser Zwischenschicht stattfindet. GAT/SAGA Da nicht alle Gridfunktinalitäten (z.b. GridFTP) der Glbus Tlkit 4 Middleware über WSRF Web Services ansprechbar sind, sndern über teilweise sehr kmplexe Nn Web Services APIs, werden in der Implementierung der TextGrid API die Tlkits GAT bzw. später dessen Nachflger SAGA eingesetzt, die eine vereinfachte und flexible Schnittstelle zu Gridfunktinalitäten verschiedener Middleware Tlkits darunter auch GT4 anbieten. TextGrid spezifische Basisdienste zur Datenverwaltung Die Datenverwaltung setzt sich aus einer Reihe vn Basisdiensten zusammen, die gemeinsam einen hmgenen Zugang zu verteilten Datenbeständen ermöglichen und die speziellen Anfrderungen der Textwissenschaften weitgehend kapseln. Die Funktinalitäten der Datenhaltung und die der textwissenschaftlichen Datenverwaltung sind in der Grafik als zwei verschiedene Schichten angedeutet, bwhl sie eng verknüpft sind. Dies sll verdeutlichen, dass die Datenhaltung über externe, hetergene Archive mittels eines Schichtenmdells realisiert ist, wie im flgenden Kapitel beschrieben wird. Das Schichtenmdell zur Archivanbindung bezieht Seite 13 vn 29

14 die Archive und deren technische Möglichkeiten in einem abgestuften Mdell mit ein. Eine der Schichten ist ein veritables Datengrid mit Funktinalitäten zur Dkumentenhaltung (DMS). Neben der DMS Kmpnente gibt es eine Kerninfrastruktur mit Verwaltungsaufgaben zur Metadatenverwaltung, zur Indizierung der Vlltexte, und zur tiefgehenden Erschließung wissenschaftlicher Texte und Strukturdatenverwaltung (XML DB). Diese Kmpnenten und deren Verknüpfung sind im Flgenden beschrieben. Datenhaltung und verwaltung in TextGrid Datenhaltung DMS In TextGrid werden diverse Infrmatinsbjekte vrgehalten, darunter vr allem Bilder (jpeg, tiff, png, etc), Texte (XML, TEI, etc.), als auch beliebige andere, auch prprietäre Frmate (TUSTEP, Winwrd, etc.). Klarer unterschieden werden kann zwischen statischen und dynamischen Objekten. Statische Objekte werden einmal in einem Textarchiv registriert und verändern sich vn da an nicht mehr; dies sind vr allem Bilddaten. Dynamische Objekte sind Teil der aktuellen Arbeit vn Textwissenschaftlern und werden regelmäßig frtgeschrieben. Das DMS verwaltet einheitlich alle Objektarten, bwhl die (externen) Textarchive ihre Datenbestände selbständig verwalten und ggf. nur statische Objekte registrieren. Der individuelle Zugang zu den Infrmatinsbjekten wird über die Metadaten ermöglicht, die auf die technischen, administrativen und inhaltlichen Eigenschaften der Objekte individuell zugeschnitten sind. In der Datenhaltung werden eine Reihe vn Aufgaben erfüllt: In der Datenstrukturierung geht es darum, w, in welcher Frm und Struktur, welche Infrmatinsbjekte vrgehalten werden. Werden einzelne Dateien eines zusammengesetzten Infrmatinsbjektes (z.b. ein Text mit Bildern) in Bundles zusammengehalten? Werden die Infrmatinsbjekte mit ihren Metadaten z.b. in METS Files gekapselt? Seite 14 vn 29

15 Wie sieht der Verzeichnisbaum aus? Wie werden unterschiedliche Versinen eines Objektes untereinander verknüpft?, nur über ihre Metadaten der spiegelt sich das auch in der Datenstrukturierung wider? Für den Zugriff sind verschiedene Mechanismen möglich bzw ntwendig: Eine eindeutige Identifikatin der Objekte muss auf ein einzelnes Objekt innerhalb eines Bundles verweisen können, Zusammengehörigkeiten, unterschiedliche Versinen, etc. abbilden, intern wie auch extern ansteuerbar sein. In der Rechteverwaltung wird auf der einen Seite das interne Rechteregime umgesetzt (siehe die Rllenaufschlüsselung in den TextGrid Szenarien; z.b. welche Rlle innerhalb einer VO darf welche Objekte löschen, etc.), als auch die Rechte externer Textarchive eingebettet. Wenn Infrmatinsbjekte nach außen transprtiert werden, werden sie mit ihren Metadaten gekapselt. Eine wichtige Eigenschaft des Datengrids ist die verteilte, redundante Datenvrhaltung. Zur Datenreplikatin müssen einige Aspekte definiert werden: Welche Objekte werden w repliziert?, welche nicht? Wieviel Speicherplatz steht bei den Textarchiven zur Replikatin zur Verfügung? Überwachung des Speicherraumes Auslastung einzelner Knten (Speicherplatz vs. Speicherbedarf, Perfrmance) Mechanismen zur Erhaltung der Knsistenz zwischen den verteilten Replika und zum einheitlichen Zugriff. Die hier besprchenen Aspekte des DMS werden derzeit gemeinsam mit Fachwissenschaftlern bei Textarchiven entwickelt und sind teilweise schn in Prttypen umgesetzt. Eine genaue Spezifikatin aller Aspekte wird im TextGrid Meta/Daten Knzept und in der DMS Systemspezifikatin vrgenmmen. Grundlage sind hierbei die Datagrid Funktinalitäten, die in GT4 zur Verfügung stehen (GridFTP, Reliable File Transfer RFT, Replica Management, etc.) Metadaten Eine Kernkmpnente zur Verwaltung vn und zum Zugriff auf Infrmatinsbjekte ist die Metadatenverwaltung. In einem TextGrid internen Metadatenschema sind diverse Aspekte abgedeckt, vn deskriptiven Metadaten (z.b. Autr, Titel) zu Kntextmetadaten (dieses Objekt ist mit diesem anderen Objekt verwandt, etc.) zu administrativen Metadaten (Rechte, Objektherkunft, etc.). Metadatenschemata haben einen Teil, der verpflichtend auszufüllen ist (mandatry) swie ptinale Teile, und sind für jedes Objekt beliebig erweiterbar. All diese Metadaten werden in einer eigenen Datenbank verwaltet. Die Metadaten Datenbank wird als ein Basisservice implementiert. Seite 15 vn 29

16 Metadaten Datenfluss Metadaten können verschiedene Ursprünge haben: 1. ein Bearbeiter erstellt sie manuell im Tl zur Metadaten Anntatin der im Bibligrafietl 2. sie werden aus existierenden Metadatenkatalgen (z.b. Kallipe, zvdd) übernmmen 3. imprtierte Infrmatinsbjekte enthalten Metadaten (z.b. im TEI Header) Neben dem Imprt aus unterschiedlichen Quellen können Metadaten auch in verschiedenen Frmen exprtiert werden (in ein Infrmatinsbjekt eingebettet, als Dublin Cre der MARC Schema). Während der Kern der Metadatenverwaltung als die Metadaten Datenbank ist, s sind die verschiedenen Möglichkeiten zum Imprt und Exprt, swie der Abgleich zwischen der Metadaten DB und dem DMS essenziell für eine effektive Metadatenverwaltung. Textanntatinen und Adaptren Neben den Metadaten und den Indexdaten sind für die textwissenschaftliche Datenverwaltung vr allem Anntatinen eine Kernaufgabe. Anntatinen sind ergänzende und vertiefende Infrmatinen zu Texten, die bis zu einer feinen Granularitätsstufe (z.b. Wrtebene) hinunterverzweigt sein können. Anntatinen können viele verschiedene Ebenen einnehmen, darunter physische (z.b. hier war ein Kaffeefleck), textgenetische (z.b. der Autr hat in der ersten Überarbeitung dieses Wrt gestrichen), linguistische (z.b. das Lemma dieses Wrtes ist...), semantische Beschreibungen und Stellenkmmentare. Die Erschließung vn Anntatinen, die in XML Markup direkt im wissenschaftlichen Text verzeichnet sind, ermöglicht eine XML Datenbank. Infrmatinsbjekte im DMS, die in XML vrliegen, werden zusätzlich in der XML Datenbank gespeichert und können mit den drt vrhandenen Mechanismen erschlssen werden (z.b. Abfrage, XQuery, etc.). Da zumeist jedes Prjekt ein individuelles XML Schema für seine spezifischen Anfrderungen erzeugt, liegen die in TextGrid vrhandenen wissenschaftlichen Texte in hetergenen Frmaten Seite 16 vn 29

17 vr. Adaptren kapseln die hetergenen Frmate und ermöglichen eine hmgene Erschliessung der Objekte. Zwei Aspekte müssen hier bedacht werden: 1. Bei der Registrierung wird das Infrmatinsbjekt swhl in seinem Herkunftsfrmat als auch im TextGrid spezifischen Frmat gespeichert. Operatinen in der XML DB perieren immer auf beiden Frmaten. Hierdurch werden prjektspezifische und TextGrid weite Anfragen immer parallel ausgeführt. 2. Das Recherche Tl bietet eine eigene Abfragesprache. Sllen auch Anfragen in einer prjektspezifischen Frm ermöglicht werden können, müssen diese spezifischen Anfragen zur TextGrid weiten Suche entsprechend umgesetzt werden. Schichten übergreifende Grid Dienste Authentifizierung, Autrisierung, Rechte, Sicherheit Mitarbeiter vn realen Organisatinen bilden s genannte Virtuelle Organisatinen (VO), um gemeinsam Rechnerressurcen, Daten und Dienste zu teilen. Autrisierungs und Authentifizierungsvrgänge werden innerhalb einer slchen VO durchgeführt. Eine VO ist ein zeitlich begrenztes der permanentes Knsrtium gegraphisch verteilter Mitarbeitern vn realen Organisatinen, Gruppen, ganzer Organisatinseinheiten der ganzer Organisatinen, die Teile ihrer Ressurcen und Dienste, ihr Knw Hw für ein gemeinsames Ziel zusammenlegen und teilen. Seite 17 vn 29

18 TextGrid wird zunächst eine eigene Benutzerverwaltung auf Grundlage eines LDAP basierten Verzeichnisdienstes aufbauen, welcher Grundlage swhl für die Authentifizierung und Autrisierung (AA) sein wird. Die Authentifizierung wird in Frm eines LDAP Bind Vrgangs durchgeführt, bei dem die Passwrtübergabe über eine via SSL/TLS verschlüsselten Sessin übergeben wird. Für die Autrisierung werden zusätzlich zu den Authentifizierungsdaten (LginID und Passwrt) weitere Attribute gepflegt, die einerseits weitere Identifizierungsinfrmatinen (E Mail Adresse, Kerbers Principle Id, etc.), Eigenschaften (Organisatinszugehörigkeiten, etc.) swie Rllenzugehörigkeiten abbilden. Über ein webbasiertes Interface können entsprechend Benutzerdaten gepflegt werden. Eine slche Benutzerverwaltung kann für sich zunächst für AA Vrgänge verwendet werden. Allerdings werden zusätzlich weitere Technlgien implementiert, um eine grundsätzliche Skalierung zu gewährleisten. Zukünftig sllen ja nicht nur einige wenige Prjektmitglieder Zugriff auf die TextGrid Ressurcen erhalten, sndern eine beliebig grße Anzahl vn Benutzern. Dann macht es keinen Sinn, dass alle Benutzer zentral an einer Stelle verwaltet werden, Für eine slche Skalierung wird zusätzlich Shibbleth implementiert, welches Federated Identity Management ermöglicht. Dies bedeutet, dass Benutzer in Ihrer Heimatrganisatin verwaltet werden und über einen Vertrauensbund Aussagen über Authentifizierung und Attribute über standardisierte XML Strukturen (SAML Assertins) ausgetauscht werden. Augenblicklich ist eine slche Föderatin deutscher Hchschulen im Aufbau (DFN AAI), die, sbald sie prduktiv gewrden sein wird, vn TextGrid genutzt werden kann. S wird es möglich, z.b. allen Germanistik Studenten der Universität Würzburg den Zugang zu TextGrid Ressurcen über deren lkalen Benutzeraccunt zu ermöglichen, als hne diese in die TextGrid Benutzerverwaltung aufnehmen zu müssen. Auch vr der Existenz einer prduktiven DFN AAI bringt der Einsatz vn Shibbleth Vrteile, weil durch diese Sftware ein Single Sign On realisiert werden kann, ein Benutzer sich als nur einmal authentifizieren muss und dann über einen definierten Zeitraum (z.b. 8 Stunden) für jeden Dienst als authentifiziert gilt. Es wird hierfür ein TextGrid Identity Prvider (IdP) implementiert, der auf den ben beschriebenen LDAP Server aufgesetzt werden kann. Sbald an den Heimatrganisatinen der Benutzer eigene IdPs entstehen, können die entsprechenden Benutzerdaten aus der TextGrid Benutzerverwaltung gelöscht werden. Durch die eigene TextGrid Middlewareschicht ist es möglich, selbst eine Knvertierung bzw. ein Mapping der LDAP bzw. Shibbleth Authentifizierung zu X.509 Zertifikaten, wie sie im Grid benötigt werden, zu realisieren. Genau dies wird aber im Prjekt GridShib implementiert, sdass anstelle einer Eigenentwicklung diese Sftware zum Einsatz kmmen kann. GridShib ermöglicht es, die Authentifizierung bzw. Autrisierung und die Single Sign On Funktinalität, die bei Shibbleth nur für Webdienste implementiert wird, auch für Przesse, wie z.b. Web Services zu verwenden. Die Autrisierungsentscheidungen werden auf der Ressurcenseite (in unserer Architektur die über die TextGrid Middleware verwalteten Infrmatinsbjekte) über Zugriffsrechte, die sich auf Rllen und Attribute beziehen, realisiert. Die Sftware Permis bietet die Möglichkeit, Zugriffsrechte kmfrtabel zu spezifizieren und in standardisierten Frmalen (XACML) abzulegen, swie Zugriffsentscheidungen mittels slcher Plicies zu treffen. Swhl GridShib, als auch Permis werden im Rahmen des GAP Prjektes IVOM evaluiert und für den Prduktiveinsatz implementiert. Die Ergebnisse dieses Prjekts werden sukzessive in die TextGrid Plattfrm einfließen. Es gibt verschiedene Rechteebenen (privat, Gruppe, öffentlich), swie verschieden Rllen (Prjektleiter, Bearbeiter, Benutzer, etc.), die im TextGrid Szenarien Text näher ausgeführt werden. Seite 18 vn 29

19 Zusätzlich zu den in den Heimatrganisatinen gepflegten Attributen können weitere Merkmale vn Benutzern, insbesndere Rllenzugehörigkeiten, in der VO selbst verwaltet werden. Auch hierzu kann ein zunächst eigener LDAP Server implementiert werden. Hierüber kann z.b. ein Prjektleiter Mitglieder in ein spezifisches Prjekt aufnehmen, die ausschließlich Zugriffsrechte auf die Prjektdaten erhalten. Auch hierfür gibt es im Gridbereich spezialisierte Sftware (VOMS und VOMRS). Insbesndere VOMRS kann mit relativ einfachen Mechanismen in eine GT4 Umgebung integriert werden, auch für den Betrieb mehrerer VOs. Dies ermöglicht, dass die inhaltlichen Prjektleiter der Textwissenschaftler zuweisen kann, wer sich in seiner Arbeitsgruppe befindet und damit wer Prjektdaten schreiben können sll. Neben direkten Prjektmitarbeitern gibt es in einer AG auch Bebachter, die selektierte Daten vrübergehend lesen können. Die Löschung vn Daten ist nicht nur abhängig vn den Zugriffsrechten: Sbald Daten veröffentlicht wurden (und damit evtl. vn extern zitiert werden), dürfen sie nicht mehr gelöscht werden. wrkflw, scheduling, resurce brkerage Die Wrkflw Kmpnenten sind im Wesentlichen auf den zwei beren Schichten (Benutzerumgebung und Service Layer) angesiedelt: der Wrkflw Editr in der Benutzerumgebung und der Wrkflw Enactr im Service Layer. Zusätzlich könnte man ein Scheduling in der Middleware Schicht zum Aufgabenbereich des Wrkflws zählen. Der Wrkflw Editr ist ein interaktiver Bestandteil der Benutzerumgebung und erlaubt es, die Autmatisierung vn Arbeitsabläufen (Wrkflws) zu definieren. Hier können nicht interaktive (als alle Streaming ) Tls krdiniert werden. Dazu erlaubt der Wrkflw Editr eine weitgehend intuitive Spezifikatin vn Abläufen. Zu jedem einzelnen StreamingTl ist eine Maske verfügbar, über die es knfiguriert werden kann (Eingabe und Ausgabedaten, falls nicht temprär, swie weitere Knfiguratinsptinen des Tls). Hauptaufgabe des Wrkflw Editrs ist die Erstellung einer Przessdefinitin, die an den Wrkflw Enactr übergeben wird. Eine zusätzliche, aber ptinale Aufgabe des Editrs ist das Anstßen und die Überwachung der Ausführung des Wrkflws, welche im Enactr erflgt. Der Wrkflw Enactr ist für die Ausführung des im Editr definierten Wrkflws zuständig. Die Zweiteilung Editr Enactr hat sich bewährt und ermöglicht die Unabhängigkeit des Enactrs vn der knkreten Anwendung; hier kann deshalb auf vrhandene Sftware zurückgegriffen werden. Der Enactr empfängt die Przessdefinitin vm Editr und führt die darin spezifizierten Tasks in der festgelegten Abflge aus. Im Falle vn Textgrid muss der Enactr Web Services als Tasks ausführen können. Das Interface zum Enactr kann wiederum als Web Service realisiert werden; Funktinen zum Starten, Anhalten und Verwalten vn verschiedenen Wrkflws sind hier verfügbar. Ein Scheduling der Tasks innerhalb eines Wrkflws ist in der ersten Implementierungsphase nicht nötig, da als Tasks nur Web Services verwendet werden, die an eine bestimmte Maschine gebunden sind. Ein Scheduling vn verschiedenen, ggf. knkurrierenden Wrkflws auf derselben Enactment Engine ist jedch evtl. ntwendig; eine gangbare Lösung wäre hierzu, jeden Wrkflw in einem separaten Thread zu realisieren und deren Krdinatin dem Betriebssystem zu überlassen. Ein Daten Scheduling (Staging) in der Middleware wäre dagegen für TextGrid wichtiger: z.b. werden in einem Wrkflw X die Daten A und B verarbeitet, diese könnten vm Scheduler vr Ausführung der Services zu einem Strage Knten in der Nähe der jeweiligen Service Knten repliziert werden. Dieses Replizieren sll möglichst im Hintergrund und vm Benutzer unbemerkt geschehen. Seite 19 vn 29

20 In einer zweiten Implementierungsphase sll der umgekehrte Weg erprbt werden: Nicht die Daten werden zum Service gebracht, sndern der Service möglichst nahe bei den Daten ausgeführt. Service Level Management Sbald TextGrid über den Prttypenstatus hinausgewachsen ist und eine größere Cmmunity TextGrid z.b. für Editinsprjekte nutzt, wird zwangsläufig die Erwartung bestehen, dass die Dienste und Daten in TextGrid rund um die Uhr ( 24/7 ) verfügbar sind. Um dem gerecht werden zu können, müssen die Administratren der angeschlssenen Rechen und Strage Knten jederzeit über den Status (Auslastung, auftretende Fehler etc.) ihrer Systeme infrmiert sein. Wenigstens ein Teil dieser Infrmatinen muss aber auch über das lkale System hinaus prpagiert werden, um innerhalb TextGrids Scheduling Entscheidungen treffen zu können, die systematische Datenreplizierung ptimieren zu können usw. Die Abfrage und Weiterverarbeitung dieser Statusinfrmatinen sll in TextGrid mit den vn GT4 MDS bereitgestellten Mitteln realisiert werden. MDS geht davn aus, dass für jede Ressurce eine krrespndierende WS Ressurce existiert, im wesentlichen als ein zustandsbehafteter Web Service. Der Zustand dieses Web Services technisch gesprchen die WS Resurce Prperties spiegelt den Status der überwachten Ressurce wieder und kann über das Aggregatr Framewrk, das Teil vn MDS ist, entweder regelmäßig abgefragt werden (plling) der aktiv an geeignete Dienste gemeldet werden (subscriptin / ntificatin). MDS bietet bereits einen Index Service, in dem die Statusinfrmatinen zahlreicher Ressurcen zusammengeführt und jederzeit abgefragt werden können. Anhand der aus diesem Index Service bezgenen Infrmatinen kann beispielsweise der Datenscheduler entscheiden, in welchem Strage Knten hinreichend Kapazitäten vrhanden sind, um hchaufgelöste Farbscans vn Manuskripten zwischenzuspeichern; über WebMDS vermag andererseits auch ein Administratr, sich im Brwser bequem einen Überblick über die in seiner Verantwrtung liegenden Ressurcen zu verschaffen. (Dieser Mechanismus ist auch für die in die D Grid Infrastruktur integrierten TextGrid Knten bligatrisch, um ein D Grid weites Mnitring zu ermöglichen. Vraussichtlich werden diese Datenquellen zugleich für TextGrid interne Zwecke und für die Zustandsmeldung an die vm DGI betriebenen Aggregatren genutzt werden können.) Ein Trigger Service erlaubt zudem, bei Überschreiten bestimmter Schwellenwerte (Plattenplatz nahezu erschöpft, Reaktinszeit eines Subsystems außerhalb des Tleranzbereiches.ä.) autmatisch Nachrichten an die zuständigen Administratren zu versenden. Die in GT4 enthaltenen Kmpnenten für das Mnitring sind als bereits hinreichend, um TextGrid aufzubauen. Sbald die Zahl der TextGrid Nutzer steigt und die Menge der in TextGrid gespeicherten Daten wesentlich über dem Umfang der vn den TextGrid Partnern eingebrachten Krpra liegt, werden die Infrmatinen über den augenblicklichen Ist Zustand nicht mehr genügen, um einen effizienten Betrieb zu gewährleisten. Dann werden auch Daten aus der Vergangenheit benötigt werden, aus denen sich Trends ableiten lassen, um z.b. Kapazitätsengpässe rechtzeitig vrhersehen und vrbeugen zu können der um z.b. die Replikatinsplicies in TextGrid s anzupasen, dass unnötige Datentransfers vermieden werden können. Die Entscheidung, wie ein slcher Dienst, der die Geschichte der TextGrid Ressurcen aufbereitet, im einzelnen aussehen muss b etwa ein einfaches Lg dieser Daten genügt, b Kennzahlen berechnet werden müssen, in welche die länger zurückliegende Geschichte nur nch schwächer gewichtet eingeht,.ä., kann erst sinnvll getrffen werden, wenn Erfahrungen mit dem Betrieb vn TextGrid vrliegen, d.h. gegen Ende der Prjektlaufzeit. Seite 20 vn 29

21 Die Prjektpartner bringen im Rahmen des Prjekts ausschließlich Daten in TextGrid ein, die frei vn urheberrechtlichen Einschränkungen sind, etwa weil der Autr vr mehr als 75 Jahren gestrben ist. Deshalb sind in dem genehmigten Prjekt keine Arbeitspakete vrgesehen, um etwa die Nutzung vn Texten abzurechnen, die nur unter einer kmmerziellen Lizenz verfügbar sind. Das Accunting zielt deshalb nicht in erster Linie darauf ab, Nutzungsdaten für eine spätere finanzielle Abrechnung zu erheben. Vielmehr dient es dazu, im Fall der missbräuchlichen Nutzung vn TextGrid Ressurcen die dafür verantwrtlichen Anwender identifizieren und im Extremfall vn der weiteren Nutzung ausschließen zu können. Vraussetzung ist hierfür, dass für alle Aktinen in TextGrid eine eindeutig zurdenbare ID des Nutzers, der die Aktin veranlasst hat, in Lg Files gespeichert wird. Dies betrifft in erster Linie das Anlegen der Mdifizieren vn Dateien bzw. Datensätzen, um unangemessen hhen Speicherplatzverbrauch der das Speichern sachfremder Daten in TextGrid unterbinden zu können, swie die Aufrufe vn TextGrid Services, um einer Blckade der TextGrid Recheninfrastruktur vrzubeugen. Diese Lgfiles müssen unbedingt auch vr dem Lesezugriff Dritter geschützt sein, denn die Akzeptanz vn TextGrid in der Cmmunity wäre erheblich gefährdet, wenn Nutzer nicht darauf vertratuen könnten, dass keine Außenstehenden anhand der Lgfiles Details über die aktuellen, nch nicht zur Veröffntlichung vrgesehenen Frschungsdaten erfahren könnten. Als ID können de fact nur die vn der AAI bereitgestellten Benutzerinfrmatinen dienen. Dabei muss es sich aber nicht ntwendig um Klarnamen der Anwender handeln; beispielsweise kann ein Shibbleth Identity Prvider s knfiguriert werden, dass das ausgestellte Authentisierungstken lediglich pseudnymisierte Nutzerinfrmatinen enthält. Die TextGrid Lgfiles enthielten dann nur dieses Pseudnym. Wenn die TextGrid Administratin Kntakt zu einem in einem Lgfile genannten Anwender herstellen will, dann muss sie sich an die Betreiber des Identity Prviders wenden; diesen bliegt dann zu entscheiden, b das Interesse vn TextGrid hinreicht, um eine Aufdeckung des betreffenden Pseudnyms zu begründen. Die Regeln, nach denen diese Entscheidungen getrffen werden, sind ntwendiger Teil einer VO Vereinbarung. Wie ben ausgeführt sind derzeit in TextGrid keine technischen Mechanismen vrgesehen, um evtl. vrhandene Verwertungsrechte an Texten, die über TextGrid zugänglich sind, durchzusetzen der die in diesem Zusammenhang fälligen Lizenzgebühren zu erheben. Das TextGrid Knsrtium sieht hier aber grundsätzlich einen Bedarf für Entwicklungen: denn nicht nur entstehen in TextGrid neue Werke mit eigenständigem Urheberrechtsschutz deren Autren entscheiden sich möglicherweise gegen eine Veröffentlichung innerhalb TextGrids, wenn sie ihr Verwertungsrecht nicht effektiv durchsetzen können. Es kann aber nicht im Interesse vn TextGrid sein, wenn Texte, die bereits vllständig ausgezeichnet und für die Weiterverarbeitung mit TextGrid Tls geeignet sind, dem möglichen Zugriff durch Dritte innerhalb der Plattfrm dauerhaft entzgen werden. Außerdem entgeht TextGrid s der größte Teil der zeitgenössischen Literatur der Krpra, die selbstverständlich ebenfalls Gegenstand textwissenschaftlicher Arbeiten sind. Denn kaum ein Verlag wird bereit sein, die Texte, an denen er das Recht hält, in TextGrid zur Verfügung zu stellen, wenn er nicht weiter kntrllieren kann, wer zu welchen Knditinen den Text z.b. kpieren und ausdrucken darf. In diesem Bereich besteht als nach wie vr Frschungs und Entwicklungsbedarf, zumal den Verwertungsinteressen der Rechteinhaber ein Interesse der Frscher gegenübersteht, dass die Ksten für den Zugang zum Gegenstand ihrer Frschung, nämlich den Texten, nicht prhibitiv teuer wird und dass im Falle einer Lizenzierung die technische Durchsetzung der Rechte der Verlage und Autren nicht den fairen Gebrauch der Daten verhindert. Angesichts des Seite 21 vn 29

22 ntwendigen Aufwandes für eine Lösung, die diesen Interessen gerecht wird, muss dahingestellt bleiben, b im Rahmen vn TextGrid nch Ansätze hierfür entwickelt werden können. Eine vllständige Lösung kann auf jeden Fall nur in einem weitergehenden Prjekt entstehen, ptimalerweise eingebettet in ein umfassendes Prjekt zum Service Level Agreement. Seite 22 vn 29

23 Archive Metadaten und Datenbjekte werden in TextGrid in der Archiv Schicht verwaltet. Sie ist Teil der TextGrid Middleware, wird aber aufgrund ihrer besnderen technischen und rganisatrischen Eigenschaften separat aufgeführt. Archive sind in einem virtuellen Speicherraum verknüpft. Textarchive im In und Ausland sind eingeladen, sich an diesen Speicherraum anzuschließen. Im Kern ist der Speicherraum ein Datengrid, mit allen Vrteilen der verteilten und redundanten Vrhaltung der Ressurcen bei deren gleichzeitiger Integratin. Um existierenden Textarchiven den Einstieg s einfach als möglich zu machen, gibt es neben dem Datengrid auch die Möglichkeit über in der Biblitheks Cmmunity verbreitete Schnittstellen wie OAI der Zing eine Einbettung der Datenbjekte zu erwirken. Dadurch entstehen einige abgestufte Schichten, aus denen der TextGrid Speicherraum zusammengesetzt ist. Mit jeder Schicht steigt die Integratin und damit auch die Möglichkeiten in TextGrid. 1. Metadatenintegratin Metadaten externer Katalge (z.b. zvdd 9 ) werden verlinkt; Datenbjekte der Referenzen dazu liegen nicht ntwendigerweise vr 2. Archiveinbindung Metadaten werden imprtiert, die Datenbjekte bleiben in den Archiven 3a. Imprt Imprt der Datenbjekte in die TextGrid Infrastruktur 3b. Datengrid Anschluss externes Archiv betreibt Grid Infrastruktur Mit jeder Schicht ist auch ein Archiv Schlüssel (archive layer cde) verknüpft, der für eine ptimale Integratin der einzelnen Archive in das TextGrid srgt. Dazu sind darin technische und rganisatrische, swie auch Aspekte zur Interperabilität und Qualität behandelt: Struktur und semantische Verknüpfung Metadatenmdell Objektmdell evtl. Selektinskriterien technische Integratin Prtklle (bzw. Grid Sftware Kmpnenten) Anfrderungen an die Verfügbarkeit des Systems 9 Zentrales Verzeichnis Digitalisierter Drucke, zvdd ( Seite 23 vn 29

24 Die Verwaltung dieses Speicherraumes ist für den Nutzer weitgehend transparent. Einzig aus Einschränkungen und Möglichkeiten mancher Tls und Services (siehe Funktinenkatalg) kann der Nutzer Rückschlüsse ziehen: nur ein Teil der Referenzen im Bibligrafietl sind auch als Digitalisate der als Vlltexte in TextGrid verfügbar. Spezialabfragen im Recherche Tl sind nur auf die Untermenge der in TextGrid verfügbaren Objekte möglich, die im entsprechenden Spezialfrmat vrliegen. Bestimmte Tls verlangen eventuell ein Spezialfrmat. S verlangt z.b. der Print Publisher die vn TextGrid für literaturwissenschaftliche Editinen empfhlene Auszeichnung 10. Metadatenintegratin In der untersten Schicht werden Metadaten gesammelt und verwaltet. Die Herausfrderung für diese Aufgabe ist das Zusammenführen hetergener Metadatenmdelle und das Abgleichen der Einträge. Mit dieser Integratinsarbeit beschäftigen sich eigenständige Prjekte (z.b. zvdd der Kallipe), auf deren Arbeit vn TextGrid zurückgegriffen wird. Das Metadatenmdell vn TextGrid ist mit dem vn zvdd abgestimmt, und eine Integratin daher relativ einfach möglich. Der Schlüssel hierzu ist: die Metadaten werden im entsprechenden TextGrid Metadatenfrmat angebten ( das interne Frmat ist hierbei nicht relevant, nur das nach außen hin angebtene) es existiert eine adäquate Schnittstelle die Richtigkeit der Daten wird durch das Textarchiv garantiert; etwaige Änderungen werden entsprechend an das TextGrid Metadatenimprtmdul weitergegeben. Archiveinbindung Die Archiveinbindung baut auf der Metadatenintegratin auf und bettet weitergehend existierende Datenbjekte in Textarchiven ein. Zur Durchsuchung der Vlltexte der weitergehenden Bearbeitung werden die Objekte in die TextGrid Umgebung imprtiert. Die Katalge und Archive werden über eine Schnittstelle abgegriffen und die Metadaten in der TextGrid Metadaten Datenbank abgelegt. Textarchive können ihre Metadaten in TextGrid integrieren und damit Textwissenschaftler auf existierende Originale, Digitalisate, der sgar Vlltexte aufmerksam machen. Der Schlüssel zum Transfer der Metadaten ist: Metadatenintegratin (unterliegende Schicht, siehe ben) ist gegeben die Infrmatinsbjekte dürfen und können in TextGrid zur weiteren Verarbeitung transferiert werden 10 Empfhlene Auszeichnungen, Metadaten, Versinierung, Knsistenzsicherung und andere Aspekte werden derzeit in einem TextGrid Objektmdell entwickelt. Seite 24 vn 29