Projekt Deutsche Digitale Bibliothek (DDB) Grobkonzept für das Portal der Deutschen Digitalen Bibliothek

Transkript

1 Projekt Deutsche Digitale Bibliothek (DDB) Grobkonzept für das Portal der Deutschen Digitalen Bibliothek v 2.0 Dieses Dokument wurde verfasst von Kai Stalmann und Reinhard Budde.

2 EINLEITUNG Die EU hat im Rahmen der Initiative i2010 den Aufbau einer spartenübergreifenden Europäischen Digitalen Bibliothek beschlossen. Ende 2008 ist ein entsprechendes Portal unter dem Namen Europeana in Betrieb gegangen. Technische Vorarbeiten dafür lieferte The European Library, ein Portal der europäischen Nationalbibliotheken. Die Länder der EU sind aufgefordert, sich mit ihren jeweiligen nationalen Portalen an der Europeana zu beteiligen. Die Deutsche Digitale Bibliothek (DDB) soll diese Aufgabe erfüllen und in Form eines Portals den Zugang zu Zeugnissen des kulturellen Erbes aus einem weitgespannten Netzwerk von nationalen Datenbanken und Portalen von letztlich möglicherweise bis zu über Kultur- und Wissenschaftseinrichtungen (Bibliotheken, Archive, Museen, Denkmalpflege, Medienarchive, Wissenschaft) bieten und damit gleichzeitig ein wichtiger nationale Datenaggregator für die Europeana werden. Maßgeblich sind hier das Verwaltungs- und Finanzabkommen zwischen der Bundesrepublik und den Ländern der Bundesrepublik Deutschland über die Errichtung und den Betrieb der Deutschen Digitalen Bibliothek sowie die Gemeinsamen Eckpunkte von Bund, Ländern und Kommunen zur Errichtung einer Deutschen Digitalen Bibliothek (beide vom Dezember 2009). 1 Das Angebot der DDB richtet sich an ein weit gefasstes und heterogenes Publikum. Es adressiert Nutzergruppen aus den Bereichen der Forschung und Bildung, der an Kultur interessierten weiteren Öffentlichkeit im In- und Ausland sowie auch Akteure der Wirtschaft (insbesondere der kulturnahen Wirtschaftsbereiche). Die Fraunhofer-Gesellschaft (Institut für Intelligente Analyse- und Informationssysteme IAIS) wurde vom Beauftragten der Bundesregierung für Kultur und Medien (BKM) mit der Konzeption, Planung und Errichtung der DDB bis Ende 2011 beauftragt. Das Vorhaben wird in enger Abstimmung mit dem Auftraggeber, dem Bundesbeautragten für Kultur und Medien, dem Kompetenznetzwerk DDB sowie dem technischen Betreiber durchgeführt, um die Anforderungen der unterschiedlichen Kultureinrichtungen in allen Phasen der Entwicklung zu berücksichtigen. Ebenfalls werden die betrieblichen Aspekte von vornherein einbezogen, so dass ein nahtloser Übergang von der Aufbauphase in den laufenden Betrieb der DDB gewährleistet ist. Bei der Entwicklung der DDB sollen bereits öffentlich finanzierte Vorarbeiten berücksichtigt und nach Möglichkeit deren Ergebnisse eingesetzt werden. Hierbei sind insbesondere die CONTENTUS-Dienste das Projekt THESEUS 2 zu nennen. 1 < < 2 < Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB), Seite 2

3 Das technische Grobkonzept ist für die weitere technische Planung der DDB von grundlegender Bedeutung, da mit diesem Schneisen in die Vielfalt möglicher Lösungswege geschlagen werden. Das Dokument stellt das technische Konzept für die Realisierung der Deutschen Digitalen Bibliothek als Plattform und Internet-Portal dar. Es beschreibt in Grundzügen alle Technologien, Komponenten, Schnittstellen, Prozesse, Frameworks und Datenmodelle, die zum Aufbau der Plattform verwendet werden, und skizziert die Infrastruktur zum (Pilot-)Betrieb des geplanten Systems. Das Grobkonzept gibt den Diskussionsstand Mai/Juni 2010 sowie die im Juni und Juli insbesondere vom Koordinator des Kompentenznetzwerks, der DNB, dem Verfasser der Machbarkeitsstudie, Michael Christen, und von Prof. Stefan Gradmann einbrachten Kommentare und Verbesserungsvorschläge. Insgesamt konkretisiert und überholt Planungsdokumente, die zu früheren Zeitpunkten der Projektierung erstellt wurden 3. Das Grobkonzept wird seinerseits im Zuge der wetieren technischen Planungen durch neuere Dokumente und andere Artefakte (Sourcecode, Dokumentation) überholt werden, ohne dass diese weiteren Änderungen und Erweiterungen in diesem Dokument nachgehalten werden sollen. Neben technischen Konzepten erörtert das Papier einige Aspekte der Vorgehensweise (Prototyping) und den Zuschnitt der Arbeitspakete, die im Zuge der Einführung einer agilen Vorgehensweise (Scrum) gegenüber der ursprünglichen Projektplanung neu aufgeteilt wurden. Die Anforderungen wurden zu implementierungsrelevanten User Stories verdichtet; sie werden weiter separat verwaltet. Zu besseren Verständlichkeit des aktuellen Planungsstandes haben wir die User Stories wichtiger Artefakte aufgenommen, wenn uns das dem Verständnis hilfreich schien. KONTAKTINFORMATION Fraunhofer IAIS NetMedia Schloss Birlinghoven Sankt Augustin Gemeint sind insbesondere folgende Dokumente: die im Mai 2010 abgeschlossene Deutsche Digitale Bibliothek Rahmenbedingungen zur Anforderungsanalyse von Fraunhofer IAIS und die Machbarkeitsstudie zum Aufbau und Betrieb einer Deutschen Digitalen Bibliothek von Michael Christen (2008) < funktionaler_technischer_sicht_finale_fassung_ pdf>; < machbarkeitsstudie_ pdf>. Seite 3, Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB)

