Abstract
Dieses Dokument behandelt die technischen Aspekte von Projekt CLARIN. Eine allgemeine Übersicht über das Projekt ist im Hauptdokument clarin.html zu finden. Autor:
Nachfolgend werden die Kerntechnologien der zu bildenden Infrastruktur kurz skizziert:
- PID
Persistent Identifier - Persistente Bezeichner für Ressourcen, wird erreicht durch weitere Virtualisierungsebene:
Die Ressource bekommt vom PID-Verwalter einen PID zugeordnet, die mit der aktuellen URL der Ressource verknüpft wird. Die URL (also die Domain/ der Anbieter der Ressource) kann sich ändern, der PID bleibt erhalten.
Technologisch nichts bahnbrechendes, das Problem ist weiterhin organisatorisches: Wie kann man sicher sein / gewährleisten, dass das Angebot des PID-Verwalters von Dauer ist.
- "commitment to continuation"
Versuch einer Lösung für das zentrale Problem: die Vergänglichkeit. Von Anfang an (im Vertrag) festlegen, wie die Persistenz zu gewährleisten ist, zB Ressourcen zu einem anderen Zentrum zu migrieren, wenn das eigene Zentrum seine Tätigkeit einstellen sollte. Entsprechende Vereinbarungen müssen im Center- und im Nutzungsvertrag getroffen werden.
- Alliance for Permanent Access, APA
alliancepermanentaccess.eu/ die internationale Initiative in diesem Bereich
- PHAIDRA
https://phaidra.univie.ac.at/ - Digital Asset Management System betrieben vom ZID der Uni Wien; vergibt den verwalteten Ressourcen eine PID
Beispiel einer Ressource in PHAIDRA: CLARIN ESFRI Summary [PID=o:1740]
Unabdingbarer Grundpfeiler für den Erfolg von CLARIN. Für eine distribuierte Infrastruktur, wie sie in CLARIN angedacht wird, ist die Erstellung einer "Trust Domain" - auch "Identity Federation", oder AAI - unumgänglich. Diese Technologie bringt folgende Vorteile:
Dem Dienstanbieter (Service Provider) wird die Benutzerverwaltung abgenommen
Die sensiblen Benutzerdaten bleiben bei der Heiminstitution
Die Benutzerin muss sich nicht für jede Ressource extra registrieren
Die Benutzerin braucht sich nicht für jede Ressource extra einloggen (SSO)
- AAI
Authentifizierungs- und Authorisierungsinfrastruktur. Die Technologie basiert auf Delegation: Der Service Provider lässt den Benutzer sich bei dem Identity Provider anmelden und erhält vom IdP die Bestätigung. Dazu ist Vertrauen zwischen dem Service und Identity Provider notwendig, das letztlich auf Verträgen/Policies gegründet ist.
- Service Provider
der Anbieter eines Dienstes, also zB eine Bibliothek mit ihrem online-Katalog, ein Uni-Institut mit seiner e-Learning Applikation, oder ZID mit Webmail.
- Identity Provider
"home organization", der Verwalter der Identität des Benutzers
- Discovery Service, Where Are You From (WAYF) Service
Das Zwischenglied, das es ermöglicht den Identity Provider für gegebenen Benutzer zu finden
- Web Single Sign-On, SSO
Der Benutzer braucht sich nur einmal (innerhalb einer Sitzung) anmelden. Wenn er auf Ressourcen vom nächsten Dienstanbieter zugreifen möchte, erhält dieser automatisch vom IdP Bestätigung, dass der Benutzer bereits authentifiziert ist.
- Single Log Out, SLO
Umsetzung nicht trivial, nicht vorhanden in den existierenden Implementierungen, auch gewöhnungsbedürftig für die Benutzer
- SAML
Security Assertion Markup Language, Ein OASIS-standardisiertes Protokoll/Schema zum Definieren der Konfigurationen bei und Austausch von Information zwischen den Providern, das in AAI weite Verwendung findet. Derzeit in Version 2.0.
- Shibboleth
shibboleth.internet2.edu - Eine AAI-Software, Server-Anwendung, die die notwendige Funktionalität für (Service und Identity) Provider bereitstellt. Derzeit in Version 2.x (unterstützt SAML 2.0), Version 1.3 auslaufend
- simpleSAMLphp
leichtgewichtige Alternative zu Shibboleth, reine PHP-Implementierung, entsprechend leicht in Web-Applikationen zu integrieren, unterstützt mehrere Protokolle (SAML 2.0, Shibboleth 1.3, A-Select, WS-Federation, OpenID, PAPI, InfoCard)
- OpenID
openid.net/ leichtgewichtige Alternative zu dem Föderationsansatz, findet Anwendung vor allem im Web-User-Bereich. Wird als Benutzer-zentrischer Ansatz angepriesen, der die Benutzer unabhängiger von IdPs machen soll, kommt aber auch um Identitätsprovider nicht drumherum.
- Internet2 Middleware Initiative
http://www.internet2.edu/middleware/
“developing an interoperable Identity and Access Management infrastructure for Research and Education”
Weitere Infos zum Thema: https://aai-wiki.univie.ac.at/Hauptseite
Beispiele existierender AAIs:
SURFnet (NL) - http://www.surfnet.nl/
Deutsches Forschungsnetz - http://www.dfn.de/
SWITCH (CH), http://switch.ch/aai/
MPG-AAI - im Aufbau (Kontakt: Sebastian Rieger, Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen)
CSC, Uni Helsinki (Kontakt: Arppe)
CLARIN soll als eine Service Provider Federation auftreten. Es wird keinen eigenen IdP errichten, sondern IdPs aus existierenden bzw. im Entstehen begriffenen AAIs werden eingebunden. Dh CLARIN wird Vereinbarungen mit ausgewählten Identity Federations treffen, was insgesamt zu einer "Federation of Federations" führen wird, also einem System, in dem bestehende AAIs zu einem noch größeren Verbund weiter zusammengeschaltet werden. Bezüglich der konkreten Konfiguration erhofft man sich Lösungsansätze von eduGAIN. Wichtig ist, dass in diesen Verhandlungen CLARIN als EINE (föderative) Entität auftreten wird, die alle teilnehmenden Service Provider vertritt. Dafür sind wiederum entsprechende CLARIN-interne Kontrakte notwendig, die das Verhältnis zwischen den Service Providern und CLARIN regeln (WP8).
Eigenes Problem sind die "homeless" Benutzer, also welche, die bei keinem (anerkannten) IdP untergebracht sind.
Ein weiteres Problem ist der Einsatz von AAI bei A2A-Interaktion, also die Handhabung der Authentifizierung und Authorisierung wenn Applikationen/Software untereinander kommunizieren werden.
Es ist zu erwarten, dass die Ressourcen klassifiziert werden bezüglich ihrer Verfügbarkeit (frei verfügbar, nur für Mitglieder gewisser Institutionen usw.) und entsprechend wird sich der Zugang zu diesen Ressourcen für die/den Einzelne/n gestalten. Dies muss das System transparent verwalten, auf der Grundlage individueller Abkommen zwischen den beteiligten Akteuren.
- Copyright Owner
behält die Rechte an den Ressourcen
- Content Provider
Bietet die Ressourcen an, Vertrag mit Copyright Owner, Vertrag mit Service Provider
- Service Provider
kennt "seine" vertauenswürdigen Identity Provider, verwaltet Authorization Register, in dem geregelt ist, was welche Benutzer mit welchen Ressourcen tun können
- Identity Provider
CLARIN müsste minimal erforderliche Attribute spezifizieren, die die IdPs liefern müssen
- User
verpflichtet sich mittels Code of Conduct zu gewisser Handhabung der Ressourcen
- Serviceorientierte Architektur, SOA
“SOA ist ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird.” [OASIS 2006]
- Web Service, WS
eine spezielle Art von Software, die
auf standardisiertem Weg (XML-Standards)
über Internet (endeutige URI)
von einer anderen Applikation aufgerufen werden kann (Im Gegensatz zu einer Webanwendung, die eher für den menschlichen Benutzer gedacht ist.).
Kann auch über bisher existierende Applikation drübergestülpt werden.
Web Services sind (nicht exklusive, aber wohl wichtigste) Bausteine der serviceorientierten Architektur.
Die Web Services werden erst wirklich interessant, wenn der Benutzer die Möglichkeit bekommt, einzelne Dienste zu einer "Kette" zusammenzustellen ("orchestration" - eine Komposition ähnlich der GATE-Umgebung) und auf die untersuchten Ressourcen anzuwenden. Kanonisches Beispiel: Tokenizer, Tagger, Lemmatizer, Morphological Analyzer and Semantical Analyzer werden verkettet.
Voraussetzung ist, dass jede Ressource über MD beschrieben ist. Genauso muss auch jede Ressource im privaten Workspace der Benutzerin und auch jedes neue Ergebnis mit MD versehen werden.
Es müssen Probleme der Kompatibilität gelöst werden: Output eines WS muss kompatibel gemacht werden zum Input des nächsten WS. Dafür braucht es eindeutige Beschreibung des Formats der Inputs und Output und Transformatoren, die zwischen diesen Formaten umwandeln können.
WSDL ist ein anerkannter verbreiteter Standard
zur Beschreibung von Web Services ist aber angeblich (Leute aus WG 2.7,
Zhastrow@Uni Tübingen, Boehle@Uni Leipzig) nicht ausreichend für die
genaue Definition der Inputs und Outputs.
Bezüglich der Transformation, kann man entweder point to point
Ansatz wählen, dh Transformationen von jedem Output in jeden Input
bereitstellen (O(n^2)), was aber unnötig viele Transformatoren
erfordert. Einfacher erscheint die Verwendung eines internen Austauschformats. So braucht es nur eine
Transformation von jedem Output und jedem Input in den Austauschformat
(O(n+n)). Dieses interne Format wird unter dem Namen "Pivot
model" entwickelt und soll zum standard CLARIN
Datenaustauchformat (data service interchange format) werden. Dieser
wird wahrscheinlich in Anlehnung auf "natürliche Ordnung" der Tools (man
kann den POS-Tagger nicht vor dem Tokenizer anwenden) einen
mehrschichtigen Aufbau auweisen.
Hardware und Software Infrastruktur, die verteiltes Rechnen ermöglicht: Durch lose verbundenes Netzwerk von Computern, die die "Arbeitslast" teilen, entsteht aus der Benutzersicht ein "virtueller Supercomputer".
Die Kopplung zwischen der CLARIN-Infrastruktur und existierenden GRIDs ist noch nicht geklärt. Die Hoffnung ist, rechenintensive Aufgaben auslagern zu können, dafür werden aber Schnittstellen auf der Software-Ebene definiert und die einzusetzenden Applikationen entsprechend erweitert werden müssen. Initiativen und Standards, die diesbezüglich zu beachten sind:
A Simple API for Grid Applications (SAGA)
Open Grid Services Architecture (OGSA)
Web Services Resource Framework (WSRF)
mehr unter: http://en.wikipedia.org/wiki/Grid_computing#See_also
TERENA ist ein wichtiges Europäisches Unterfangen in diesem Bereich, zu dem CLARIN aktiven Kontakt unterhält.
CLARIN Metadaten Infrastruktur (CMDI) wird das technische Herzstück von CLARIN sein. Es wird die Erstellung, Verwaltung von und Zugriff auf die Metadaten ermöglichen. Da die Ressourcen verteilt sein werden, werden die Benutzer_innen von CLARIN primär mit den Metadaten arbeiten und die eigentlichen Ressourcen evtl. gar nicht zu Gesicht bekommen. Eine Vorstellung davon kann man sich in dem Vorgänger von CMDI machen, dem IMDI-Browser, entwickelt an dem MPI für Psycholinguistik, Nijmengen: http://corpus1.mpi.nl/ds/imdi_browser/
Ein wichtiges Prinzip von CLARIN ist, dass kein neues MD-Schema
entstehen soll, sondern statt dessen existierende Schemen (IMDI,
OLAC, TEI) in einer flexiblen komponent-basierten
MD-Infrastruktur integriert werden sollen. Dadurch soll sichergestellt
werden, dass die große existierende Datenbasis in die neue Infrastruktur
integriert werden kann.
- Data Category
A data category is an elementary descriptor in a linguistic structure or an annotation scheme; unique reference point, fine grained semantics;
definiert ein Konzept assoziiert mit einem Wert oder einem Schlüssel;
Verwendet bei Schema-Definition:
<elementSpec name="POS"> <equiv name="partOfSpeech" uri="isocat.org/dadtacat/ISO-DC-369" /> </elementSpec>
- DCR, Data Category Registry, ISOcat Registry
www.isocat.org - Referenzimplementation des ISO-Standard:
ISO 12620; Produkt des: ISO TC 37 Terminology and Other Language and Content Resources; Eigentlich ein Meta-Standard, der eine Struktur und einen Prozess definiert, über die neue Data Categories auf schnellem Weg definiert/standardisiert werden können. Es ist organisiert über "Thematic Domain Groups" (formale Gruppen) die DCs beurteilen, die für den Standardisierungsprozess eingereicht wurden. Der Standard sieht auch einen User Space vor, in dem Kandidat-Definitionen existieren können, noch bevor sie den Standardisierungsprozess durchlaufen. Es werden keine Relations (semantische Beziehungen zwischen Konzepten) definiert.DCR ist freier Service: http://www.isocat.org/interface/index.html; Eine DataCat-ID ist persistent und versions-basiert (dh jede Version einer Data Category erhält eigene PID)
- Trusted Concept Registry
Manche existierende MD-Sets (
IMDI, OLAC, TEI) sollen in das neue System integriert werden. Diese werden hier verwaltet/veröffentlicht.- Component & Profile Registry
indiziert und veröffentlicht die definierten Komponenten und Profilen
- Component Editor
Ermöglicht die Erstellung, Definition von Komponenten und Profilen. Muss dem Benutzer Zugriff zum ISOcat Registry und Component Registry bieten.
- Component Specification
XML-Schema - "Meta-meta-language" zum Definieren von Komponenten aus vorhandenen "primitiven" Konzepten (DataCategories) und/oder anderen bereits existierenden Komponenten
- Relations Registry
Es sollen auch Relations zwischen Elementen definiert werden können, die dann im Relations Registry verwaltet werden. Die Relations werden aber nur selektiv, bedarfsorientiert definiert und sollen insgesamt keine Ontologie ergeben. Sie sollen Semantic Mapping und dadurch semantische Suche im CMDI ermöglichen.
- Profile
Entspricht in etwa einem Schema. Eine Komponent-Auswahl versehen mit weiteren administrativen MD, die die MD-Struktur für gegebene Ressourcen definiert. Benutzer können frei Profile erstellen, sollen aber nach Möglichkeit existierende wiederverwenden.
- Metadata Editor
Basierend auf ausgewählten Profilen, und mit Hilfe von Vorlagen (Templates) füllt hier der Editor-Benutzer die Metadaten für die Ressourcen.
- Virtual Collection (Registry)
Die Benutzerin kann sich ihre eigene Sammlung von Ressourcen zusammenstellen, mit der sie arbeitet. Diese Sammlungen werden wiederum als eigene Ressourcen angesehen, sind mit MD versehen und werden in einem eigenen Virtual Collection Registry indiziert.
- Private Workspace
Die Benutzerin verfügt über privaten Arbeitsbereich, der vor allem der Ergonomie dienen soll. Benutzerspezifische Einstellungen, verwendete Ressourcen, Tools und neu enstehende Ressourcen (Ergebnisse) werden hier verwaltet. Auch hier sind alle Ressourcen mit MD versehen. Das Persistence-Layer (eigentlicher Speicherort) wird distribuiert und heterogen angenommen (lokale Dateien, Server-DB, ...)
- Metadata Repository
Eine Datenbank, die die MD sammelt, verwaltet und verfügbar macht. Es soll mehrere MD Repositories geben und zumindest ein zentrales, das alle MD sammelt und veröffentlicht. Einzelne MD Repositories müssen nicht notwendigerweise vollständig sein (alle CLARIN-Ressourcen erfassen), sie können sich auch nur auf eine Untermenge der Ressourcen spezialisieren.
- MD Query Service, Search Engine
Das Benutzer Interface zu den MD Repositories, ermöglicht die Suche nach Ressourcen nach verschiedenen Kriterien
- Harvest MD
Die Resource Provider müssen die MD über ihre Ressourcen so bereitstellen, dass sie mittels
OAI-PMHProtokoll gesammelt werden können, um in das MD Repository aufgenommen zu werden.- Portal
Das Integrationspaket, das aus den Benutzer-Modulen (Component Editor, MD-Editor, Browsing & Searching MD) besteht und einen einheitlichen, integrierten Zugang zu den CLARIN-Ressourcen bietet.
- IMDI
http://www.mpi.nl/IMDI/ ISLE Metadata Initiative; ISLE - International Standards for Language Engineering (älteres Projekt, bis 2002?), http://www.ilc.cnr.it/EAGLES/isle/ISLE_Home_Page.htm
- OLAC
http://www.language-archives.org/ Open Language Archives Community - international partnership of institutions and individuals who are creating a worldwide virtual library of language resources
- TEI
http://www.tei-c.org/ Text Encoding Intitiative - Weite Verbreitung im Annotieren von Texten (Korpora)
- LMF
http://www.lexicalmarkupframework.org/ - ISO standard for Natural Language Processing (NLP) lexicons and Machine Readable Dictionaries (MRD). The ISO code number for LMF is ISO-24613:2008.
- MAF
http://atoll.inria.fr/~clerger/MAF/maftoc.html Morpho-syntactic Annotation Framework, basiert auf ISO 12620; Verwendung, Verbreitung unklar?
- TMX
http://www.lisa.org/Translation-Memory-e.34.0.html - TMX (Translation Memory eXchange) is the vendor-neutral open XML standard for the exchange of Translation Memory - von Localization Industry Standards Association
- MDF
Multi-Dictionary Formatter ?
- CES/XCES
http://www.xces.org/ Corpus Encoding Standard
- EAF
ELAN annotation file; ELAN (Endangered Languages Archive) - Standalone-System zur Annotation von Multimedia
- Shoebox
http://www.sil.org/computing/shoebox/index.html - Linguistische Arbeitsumgebung zur Annotation von Sprachressourcen
Existierende Applikationen mit Bezug zu CLARIN. Großteils Web Services vorgestellt von CLARIN Partnern in Oxford, 2009-02 als Fallbeispiele und zugleich erste prototypische Service Bausteine für die CLARIN-Infrastruktur.
Middleware Architektur für die Integration von deep und shallow NLP Komponenten.
Entwickelt am DFKI
An Automated Linguistic Processing Environment (ALPE)
A model to interpret XML and non-XML metadata
An environment allowing automatic configuration of processing chains
developed at Institute for Computer Science, Romanian Academy (Dan Cristea)
presented at D-Spin Meeting in München 2008-11
leading toolkit for Text Mining
developed at Sheffield
Zwar eigene Applikation, die lokal läuft, daher wohl nicht direkt für CLARIN verwendbar, aber ausgereiftes Produkt - Werkzeugkiste für Textmining und NLP - von dem man sich viele Konzepte abschauen kann (Benutzerumgebung, Komponieren von Prozessen).
DWDS entwickelt mehrere einfache, aber praktische Web Services basierend auf XMLRPC:
- ddc
corpus query system/manager/indexer
implementiert auch als xmlrpc-service(?)
- ToMaSoTaTh
Tokenizing, TAGH Morphology, TextToSound (SAMPA), Tagging (moot), Thesaurus (Lexikonet)
- Meinten Sie?
basiert auf Edit-Distanz, Token, liefert Tokens Vorschlagliste
- SynCoP
Syntactic Constraint Parser grammar/specification-driven parser implemented sytems: - (partial) dependency parsing - NER and classification (highest f-measure: 94%) plain text -> ~TIGER-XML oriented format
Aufruf (code-snippet):
xmlrpclib.ServerProxy sessionid = server.dwds.login(name,pwd) server.dwds.processor - tools server.dwds.resources - languages
old services: RDB, SOAP-based, Apache Axis
parameters only in strings, because problem with data-types (date, floating-point)
can't define complex data-types (??)
QoS issues
challenge: howto integrate completely different tools
approach: 4 layers = chainer, common CLARIN WS (Auth, QoS), toolwrapper, resource/tool
classic SOA + matching the formats(?), central point: input/output definition, need vocabulary
bottom-up approach, specification (3/4 months), implementation (2 months)
own header (of the message) allows the input/output matching, building bridges
plans: dialects, central repository (integrate CLARIN MD), more services,
evaluate the prototype-infrastructure => performance, scalability, costs.
2 publicly available Services:
GermaNet,OpenThesaurusJava 6, ApacheTomcat as appserver, implemented REST style, web form for querying the data
Import/export problems, focus on the linguistic aspects, big data not possible in WS
clarin.sfs.uni-tuebingen.de:8080/navigation/ /metadata/
wget --post-file=....xml http:/ -o gnOut.xml
- LangID
statistische Sprache-Erkennung
- TTL
Tokenizing, Tagging, Lemmatizing, Chunking and Linking Free Running Texts
- MT WebService
Machine Translation, basiert auf Moses (opensource factorized translation system)
- Jaguar
statistical corpus information: n-grams, contexts, vocabulary
- Aaile
lexical corpus information; groups concordances according to the syntactic contexts
- CQP
CQL implementation, allows querying the IULA corpus; 3 Web Services:
- CQP WS: lists the contexts of a sequence of words
- CQP BagOfWords: returns a data matrix which collects the words that go with the lemma
- CQP BagOfWords Clustering: Performs a clustering on the matrix returned by CQP BagOfWords.
Nachfolgend eine Überblicksgrafik, die die Zusammenhänge zwischen einigen der Entitäten in der CLARIN Welt darstellt. Es werden Gruppen, Projekte/Initiativen, Standards, (Projekt)Aktivitäten und Produkte in Beziehung gesetzt.
Im folgenden "tentative" Deploy-Diagramm wird versucht, das Zusammenspiel der einzelnen Entitäten darzustellen: Die Komponenten der CLARIN Metadata Infrastruktur (CMDI) - das MD-Repository, das Portal -, die Worfklow-Engine, die eigentliche Ressourcen und AAI-Komponenten (Ports) verteilt auf die teilnehmenden Knoten, kommunizieren über definierte Schnittstellen. Die Benutzerin greift auf die Ressourcen primär über das Portal zu, aber ein direkter Zugriff ist auch denkbar, falls der Ressourcen Anbieter entsprechendes User-Interface bereitstellt. Der Sicherheitsaspekt der Kommunikation ist über AAI geregelt, dh das ganze System stellt eine Identity Federation (bzw. Federation of Federations) dar.