4 Inhalt 1 Die Deutsche Digitale Bibliothek als Plattform Die DDB Plattform in der Übersicht Das Portal als Anwendungs-Container und Präsentationsschicht Zugang, Personalisierung, Extranet Redaktionelle Inhalte (öffentliche und geschützte) Funktionale Komponenten Minimalset der Rollen und Rechte Webdesign Standards, Best Practices, Open Source, Qualität, Sicherheit, Mehrsprachigkeit Buzzword-Liste der Technologien, Tools und Standards Mengengerüst 17 2 Hauptkomponenten Hauptkomponente Portal Portalfunktionalität für redaktionelle Inhalte Portalfunktionalität zur Verwaltung von Nutzern und Nutzerregistrierungen, Formularen, Auswertungen Portalkomponenten Wiki, News, Kalender Portalkomponente Objektrecherche / Object Discovery: Anwendungen für Suchen, Browsen, Detailanzeige der Digitalen Objekte bzw. Dokumente Hauptkomponente Digitale Bibliothek OAIS Compliance und Anlehnung an die Nomenklatur des Digital Library Reference Model Relevanz des OAIS für DDB Digital Library Reference Model Zentrale Schnittstellen und Prozesse 33 3 Komponenten und Anwendungen, Endpoints Augmented SIP Creator (ASC) Ingest Endpoint Zeichenketten-Normalisierung Resource Recognition Object / Resource Clustering (Objektähnlichkeitserkenner, Dublettenhandling) Unified Catalog (Gesamtkatalog, Werkenormdatei) Indexierungskomponente Data Management Dokumentenablage (Storagekonzept) Access Endpoints 44 4 Dienste (lokale und entfernte Services) / Mashups Dienste zur semantischen Anreicherung und Anfrage User Generated Content (UGC) / Crowd Sourcing Dienste zur kommerziellen Nutzung der Daten in der Bibliothek46 Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB), Seite 4

5 5 Datenmodelle, Speicherung, Zugriff auf Objekte Nutzung von RDF Anforderungen an das Submission Information Package Die Daten und die Datenmodelle der DDB Logische Sicht auf Datenfluss, Storage, Access der Digitalen Bibliothek 52 6 Arbeitspakete PORTAL / Präsentationsschicht DIGITALE LIBRARY QUERSCHNITTSAUFGABEN 55 7 Releaseplanung und Teamplanung Geplante Releases für Portal und Digital Library (DL) Teams und Skills 57 8 Anhang Glossar OAIS Terminology UML Diagramme aus dem Digital Library Reference Model ( 65 Seite 5, Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB)

6 1 Die Deutsche Digitale Bibliothek als Plattform Die endgültige Bestätigung des Namens "Deutsche Digitale Bibliothek" (DDB) für das geplante Portal steht noch aus und soll bis Ende 2010 erfolgen. Der endgültige Name wird Bestandteil des Domänennamens werden, unter dem das Portal zu erreichen ist. Das Portal der DDB bietet unter einer Adresse (URL) alle Dienstleistungen und Verwaltungsanwendungen ('Extranet') der DDB an. Einige Dienstleistungen werden im Dokument weiter unten beschrieben. Andere Dienstleistungen der DDB werden jedoch erst später entwickelt und integriert werden. Integration kann hier bedeuten, dass zusätzliche Komponenten entwickelt und installiert werden, bzw. in Form von Mashups eingebunden werden. Wichtigste Aufgabe des aktuellen Implementierungsprojektes ist es, eine flexible, ausbaufähige Plattform zu schaffen, die eine sehr große Zahl digitaler Objekte verschiedenster Provenienz und Art - im Prinzip das digitalisierte kulturelle Erbe der Bundesrepublik Deutschland - in adäquater Weise aufnimmt, konsolidiert, verwaltet, zugänglich macht und vernetzt Nutzer mit unterschiedlichen Interessen im Internet mit Dienstleistungen zu den aus Archiven, Museen, Bibliotheken und wissenschaftlichen Einrichtungen stammenden Inhalten bedienen, so dass Alleinstellungsmerkmale und wirklicher Mehrwert entstehen, als konstruktiver Bestandteil des Semantic Web Ressourcen zur Verfügung stellt für humane und maschinelle Zugriffe und Verarbeitung. Der Fokus dieses Papiers liegt auf der Beantwortung der Frage, wie eine geeignete Plattform technisch konzipiert und realisiert werden kann. Es bildet den Ausgangspunkt weiterer Detailspezifikationen, Architekturen, Prototypen und Implementierungen. Insofern beschreibt das Dokument einen aktuellen Stand und will als living document verstanden sein. Als Basistechnologie der zentralen Komponenten wird Java vorausgesetzt. Java ist zur Zeit die meistgenutzte Technologie im Web-Projekt- / Enterprise- Programming Umfeld. Es gibt eine hervorragende Toolunterstützung, unzählige ausgereifte Open Source Frameworks und Code Bibliotheken wie Lucene, Solr und Jena, und nicht zuletzt eine enorme Menge professioneller Erfahrung im Java-Umfeld. Java stellt sicher, dass sowohl in der Aufbauphase wie auch nach Übergabe an den Betreiber und bis in die absehbare Zukunft hinein qualifizierte Entwickler zur Weiterentwicklung rekrutiert werden können. Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB), Seite 6

7 Neben Java können auch andere, auf der Java Virtual Machine (JVM) lauffähige, dynamisch typisierte Sprachen wie Groovy eingesetzt werden, wenn sie eine bessere Alternative darstellen. 1.1 Die DDB Plattform in der Übersicht In den nachfolgenden Kapiteln wird das Konzept der DDB beschrieben. Die DDB Plattform besteht im Wesentlichen aus 2 Hauptkomponenten: dem Portal (Präsentation, Verwaltung, Personalisierung) und der Digitalen Bibliothek. Wir werden zunächst das Portal und die zur Realisierung vorgesehenen Portal- Technologien sowie die im Portal verwalteten Inhalte diskutieren. Anschließend werden die innerhalb der Hauptkomponente Portal geplanten Komponenten skizziert. Das sind Anwendungen zur Verwaltung und Präsentation von statischen Inhalten, Nutzern usw. Wir gehen von dort über zu den für die Hauptkomponente Digitale Bibliothek (DL) wesentlichen Komponenten. Nach dieser Übersicht der Hauptkomponenten und der geplanten Sub- Komponenten werden die wichtigsten Komponenten und Endpoints der DL sowie anschließend einige der benötigten Dienste beschrieben, bevor wir zu den Datenmodellen, dem Datenfluss und Fragen der Speicherung übergehen. Abschließend werden die Arbeitspakete und Releases beschrieben und schließlich die voraussichtlich benötigte Infrastruktur zum Betrieb der Plattform. Die nachfolgende Skizze soll das Gesamtkonzept des Systems grafisch veranschaulichen. Die Plattform der DDB besteht aus einem Präsentation Layer (Portal), das auf ein Service Provider Interface zugreift (Digital Library Services, DLS), die Infrastrukturkomponenten und Implementierungen nutzen. Die bei der Implementierung der DL verwendete Terminologie wird sich an der Nomenklatur des OAIS Referenz Modell und am DELOS Digital Library Reference Model orientieren. Für das Gesamtsystem ist neben der Plattform und dem Portal eine externe Komponente vorgesehen, der Augmented SIP Creator (ASC), der die Daten vor dem Ingest aufbereitet. Diese Aufbereitung betrifft das Metadaten- bzw. Ontologiemapping und damit die Indexierung, soll aber auch die adäquate Präsentation der Inhalte ermöglichen. Dieses Werkzeug soll prinzipiell von den Einrichtungen genutzt werden können, und auf diese Weise den Einrichtungen ermöglichen, die Aufbereitung der eigenen Daten optimal steuern und eigenen Vorstellungen anpassen zu können. In der Praxis werden die Anpassungen auf spartenspezifische Standardmappings und vorlagen, also auf Erfahrungen andere Einrichtungen zurückgreifen können. Innerhalb der Plattform werden die Daten ingestiert, indiziert, redundant gespeichert und damit für den Zugriff aufbereitet. Für die Suche, das Browsen (Listen, semantisches Netz) und die objektspezifischen Detaildarstellungen gibt Seite 7, Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB)

8 es eine Komponente namens Object Discovery, die innerhalb des Portals die zentrale DDB-Anwendung darstellt. ASC (PRE INGESTAugmented SIP Creator) provider data <<restructure as>> views semantics search terms <supports> <contains> <uses> OBJECT DISCOVERY Search Browse Detail View DDB Platform Layers escidoc on Fedora DELOS DLRM Portal (Mashup Server) users resources policies functionalities content quality OAIS DLS (Digital Lib Services - Provider API) <uses/extends> 1.2 Das Portal als Anwendungs-Container und Präsentationsschicht Das Portal wird in einer noch nicht endgültig spezifizierten Form als Container realisiert werden, der die Kernapplikationen enthält und in den zur Erweiterung der Funktionalität später weitere Anwendungen installiert werden können. In Ermangelung eines allgemeineren Standards für Portale bietet sich der Portalstandard JSR 286 an. Alle diesem Standard folgenden Portalcontainer können JSR 286 Portlets aufnehmen. Der Standard erlaubt (im Unterschied zum Vorgänger JSR 186) auch eine Datenkommunikation zwischen Portlets. 4 Entfernte Anwendungen können notfalls über WSRP 5 eingebunden werden, was allerdings als unerwünscht schwache Integrationsform zu sehen ist. Es gibt eine Vielzahl von Open Source Portlet Container-Implementierungen, die dem Standard folgen, z. B. Liferay Portal Server, Jetspeed 2, JBOSS Portal, außerdem kommerzielle Produkte wie IBM Websphere Portal. Der funktional intessanteste Kandidat, Liferay, erwies sich bei bei genauerer Evaluation als ungeeignet (Auswertung ist separat dokumentiert). Die Präferenz haben zunächst Open Source Produkte, es erweist sich aber, dass die verfügbaren Open Source Portale technisch unzureichend sind bzw. nur über stark reglementierende, kommerzielle Lizenzen hinreichend mit Support versehen werden. Daher werden zur Zeit (Stand Ende Juli 2010) auch kommerzielle Plattformen für die Präsentationsschicht ins Auge gefasst, die nicht der Portlet- Spezifikation folgen. Das Portal sieht ein Registrierung und ein Login vor. Registrierte Nutzern nehmen gegenüber dem System eine Rolle ein, die zur weiteren 4 Näheres siehe 5 Web Service Remote Portlet, Integrationsmodell für entfernte Anwendungen. Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB), Seite 8

9 Nutzungsformen einlädt. Das Rollenmodell der DDB regelt den Zugriff auf geschützte Bereiche und ermöglicht damit unter anderem die Abrechnung kommerzieller Dienste, die auf der Plattform angeboten werden können Zugang, Personalisierung, Extranet Zentraler Zugang zum Portal Die nicht-eingeloggten Nutzern zugängliche Standard-Startseite des Portals setzt sich aus öffentlich zugänglichen Anwendungen mit für die Öffentlichkeit gedachten redaktionellen Inhalten und Funktionen (wie vor allem Suchen, Browsen, Sichten von DDB-Objekten) zusammen. Die lizenzrechtlichen Fragen der Nutzung werden zur Zeit auf politischer Ebene noch diskutiert. Die DDB wird die technische Verwaltung der ihr anvertrauten Inhalte so auslegen, dass diese Inhalte wirksam geschützt werden können. Der Zugriffsschutz wird Bestandteil der unteren Schichten der Architektur sein und die in Metadaten enthaltenen Schutzbestimmungen auswerten. Neben den öffentlich direkt zugänglichen Inhalten werden auf der Plattform weitere, geschützte Inhalte und Applikationen angeboten werden. Solche Mehrwertdienste können auch später noch in die Plattform eingebracht werden. Eine Personalisierung des Portals wird Nutzern nach Registrierung und Login ermöglicht. Für die Nutzer stellt das Portal einen Single Point of Access dar. Die jeweils nutzbaren Funktionalitäten und sichtbaren Inhalte sollen lediglich von den Rechten des Nutzers abhängig sein. Nutzer, wie z.b. ein anonymer Internet- Endnutzer, ein registriertes Community-Mitglied, ein Mitglied des Betreibernetzwerks (Extranet-Nutzer) oder eine das Plattform-API nutzende Maschine, erreichen die Plattform über ein und dieselbe Adresse (z.b. Dessen ungeachtet können weitere öffentliche Landingpages oder Microsites mit abweichenden URLs veröffentlicht werden, etwa um Aufmerksamkeit auf bestimmte Inhalte oder Sammlungen zu lenken Personalisierung des Portals, Extranet Eingeloggte Nutzer können ihre Sicht auf das Portal personalisieren, indem sie unter den auf der Plattform für sie (ihre Rolle) freigegebenen Anwendungen wählen. Das Extranet ist der Portal-Bereich für die KWEs 6. Nur eingeloggte Mitglieder des Betreibernetzwerks 7 haben auf die Extranetfunktionen Zugriff. 6 KWE steht für kulturelle und wissenschaftliche Einrichtungen. 7 Das Betreibernetzwerk umfasst neben dem technischen Betreiber vor allem die KWEs, die Inhalte zu der DDB betragen. Seite 9, Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB)

10 Mandantenfähigkeit Die Plattform muss mandatenfähig sein, um eine weitgehend dezentrale Administration zu ermöglichen. Die institutionellen Mitglieder des BNW, die Einrichtungen, stellen gegenüber der Plattform Mandanten 8 dar. Der (übergeordnete) Betreiber legitimiert die Einrichtungen und macht technisch eine Reihe anderer Vorgaben. Den Einrichtungen selbst soll jedoch eine Eigenständigkeit, z.b. bei ihrer Selbstdarstellung und bei der Verwaltung ihrer Mitarbeiter im System und der Zuteilung von Rollen zugestanden werden. Den institutionellen Mitgliedern des BNW stehen somit jeweils eigene Funktionen / Inhalte zur Verfügung. So können die Stammdaten einer Einrichtung nur von einem Berechtigten der Einrichtung selbst editiert werden. In ähnlicher Weise sollen Mitglieder der Einrichtung von der Einrichtung selbst legitimiert werden. Auch verwaltet die Einrichtung ihre eigene Microsite, auf der sie sich darstellt und z.b. News posten oder einen Kalender pflegen kann. Innerhalb des Extranet entstehen so - in Bezug auf die Rechte und Rollen - weitere Substrukturen, die eigenverantwortlich gepflegt werden. Letztlich könnte man insbesondere auch die digitalen Objekte als Objekte betrachten, die von der Einrichtung verwaltet werden und zwar disjunkt von den Objekten anderer Einrichtungen. Die digitalen Objekte der DDB sind als von der DDB nur verwaltete Objekte anzusehen, auch wenn die DDB mit der Aufbereitung eine rechtliche Verantwortung übernimmt. Jedes Objekt, das eine Einrichtung der DDB zur Darstellung zur Verfügung stellt, kann nur von dieser Einrichtung selbst freigegeben werden und hinsichtlich seiner Semantik (Metadaten) und seiner Qualität (Content) definiert werden. Die Rolle der DDB liegt in der geeigneten Verwaltung (Präsentation, Suche, Clustering) des Contents. Dessen ungeachtet kann die DDB, wie es konkret auch angedacht ist, in der Zukunft Dienste zu Monetarisierung von Content anbieten oder vermitteln Redaktionelle Inhalte (öffentliche und geschützte) Redaktionelle Inhalte bieten dem Nutzer Informationen, Hilfen, Anreize an. Es handelt sich dabei nicht um die Kernaufgabe der DDB. Im Extranet der Betreiber sollen redaktionelle Inhalte die Kooperation der Einrichtungen und Partner verbessern. Eine besondere Form der redaktionellen Inhalte stellen virtuelle Ausstellungen dar, die innerhalb der DDB, aber auch auf einer separaten Landingpage veröffentlicht werden können. Virtuelle Ausstellungen sind Aggregationen von Inhalten der DDB und sie werden, wie alle übrigen Inhalte der DDB, als Ressourcen im Sinne des Semantic Web verwaltet, verlinkt und zugänglich gemacht. Nutzergenerierte Inhalte können auch von Mitgliedern der DDB Community (alle registrierte Nutzer der DDB, die nicht Mitglieder des Betreibernetzwerks 8 Wegen der divergierenden Bedeutungen des Terms definieren wir ein mandantenfähiges Softwaresystem als System, das Kunden verwalten können muss, die ihre Daten in eigener Verantwortung verwalten, so dass die Kundendaten disjunkt vorgehalten werden. Wenn also bspw. eine Dachorganisation sämtliche Daten ihrer Mitglieder verwaltet, wären die Mitglieder keine Mandanten, sondern einfache Geschäftsobjekte. Wenn dagegen in dem System zwar die Mitglieder von der Dachorganisation verwaltet, die Mitglieder aber ihren eigenen Content selbst verantworten, dann wäre das System mandantenfähig zu nennen. Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB), Seite 10

11 sind) erzeugt werden. Dies können beispielsweise Postings in Communityforen sein. Für solche Foren wird die Rolle eines Moderators benötigt. Außerdem empfiehlt es sich, ein Manifest vorzusehen, das die Lizenz- und datenrechtlichen Fragen der Postings regelt und festlegt, unter welchem Bedingungen Inhalte gelöscht oder gesperrt werden können bzw. müssten. Der konkrete Inhalt des Manifests muss vom Betreibernetzwerk, bzw. dem Vorstand der DDB festgelegt und veröffentlicht werden Redaktionelle Bereiche und Verantwortlichkeiten Redaktionelle Bereiche (Die Gruppe der registrierten Nutzer wird im Folgenden als Community bezeichnet.) In der Anforderungsanalyse wird eine Reihe von redaktionellen Bereichen genannt, die in unterschiedliche Verantwortlichkeiten fallen. Sparten Verantwortlichkeit Kontrolle News Vorstandsbeschlüsse Vorstand Betreiber News Betreiber, KWE, Partner Betreiber Community News Community Öffentliche News Vorstand, KWE, Betreiber Betreiber Termine Termine der Betreiber Vorstand, KWE, Betreiber Termine, öffentlich Vorstand, KWE, Betreiber Betreiber Artikel Redakt. Artikel, Betreiber Vorstand, KWE, Betreiber Microsites Redakt. Artikel für d. Öffentlichkeit Öffentliche Seiten, Themenseiten und Landing Pages der DDB Öffentliche Seiten, Themenseiten und Landing Pages der KWE Extranet-Themenseiten der Partner Vorstand, KWE, Betreiber, Community Betreiber KWE Partner Forum Themenforen, Betreiber Vorstand, KWE, Betreiber Themenforen, Partner Partner Betreiber Betreiber Themenforen, Communities Community Wiki Knowledgebase, Betreiber Vorstand, KWE, Betreiber, Partner, Community FAQ Knowledgebase, öffentlich Betreiber About Pages DDB Kontaktdaten KWE Kontaktdaten Vorstand KWE Die Aufstellung stellt den aktuellen Erkenntnisstand dar (Mai 2010). Weitere Themen werden eventuell im weiteren Projektverlauf identifiziert und dann integriert. Seite 11, Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB)

12 Organisatorische Einheit Die Verantwortlichkeiten werden als Gruppen und Rechte modelliert. Die minimal notwendigen Rollen für die redaktionelle Betreuung des Portals sind demnach: Redaktionelle Funktionen Rolle Vorstand Redaktion DDB Redakteur / Hauptredaktion Betreiber Redaktion, Freigabe DDB Redakteur / Freigeber bzw. Hauptredaktion KWE Redaktion Redakteur der KWE Partner Redaktion Redakteur des Partners Community Redaktion Community Redakteur (Superuser) Öffentlichkeit - Technisch werden die redaktionellen Bereiche mit geeigneten Komponenten bzw. mit entsprechenden Templates realisiert (siehe weiter unten). Die Inhalte werden als Ressourcen gespeichert. Inhaltlicher Bereich News Diskussionen Wissenspflege Microsites Termine Kontaktdaten Sitemap Anwendung CMS, Feeds Forum Wiki CMS Kalender, Feeds CMS Generator Funktionale Komponenten Die redaktionellen Inhalte meint im weitesten Sinne Informationen über die DDB, die in dem Portal veröffentlicht werden. Dienstleistungen und Funktionen, die Nutzern angeboten, bzw. von Mitgliedern des Netzwerks verwaltet und angeboten werden, stellen den eigentlichen Wert der Plattform dar. Die Verwaltung (Installation, Wartung, Aktivierung, Erweiterung) der funktionalen Komponenten muss bei der Entwicklung des Rechtekonzepts berücksichtigt werden. Die folgende Tabelle stellt dar, welche Rollen und Rechte minimal benötigt werden, um das Portal in sinnvoller Weise zu verwalten (Erkenntnisstand Mai 2010). Mit Administrator Rechenzentrum sei eine Rolle umschrieben, die initial das System und Netzwerk konfiguriert. In der Praxis werden das mehrere Personen Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB), Seite 12

13 mit unterschiedlichen Rollen und an verschiedenen Orten sein, da die DDB Plattform in einer Cloud, bzw. auch verteilt laufen wird. Der Plattform Administrator meint hier die Rolle derjenigen, die das laufende System betreuen und weitere Anwendungen auf dem System installieren. System Anwendungen Funktionaler Bereich Netzwerk, Maschinen, Storage DDB Plattform Portal Container, Anwendungen, Dienste, Prozesse CMS Datenmodell, Templates, Prozesse Funktionen einrichten, administrieren, backup/restore konfigurieren, patchen, start/stop, migrieren, Spam-Abwehr und System-Sicherheit installieren, deinstallieren, start, stop alle Aktionen auf Produktivsystem Administrator Rechenzentrum Plattform Admin Plattform Admin Plattform Admin CRM Datenmodell, alle Aktionen Plattform Admin Formulare, Prozesse Kalender alle Aktionen Plattform Admin Forum anlegen / löschen für Gruppe Feeds Feed einrichten/löschen für Thema Sitemap Generator konfigurieren Wiki ecommerce API Bereich für Gruppe freigeben Nutzung für Anwender / Institution freigeben Admin Mandant Admin Mandant Plattform Admin Admin Mandant Plattform Manager Rechte hat auf Sandbox Administrator Rechenzentrum Plattform Admin Plattform Admin, Sandbox Admin Admin Mandant Registrierung Registrierung einer Institution Registrierung eines Mitarbeiters bei einem Netzwerkmitglied Admin Mandant legitimieren Netzwerk User legitimieren Person registriert Automatische sich als Community Legitimation Mitglied (kann Personalisieren etc.) Minimalset der Rollen und Rechte Plattform Manager Admin Mandant Captcha, Mail Die bisherige Analyse läuft auf folgendes Minimalset an Rollen und Rechten hinaus: Seite 13, Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB)

14 Gruppe/Rolle * KWE und Partner stellen Mandanten der Plattform dar. Die Rechte müssen beim Login zugeteilt werden, hängen an der Session und gelten für alle Anwendungen der Plattform (single sign on). Abgesehen von den Applikationen, die die Plattform zur Verfügung stellt, kann es im Umfeld weitere Zugänge, etwa zu FTP Servern oder Source-Code-Verwaltungssystemen geben, die nicht direkt über die Plattform erreicht werden. Diese bleiben hier außer Betracht. Die Nutzerdaten (Loginname, Passwort) sollen nicht innerhalb der Plattform gespeichert werden, sondern über externe Authentifizierungssysteme (LDAP, OpenID, Shibboleth) realisiert werden. Über die Anmeldung können Mengenbeschränkungen beim Zugriff auf Ressourcen gesteuert werden, so dass Nicht- Angemeldete Nutzer nur eine limitierte Anzahl von Anfragen pro Minute an das System stellen können (Schutz vor DoS Attacken). Die Anmeldung ist außerdem eine Bedingung für jede kommerzielle Nutzung. Während bei einzelnen Anwendungen lediglich entschieden werden muss, ob der Nutzer das Portlet aktivieren und nutzen darf, muss bei andern das Rechtemodell des Portals in die Portlet- Anwendung hinein getragen werden. Dies ist zum Bespiel wegen der Mandantenfähigkeit beim CMS und beim CRM der Fall. Beschreibung legitimiert für 1.1 Anonym unbekannter Internetznutzer öffentliche Inhalte und Funktionen des Portals, Mengenbeschränkung beim Zugriff 1.2 Community registrierter Nutzer der Plattform 1.3 Netzwerk Vorstand, KNW 9, Betreiber, Partner wie (1.1) plus Personalisierung, Tagging, Bookmarks etc. wie (1.2) plus rollenabhängig Extranetfeatures 2.1 Superuser / Community Redakteur besonders aktiver Nutzer 2.2 Hauptredaktion Redakteur der KNW, auch Freigeber (eventuell trennen) 2.3 Redakteur des Mandanten wie (1.2) plus Betreuung von Community- Foren, Wiki-Seiten. Recht zum Löschen. wie (2.1), kann aber alle Inhalte für das Extranet sowie öffentlich sichtbare Inhalte redigieren. der KWE oder des Partners wie (1.2), kann aber Inhalte der Institution / des Partners redigieren. 3.1 Admin Mandant Admin einer KWE oder eines Partners kann weitere Mitarbeiter der Institution legitimieren 9 Kompetenznetzwerk Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB), Seite 14

15 3.2 Plattform Manager Mitarbeiter des Betreibers, verwaltet die Gesamtplattform rechtlich / organisatorisch 3.3 Plattform Admin gehört zum technischen Betreiber 3.4 Administrator Rechenzentrum gehört zum technischen Betreiber legitimiert weitere KWE und Partner, verwaltet Mehrwertdienste (ecommerce API) administriert die Plattform, installiert Anwendungen, Prozesse, Services. administriert die Infrastruktur der Plattform (Netz, Storage, Rechner). * wird noch weiter ausspezifiziert Webdesign Das Webdesign muss das Portalkonzept und die heterogene Datenlage berücksichtigen und soll in enger Abstimmung mit der Entwicklungsleitung in Sankt Augustin agil entwickelt werden. Die im öffentlichen Nutzungsbereich liegenden Anwendungen, aber auch Anwendungender Nutzungsbereiche der Community und des Betreiber- Netzwerks müssen gut an den Styleguide angepasst werden können. Für reine Verwaltungswerkzeuge - die nur von wenigen Administratoren genutzt werden - sollten besonders während der ersten Realisierungsphase die vorhandenen Tools verwendet und allenfalls grob angepasst werden. Die Einhaltung eines einheitlichen Gesamteindrucks wird dadurch erschwert, dass wir den Einrichtungen bei der Gestaltung ihrer Inhalte soweit möglich Freiraum lassen wollen. Eine Einrichtung soll natürlich die Möglichkeit haben, eine eigene About-Seite zu erzeugen und diese mit einem Logo und anderen Inhalten zu verbinden. Einige Einrichtungen werden vielleicht ausführlichere Seiten zusammenstellen, andere, besonders größere Einrichtungen werden vermutlich eher auf ihren vorhandene Webpräsenz verweisen Standards, Best Practices, Open Source, Qualität, Sicherheit, Mehrsprachigkeit Standards und best practices werden berücksichtigt, um Interoperabilität und Kompatibilität herzustellen, Austauschbarkeit von Komponenten zu erzielen, Fehler und Risiken zu minimieren und um anderen Entwicklern den Einstieg zu erleichtern. Die Projektartefakte dieses Projekts werden Open Source sein. Damit ergibt sich auf natürliche Weise eine Präferenz zur Verwendung von frei verfügbaren Open Source Produkten. Kommerzielle resp. Closed Source Produkte sind immer dann eine Alternative, wenn Open Source Produkte nicht in hinreichender Qualität und Zuverlässigkeit zur Verfügung stehen. Dessen ungeachtet ist die DDB gut beraten, kommerziellen Support / Wartung für die verwendeten Open Source Produkte zu kaufen. Für die kritischen Komponenten (Portal, CMS) ist das eine unverzichtbare Anforderung. Seite 15, Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB)

16 Das Portal muss mehrsprachig betrieben werden können. Wir verfolgen den Anspruch der vollen Lokalisierbarkeit zumindest aller im Nutzungsbereich liegenden Komponenten und Metadaten. Eine Lokalisierbarkeit der Verwaltungskomponenten wird ebenfalls angestrebt. In welche Sprachen die Inhalte und Label der Seite dann tatsächlich übersetzt werden sollen, ist keine technische Frage. Von technischer Seite soll jedoch sicher gestellt werden, dass eine Lokalisierbarkeit prinzipiell für jede gängige Sprache und insbesondere für UNESCO-Sprachen 10 jederzeit möglich wäre. Eine Lokalisierung der Metadaten ist unrealistisch. Ein Ausgleich für dieses Manko kann durch eine Übersetzung / Expansion des Query-Strings geschehen. An das Produkt, die Plattform der DDB, werden sehr hohe Qualitäts-, Sicherheits- und Performance-Anforderungen gestellt. Die Betriebssicherheit der Plattform und der zentralen Services muss ausfallsicher ausgelegt werden. Jeder Betriebsausfall wird dem Ruf der DDB nachhaltig schaden. Wie werden ein Verfahren zur Aufbereitung der Ergebnisse aus Suchanfragen entwickeln, das Duplikate bei der Präsentation von Suchergebnissen unterdrückt. Dazu müssen Ähnlichkeiten erkannt werden und ähnliche Inhalte geclustert werden. Das Konzept wird weiter unten skizziert. Die Einzeldarstellung der digitalen Objekte muss in einer Weise erfolgen, die das Objekt adäquat wiedergibt. Dabei ist der hohe Anspruch der Datenprovider zugrunde zu legen. Die Datenprovider der Datenobjekte müssen erkennbar sein. Zur Sicherung der Qualität, der Performanz und der Sicherheit des Systems, der Berücksichtigung relevanter Standards, und zur Prüfung, dass Anforderungen erfüllt werden, wird eine Qualitätssicherungsstrategie entwickelt und eine Verantwortlichkeit benannt Buzzword-Liste der Technologien, Tools und Standards Die folgende, fortlaufend zu erweiternde Liste relevanter Technologie- Buzzwords dient der Skillabfrage bei der Bildung von Teams: Plattform: HTTP, WSDL, REST, JSON, XML, XSLT, JSR 286, JCR, JCA, JAAS, Shibboleth, Kerberos, OpenID, JVM, JMS, UTF8. Digital Library: DELOS Digital Library Reference Model, OAIS, OAI-PMH, OAI- ORE, SRU, Open Search, RSS, Z39.50, DSpace, Fedora. Metadaten: DCMES, RDFa, GRDDL, FOAF, EAD, museumdat, LIDO, MARC, MARCXML, MAB, METS, MODS, Atom, Normdateien, Europeana EDM, SWD, GKD, PND, LCSH, DDC, VIAF, URI, IRI, ARK, DOI, Topic Maps, CIDOC CRM, URN. 10 Englisch, Französisch, Spanisch, Arabisch, Chinesisch, Russisch. Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB), Seite 16

17 1.2.8 Mengengerüst Multimedia Content: XHTML, Text, Digitalisate (Images, verschiedene Formate), Audio (verschiedene Formate, Streaming), PDF, Filme (verschiedene Formate, Streaming), 3-D Objekte. Die DDB Plattform und das Portal müssen in verschiedener Hinsicht skalieren. Für den Pilotbetrieb ist mit etwa 1-2 Millionen Objekten zu rechnen, bei Vollausbau sollen am Ende bis zu 300 Millionen Objekte gespeichert werden. Die Anzahl der registrierten Einrichtungen kann theoretisch bis auf über Dreißigtausend anwachsen. Wieviele Einrichtungen es in den nächsten Jahren tatsächlich werden, ist schwer abzusehen. Es ebenfalls schwer abzuschätzen, wieviel an redaktionellem Inhalt von den Einrichtungen innerhalb der DDB verwaltet werden wird. Ein mögliches Geschäftsmodell der DDB könnte darin liegen, interessierten Einrichtungen die Langzeitspeicherung ihrer Inhalte anzubieten. Aus Sicht der technischen Umsetzung gibt es keinen Grund, ein solches Modell zu verhindern. Wir werden allerdings zum gegenwärtigen Zeitpunkt keine Aufwände treiben, um ein Langzeitarchivierungssystem zu realisieren und planen daher kein Modul das sich im Sinne des OAIS Modells mit Preservation Planning befaßt. Für die zu erwartenden Nutzerzahlen gibt es bislang keine belastbare Schätzung. Zahlen können nur durch Vergleiche mit anderen Plattformen näherungsweise geraten werden. Das Internet Archive 11 etwa liefert zurzeit ca. 4,5 Millionen Page-Views täglich an etwa 1 Million IPs (was in etwa mit unique users gleichzusetzen ist). Ein Nutzer hält sich etwa 3 Minuten auf der Seite auf. Das lässt darauf schließen, dass das System dauernd zwischen und gleichzeitige Nutzer bedient. 12 Wir haben uns auf Grundlage der öffentlich zugänglichen Daten zum Internet Archive und zu Europeana eine Abschätzung des Traffics, des Speicherbedarfs und der Dateizugriffe vorgenommen. Die Schätzung differenziert nicht zwischen Zugriffen auf unterschiedliche Inhalte (statischer/dynamischer Content, Anfragen an Indexierer, an Tripel Store etc.), da diese Details bei aktuellen Planungsstand noch nicht abzusehen sind. Items Traffic IO Year Parallel users Number Quota of rich data Versions per Item Netto storage in TB MB/sec delta, per sec max, per sec ,10 2 0, ,20 3 1, ,30 4 5, , , Quellen: Seite 17, Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB)

18 , , , , Es werden hier Annahmen getroffen, die auf realistischen, aber letztlich hypothetischen Grundlagen beruhen. Es ist daher wichtig, die Zahlen iterativ Prüfungen zu unterziehen. Die Parallel Users meint gleichzeitig an das System Anfragen stellende Clients (Menschen oder Systeme). Diese Zahl kann mit zunehmenden Mashups stärker wachsen als angenommen. Number of Items bezeichnet die im Storage gelagerten Informationsobjekte und damit den Kerndatenbestand der DDB. Nicht beziffert sind eventuell ebenfalls im Storage liegende sekundäre Contentobjekte wie Termine, Einrichtungen, Autoren etc., die ebenfalls als Ressourcen verwaltet werden sollten. Quota of Rich Data ist der Anteil an Informationsobjekten der DDB, für die Digitalisate, bzw. generell binärer Content (Film, Audio, etc.) in der DDB vorhanden sind. Wir nehmen an, dass Provider ihre mögliche anfängliche Zurückhaltung, reichen Content zu liefern, zunehmend aufgeben werden. Versions of Item dient hier nur zur Berechnung des Storagebedarfs. Wir nehmen an, dass identische Objekte beim Re-Ingests nicht mehrfach gespeichert werden müssen (der Storage funktioniert nach dem Prinzip des Content Addressed Storage). Andernfalls müsste von erheblich mehr gespeicherten Content-Versionen ausgegangen werden. Netto Storage in TB meint, dass die vorliegende Berechnung nicht den für eine Datenverlustsicherung technisch nötigen Plattenbedarf berücksichtigt. Traffic in MB/sec trifft Annahmen für die über die Plattform ausgelieferte Datenmenge. Auch diese Größe kann durch Mashups nach oben getrieben werden, ebenso wie die Annahmen zur Anzahl der IO-Operationen pro Sekunde. Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB), Seite 18

19 2 Hauptkomponenten 2.1 Hauptkomponente Portal Die für die Öffentlichkeit gedachten Inhalte sind über das Portal für anonyme Nutzer zugänglich, werden aber in einem geschützten Bereich (Extranet / Verwaltung der DDB) redigiert und verwaltet. Die wesentlichen funktionalen Komponenten der Digitalen Bibliothek werden anonymen und angemeldeten Nutzern über das Portal angeboten. Die nichteingeloggten Nutzer haben einen eingeschränkten Zugang. In funktionaler Hinsicht ergibt sich die Einschränkung gegenüber eingeloggten Nutzern dadurch, dass einer Personalisierung erst nach dem Login möglich ist. Aus rechtlichen bzw. lizenzrechtlichen Gründen haben anonyme Nutzer keinen Zugriff auf den gesamten Bestand der Digitalen Bibliothek. Die für das Betreibernetzwerk sichtbaren Inhalte werden von Mitgliedern des Netzwerks bzw. einer Redaktion erstellt. Die Auswahl der in das Portal als Anwendungen zu integrierenden Komponenten ist noch nicht abgeschlossen. Im Juni 2010 werden Kriterienkataloge erstellt, Kandidaten identifiziert und erste Prototypen entwickelt. Welche Inhalte mit welcher Art von Anwendungen zu verwalten wäre, ist im folgenden Abschnitt dargestellt Inhaltliche Schwerpunkte des redaktionellen Contents Neben den funktionalen und verwaltungstechnischen Aspekten organisiert das Portal über verschiedene Tools eine Reihe von redaktionellen Inhalten. Die folgende Auflistung fasst die in den Anforderungen genannten redaktionellen Themen zusammen. Inhaltliche Schwerpunkte Seitentyp Zielgruppe Vorstandsbeschlüsse News Netzwerk Presse-Infos, Werbematerial, herunterladbare Pressemappe, Assets Microsite Öffentlichkeit Contentauswahl der DDB, Kollektionsausbau News, Wiki Öffentlichkeit Rechte und Lizenzen von Objekten Forum, Wiki Netzwerk Mitteleinwerbung Dienstleistungsangebote innerhalb der DDB (Partnerangebote) Interoperabilität Langzeitarchivierung Bestandserhaltung der Originale Digitalisierungsprojekte, -verfahren und -probleme News, Forum, Wiki Netzwerk News, Forum, Wiki Netzwerk News, Forum, Wiki Netzwerk News, Forum, Wiki Netzwerk News, Forum, Wiki Netzwerk News, Forum, Wiki Netzwerk About-Pages Microsite Netzwerk, Öffentlichkeit Seite 19, Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB)

20 Inhaltliche Schwerpunkte Seitentyp Zielgruppe Themenseiten Teaser, Microsite Netzwerk, Öffentlichkeit Termine Kalender Netzwerk, Öffentlichkeit Innovations-Lab der DDB: Geschäftsmodelle und Forum, Wiki Netzwerk Mehrwertdienste Einen gewissen Sonderfall stellen Community-Foren und -News dar, die von registrierten Nutzern gelesen und eventuell auch betreut werden könnten User Stories Portal Weitere Inhalte könnten sein: Wunschliste der DDB-Betreiber: hier signalisiert man Unterstützung und die Garantie eines Feed-Backs, wenn Punkte aus der Wunschliste aufgegriffen werden Rewards, etwa bei Themen wie Logo- und Icon-Design, die konkurrierend von mehreren Gruppen/Personen aufgegriffen werden können, wobei die beste Lösung,gewinnt. Als User Stories bezeichnet man in agilen Methoden wie Scrum (wird beim DDB Projekt eingesetzt) Artefakte, die in konventionellen Vorgehensmodellen Anforderungen heißen. Von User Stories erwartet man, ähnlich wie von Use Cases, klare Aussagen, die Nutzeraktivitäten darstellen (Nutzer können auch Maschinen sein). User Stories werden in Schätzklausuren zur Abschätzung des Aufwands herangezogen und dienen den Scrum Teams als Implementierungsgrundlage. Bei technischen Anforderungen ist es zuweilen nicht einfach, passende User Stories zu formulieren. Dennoch können User Stories helfen, die oft eher unkonkreten Anforderungen zu konkretisieren. AF-107 US-17 US-20 US-21 US-25 US-31 US-41 US-56 US-63 US-125 US-128 US-129 US-143 Container Ein Benutzer loggt sich mit einem einzigen Account ein, um auf zusätzliche Inhalte und Funktionen zugreifen zu können (z.b. personalisiert oder Extranet). Ein Mitglied des Extranets öffnet durch den Login von der Portal-Seite aus seine Startseite des Extranets. Nicht registrierte Benutzer und Einrichtungen können einen Registrierungsprozess starten, an dessen Ende sie eine Menge von Rollen bekommen (z.b. Teil des Betreibernetzwerkes). Es gibt genau ein Login-Feld zur DDB (Extranet + Portal) Ein Benutzer loggt sich ein und sieht abhängig von seiner Rolle unterschiedliche Inhalte Berechtigte Nutzer können Diskussionsforen für andere Nutzer einrichten. Berechtigte Benutzer können Objekte in einen Warenkorb legen und diesen rechteabhängig downloaden bzw. kaufen. Der User sieht sich die Site-Map an Für fremdsprachige Begriffe oder Texte erhält der Benutzer eine Übersetzung, sofern multilinguale Vokabularien zur Verfügung stehen. Den Kultur- und Wissenschaftseinrichtungen sind Werkzeuge für die Administration der Mehrwertdienste zur Verfügung zu stellen, die sie direkt über das DDB-Portal anbieten können. Den Kultur- und Wissenschaftseinrichtungen sind Werkzeuge für die Administration ihrer Verwertungsaktivitäten zur Verfügung zu stellen. Der User kann Digitalisate auf einem Datenträger bestellen. Grobkonzept für das Portal der Deutschen Digitalen Bibliothek (DDB), Seite 20