Alle Themen der Wissensbasis

Alle Themen der Wissensbasis

@mire
Articles Extras Plugin
Backup
Begutachtung (Peer Review)
Bibliotheksservice-Zentrum Baden-Württemberg(bsz)
Bildbearbeitung und Optimierung
Center für Digitale Systeme (CeDiS)
Common Log Format (CLF)
Connexions & Rhaptos (Rice Universität)
Custom Block Manager
Custom Block Manager OCS
Dateiformate LZA
digital peer publishing nrw
Discussion:Literaturverwaltung
disziplinäres Repositorium
DiVA (Digitala Vetenskapliga Arkivet) (Universität Uppsala)
Dokumenterstellung
Dokumentlieferung
Dokumentvorlage
DPubS (Digital Publishing System) (Cornell und Penn State)
DSpace
dublin core metadata element set
Editorial und Redaktionssystem
edoc-server
Einreichungsprozess
eJournal Hosting
eJournal und ePublishing Software Systeme
EPrints Services
External RSS Feeds
Fedora
FIZ Karlsruhe
functional requirements for bibliographic records (frbr)
Galley Icons
giga hamburg university press
GNU EPrints (Universität Southampton)
Google Site Search
Hamburg University Press: GIGA Journal Family
Hardware LZA
HathiTrust Digital Library (Kollaboration von 26 Forschungsinstitutionen der USA)
Humboldt Universität zu Berlin
Hyperjournal (Net7 und Universität von Pisa)
Indexierung & Suche
Institutionelles Repositorium
Jalali calendar support
Konvertierung
Kooperativer Bibliotheksverbund Berlin-Brandenburg (kobv)
Langzeitarchivierung
LatexRender support
Linksammlung Standards & Interoperabilität
linksammlung standards und interoperabilität
Literaturverwaltung
Living Documents
Metadaten
Metadatenerfassung (Digitalisierung)
Metadatenerfassung (Dokumenterstellung)
Metadatenerfassung (elektronische Zeitschriften)
Metadatenerfassung (ePublishing)
Metadatenerfassung (Repository)
MyCoRe
NLM Citation Plugin
Nutzungsstatistik
OCS - Open Conference Systems
OCS Plugins
OJS Plugins
ONIX DOI xml Export
Open Journal Systems OJS (Universität von British Columbia und Simon Fraser Universität)
Open Repositories.org
openaire-compliance
Paymethod::Moneris
Persistent Identifier LZA
Persitent Identifier
Piwik
Polished Theme
Popular Articles Block Plugin
Public Folder Browser Plugin
Publikations und Sammlungspräsentation
Publikationspräsentation & Browsing
Repositorien Software Details und Vergleiche
Repositorienhosting
Repositoriensoftware
Repositorium
Repository-Cookbook
repository-management
Retrodigitalisierung
Reviewer Index Plugin
Sammlung zu Standards und Interoperabilitäten
SciELO Export Plugin
Select Role Block
Simon Fraser University Library (SFU)
SLUB Dresden
Software LZA
Speicherung und Archivierung
Standards
start
Static Pages
Static Pages OCS
SWORD 1.2 Repository Deposit
Technischer Leitfaden - Fedora
Technischer Workflow LZA
Template:Vorlage für die Eingabe weiterer Repository Systeme
Thesaurus (tematres integration)
Topaz (Topaz Projekt)
Validierung
Vancouver Citation Plugin
Vergleich von institutionellen und disziplinären Repositorien
VG Wort Zählmarken
Views report
Virtuelle Forschungsumgebungen
Volltextdigitalisierung (OCR)
Wiedergabe multimedialer Inhalte
Zeitschriftenserver von Hamburg University Press


[Article: Repository-Cookbook | Diskussion ]
Startseite der CARPET Knowledge Base Seite aktualisieren Bearbeiten Versionen Download HTML Version

Inhaltsverzeichnis

[Edit]Repository Cookbook

Zu diesem Dokument: Anstelle eines ausformulierten Handbuches finden Sie im Folgenden aufbereitete Checklisten mit den wichtigsten Eckpunkten und Entscheidungen, die Sie beim Aufbau und Betrieb eines Repositoriums berücksichtigen sollten. Dieser Leitfaden richtet sich vorrangig an Personen und Institutionen, die erstmals beabsichtigen ein digitales Repositorium zu errichten. Darüber hinaus ist der Leitfaden als "Living-Document" angelegt und lädt daher jeden ein, eigene Erfahrungen einzubringen, zu ändern und zu ergänzen.

[Edit]Planung und Einrichtung

[Edit]Zielhorizont festlegen

  1. Institutionelles Repositorium oder disziplinäres Repositorium (Synonym: Dokumentenserver, Repository)
    1. Vergleich von institutionellen und disziplinären Repositorien
  2. Kooperationspartner (Nutzer) festlegen (z.B. Wissenschaftler, Bibliothekare, Informationswissenschaftler, Informatiker, Institutsleitung,)
  3. Berücksichtigen Sie folgende Grundsatzfragen:
    1. Welches sind die beabsichtigten Funktionen und Außenwirkungen des Repositoriums für die Institution?
    2. Liegt eine Marktanalyse vor, die Stärken und Schwächen des geplanten [1] identifiziert?
    3. Ist der angestrebte Leistungsumfang/Zweck des Dienstes skizziert?

[Edit]Ressourcen-/ Kostenplanung

  1. Bibliothekarisch
    1. Bestehen bereits nutzbare oder erweiterbare Publikations-Workflows an der Institution oder müssen diese erst eingerichtet werden? (Hinweis: Veröffentlichungsvorgänge in bestehende bibliothekarische Geschäftsgänge integrieren und software-basierte Workflowsysteme nutzen)
    2. Regelmäßige bibliothekarische Aufgaben sind hier:
      1. Sichtung eingereichter Dokumente
      2. Prüfung dieser Dokumente hinsichtlich inhaltlicher, technischer und rechtlicher Standards (insbesondere formale und technische Standardisierung und rechtliche Abklärung sollten nicht unterschätzt werden)
      3. Prüfung, Korrektur bzw. Erfassung der dazugehörigen Metadaten
      4. Erschließung und Veröffentlichung der Dokumente
  2. Informationstechnisch
    1. Aufwand für Installation und Konfiguration der Repositoriums-Software (s. nächster Punkt " Auswahl des Software-Systems (http://www.carpet-project.net/wissensbasis/wiki/Repository-Cookbook/#Auswahl_des_Software-Systems)]")[2]
    2. Regelmäßige Wartungsarbeiten des Softwaresystems (Updates, Anpassungen)
    3. Infrastrukturkosten
      1. Software (sofern keine standardisierte und kostenfreie open-source Lösung gewählt wird)
      2. Hardware: wird durch Mindestanforderung der Software und Skalierung des Systems bestimmt, für die Skalierung des System an anderen Diensten orientieren und beim Hersteller erfragen
      3. Betriebskosten (z.B. Strom, Netzwerkbetrieb, Langzeitarchivierung)
      4. Alternative Hosting: technischer Betrieb des Repositoriums wird an Serviceanbieter ganz oder teilweise gegen Gebühr ausgelagert (Outsourcing) (siehe 3.c.ii)
  3. Produktive Eingliederung in die Institution und Sichtbarkeit des Angebots
    1. Aufwand ist abhängig von geplanter Reichweite des Repositoriums sowie dem Grad der Integration in bereits an der Institution etablierte Systeme (z.B. virtuelle Lern- und Forschungsumgebungen) -> je geringer der Integrationsgrad desto geringer der Aufwand
      1. Inhaltsakquise durch Überzeugungsarbeit: Bestückung des Repositoriums mit Inhalten („Content“) durch regelmäßig wiederkehrende persönliche Ansprache von Wissenschaftlern sowie Informationsveranstaltungen bei Studierenden (als Nachfrager/Rezipienten bzw. künftige Publizierende)
      2. Langzeitarchivierung nur schwer kalkulierbar, derzeit (August 2011) sind noch keine einfachen und etablierten Lösungen verfügbar, wohl aber gute Ansätze wie das LOCKSS (Lots of Copies Keep Stuff Simple) Netzwerk
  4. Hinweis: Auf bereits vorhandene technische und personelle Ressourcen zurückgreifen
  5. Berücksichtigen Sie folgende Fragen:
    1. Gibt es bereits ein Repositorium oder eine andere Form der digitalen Speicherung von Publikationen?
    2. Besteht für Ihre Institution eine repräsentative Arbeitsgruppe und sind alle relevanten Stake Holder berücksichtigt?
    3. Sind finanzielle Regelungen getroffen, um den Dienst, kurz-, mittel- und langfristig betreiben zu können?
    4. Ist der technische Support für Probleme im Tagesbetrieb zuverlässig geregelt?

[Edit]Auswahl des Software-Systems

  1. Basis ist i.d.R. ein Standardserver (z.B. Apache, Tomcat) aus etablierten Open-Source-Komponenten; alternativ sind proprietäre Systeme wie Windows-Server oder Mac OS Server denkbar
  2. Auswahl einer Repositorien-Software
    1. Notwendiger Funktionsumfang der Software
      1. Mindeststandard
        1. Dokumentupload
        2. Metadatenerfassung durch Bibliothekar und/ oder Autor
        3. OAI-PMH (http://www.carpet-project.net/de/glossar/item/oai/) Schnittstelle (für Interoperabilität)
        4. Indexierung und Browsing entlang der Metadaten von Dokumenten
        5. Orientierung an den im aktuellen DINI-Zertifikat (http://www.dini.de/dini-zertifikat/) festgeschriebenen Mindeststandards
      2. Empfohlen
        1. Open-Source, weil selbständig erweiterbar, oft durch aktive Communities auch Hilfestellungen und i.d.R. kostenfreie Lizenz
        2. Langzeitarchivierungsfunktion(en)
        3. Erleichterung und Koordination von Verwaltungsvorgängen
        4. Möglichkeit der Einbindung in externe Software/Dienste
    2. Einfachheit von Installation und Wartung des Systems (gilt nur bei Selbstbetrieb der Software)
    3. Einfachheit und Intuitivität der Content-Pflege für die Nutzer des Systems
    4. Größe und Aktivität der dazugehörigen Software-Community sollte jeweils aktuell geprüft werden
    5. Empfohlene Open-Source Softwarestandardpakete
      1. DSpace (http://www.carpet-project.net/de/katalog/detail/carpet/dspace/)
        1. Vorteile:
          1. Speicherung und Verwaltung aller Dateitypen und Inhaltsarten
          2. Im-/Export in eine Vielzahl von Metadatenformaten (inkl. MODS, PREMIS)
          3. Out of the Box Software mit guter Dokumentation: deshalb kann man ein betriebsbereites Dspace-Repository mit Nutzer- und Adminoberfläche relativ einfach und schnell aufsetzen.
          4. differenziertes Rechtemanagement
          5. Embergomanagement
          6. aktive Community
        2. Nachteile:
          1. Erweiterte Suche: keine Boolean Logic
          2. internes Metadatenschema erlaubt keine Hierarchie
          3. Setbildung für die OAI-Schnittstelle nicht konfigurierbar
          4. weitere Schnittstellen, wie SRU, REST nicht robust
      2. MyCoRe (http://www.carpet-project.net/wissensbasis/wiki/MyCoRe/)
        1. Vorteile:
          1. hohe Anpassbarkeit, sowohl die Datenmodelle der zu speichernden Dokumenttypen und Metadatenbeschreibungen, als auch die Anwendung selbst können individuell und einfach in XML angepasst werden
          2. Großer Einsatzbereich:
            1. Bibliotheken
            2. Zeitschriftenserver
            3. Lexikon
            4. Archive mit großen Mengen an Digitalisaten
            5. Dokumentenserver
          3. Community ist zwar klein dafür jedoch beständig. Alle Entwickler sind an universitären Rechenzentren oder Bibliotheken tätig. Es gibt 14-tägige Telefonkonferenzen und regelmäßige Treffen. Die Vermittlung zwischen MyCoRe-Nutzern und Entwicklern findet derzeit über die MyCoRe-Geschäftsstelle statt.
        2. Nachteile:
      3. Fedora Commons (http://www.carpet-project.net/de/katalog/detail/carpet/fedora-commons-1/)
        1. Vorteile: Speicherung und Verwaltung aller Dateitypen und Inhaltsarten, Darstellung für Endnutzer ist beliebig konfigurierbar abhängig vom gewählten Content-Management-System (CMS) das an Fedora angedockt werden muss (da kein eigenes vorhanden), jedes XML Metadatenformat kann genutzt werden
        2. Nachteile: kann keine Thumbnail Previews von Image, PDF, Text, Images erstellen, kein Endnutzer Interface, keine Unterstützung von Mehrsprachigkeit, keine Fachspezifische Suche, Erweiterte Suche: keine Boolean Logic,
      4. EPrints (http://www.carpet-project.net/de/katalog/detail/carpet/gnu-eprints/)
        1. Vorteile: BibTeX, DIDL, EndNote, JSON, MODS, CSV, ORE, OpenURL, RDF, Refer, RefMan, XML; Erweiterte Suche: Boolean Logic,
        2. Nachteile:
      5. OPUS (http://www.carpet-project.net/de/katalog/detail/carpet/opus-4/)
        1. Vorteile:
        2. Nachteile:
  3. Auswahl einer Betriebsvariante
    1. Installation eines Standardpakets auf einem eigenen Server (Inhouse-Lösung); das System sollte nur aus erprobten und stabilen Komponenten bestehen
    2. Externes Hosting eines Standardpakets durch einen externen Serviceanbieter (Outhouse-Lösung)
    3. Eigenentwicklung (nur in Ausnahmefällen und nach gründlicher Abschätzung des Aufwandes empfehlenswert)
  4. Entscheidung: Selbstbetrieb vs. Hosting
    1. Argumente für den eigenen technischen Betrieb
      1. Volle technische Kontrolle über diesen Dienst
      2. Minimierung von externen Abhängigkeiten
      3. Evtl. bereits vorhandenes Knowhow kann durch den Betrieb genutzt und ggf. erweitert werden
      4. Möglichkeit: künftig selbst als Hosting-Betreiber durch gewonnene Expertise und Profilierung aufzutreten und den eigenen Dienst durch externe Einnahmen kostengünstiger zu betreiben
    2. Argumente für eine Auslagerung des technischen Betriebs
      1. Kalkulierbare regelmäßige Kosten
      2. Keine Personalbindung
      3. Keine Aufwendungen für technische Infrastruktur



[Edit]Auswahl der Hardwareausstattung

Softwarehersteller machen i.d.R. (Mindest-)vorgaben, darüber hinaus gilt:

  1. Beachtung des gegenwärtigen Institutsstandards; bestehende Ressourcen sollten wenn möglich gemeinsam genutzt werden; Varianten:
    1. Shared Server: mehrere virtuelle Maschinen mit mehreren Instanzen einer Software oder verschiedene Arten werden gleichzeitig auf dem selben physischen Computer (Host) betrieben (kostengünstiger aber weniger performant als ein Dezidierter Server)
    2. Dezidierter Server: ein zweckgebunden arbeitender Host mit nur einem Server also nur einer Aufgabe (dedicated service) oder nur einem Kunden (i.d.R. eine physische kann aber auch eine zweckgebundene virtuelle Maschine sein)
  2. 'Rechnerkapazität und Speichervolumen sollten in Abhängigkeit der erwarteten Zugriffszahlen und Datenmengen gewählt werden und zum Zwecke der Skalierung möglichst erweiterbar sein
  3. Begrenzung der Ausstattung durch die verfügbaren bzw. festgelegten finanziellen Mittel

[Edit]Betriebskonzept

  1. Konzept für die Gewährleistung einer angemessenen Verfügbarkeit des Systems (i.d.R. wird bei einem 24/7-Betrieb die 100%-Marke angestrebt, realistisch sind aber aufgrund von Ausfallzeiten und Wartungsarbeiten lediglich 99%)
  2. Gewährleistung der Sicherung und Wiederherstellung von Dokumenten und Metadaten durch geeignete Technologien
  3. Ausfallzeiten entgegenwirken durch:
    1. aktuelles gespiegeltes System das im Notfall das Produktivsystem ersetzen kann (Redundanz)
    2. fehlertolerantes und robusten Gesamtsystem (Stichwort: Hochverfügbarkeit)
    3. schnell verfügbares Fachpersonal
    4. Verfügbarkeit von Ersatzteilen
    5. Regelmäßige Wartungsarbeiten
    6. Qualifiziertes Fehlermeldungs-, Überwachungs- und Alarmsystem

[Edit]Dokumentation

  1. Technisches System
    1. Beschreibung des eingesetzten Systems
      1. Softwarekomponenten
        1. Versionsnummer
        2. Gegenseitige Abhängigkeiten von Komponenten
        3. Eigene Änderungen am Code
        4. Weitere technische Parameter
      2. Hardware
        1. Hersteller
        2. (CPU-)Geschwindigkeit
        3. Speichergröße
        4. Weitere technische Parameter
  2. Regelung für Zugang zum Server und Benennung der Verantwortlichen
    1. Personenkreis mit räumlichem Zugang
    2. Personenkreis mit Systemlogin-Zugang (z.B. Administratoren)
    3. Personenkreis mit rechtlichen/ redaktionellen/ inhaltlichen Verantwortlichen
    4. Ort an dem das Administratorenpasswort hinterlegt ist (z.B. Direktionssekretariat)
  3. Berücksichtigen Sie folgende Fragen:
    1. Sind Rollen und Verantwortlichkeiten (besser positions- als personenabhängig) für den mittel- und langfristigen Betrieb des Repositoriums definiert?

[Edit]Usability/ Nutzbarkeit

  1. Intuitivität der Benutzeroberfläche(n) für Wissenschaftler und Bibliothekare
  2. Darbietung der Dokumente in einem gängigen Präsentationsformat i.d.R. PDF (Portable Document Format); bei anderen Formaten sollte immer auch der Downloadlink zu einer frei nutzbaren Visualisierungssoftware angeboten werden
  3. Dokumente sollten ausdruckbar sein; bei Verwendung eines DRM (Digital Rights Management) Schutzes ist dies möglicherweise problematisch
  4. Dokumenten-Qualität: Sonderzeichen, Strukturen, Multimediaelemente sollten erkennbar sein
  5. Ausführbarkeit der Hyperlinks im Dokument

[Edit]Leitlinien (Policies)

  1. Detaillierte Beschreibung des Dienstes als geschlossenes Dokument und direkte und sichtbare Verlinkung darauf von der Hauptwebseite des Dienstes (i.d.R. Startseite)
  2. Policy-Inhalte
    1. Grundsätze, Ziele & Dienstleistungsfunktionen des Repositoriums;
      Beispiel: „Zielsetzung des Repositoriums ist es, den Angehörigen der Institution X die organisatorischen und technischen Rahmenbedingungen zum elektronischen Publizieren wissenschaftlicher Dokumente zu bieten. Über das Internet sollen wissenschaftliche Dokumente unter Einhaltung von Qualitätsstandards für Forschung und Lehre bereitgestellt werden. Die elektronische Veröffentlichung ist für Angehörige der Institution und von mit ihr assoziierten Einrichtungen kostenfrei. Die für eine Veröffentlichung notwendigen zusätzlichen Arbeiten (Aufbereitung der elektronischen Dokumente oder Konvertierung in andere Formate) werden seitens des Dienstanbieters gewährleistet.“
    2. Definition der Zielgruppen (z.B. Autoren, Herausgeber, Rezipienten)
    3. Inhaltliche und technisch-qualitative Kriterien für die Aufnahme und Erfassung von Publikationen in das Repositorium
    4. Technischer Betrieb (Leistungsparameter des Dokumentenservers und Benennung der Verantwortlichen für den technischen Dienst)
    5. (Langzeit-)verfügbarkeit des Dienstes und der Dokumente
    6. Rechte und Pflichten des Dienstanbieters/ der Autoren /der Herausgeber (siehe: Urheberrecht (http://www.urheberrechtsbuendnis.de/), geistiges Eigentum)
    7. Maßnahmen zum Schutz gegen Verfälschung des Dokuments (z.B. per digitaler Signatur, Zeitstempel (siehe: rechtswirksames Echtheitszertifikat)
    8. Maßnahmen zur dauerhaften Auffindbarkeit von Dokumenten durch dauerhafte Webadressen (siehe: URN (http://www.carpet-project.net/de/glossar/item/urn/))
    9. Garantieerklärung zur Mindestverfügbarkeit (5 Jahre dürfen lt. DINI-Zertifikat nicht unterschritten werden)
    10. Definition des Projektumfangs (Archivierungszeiträume, Publikationsvolumen, Publikationsarten: „Was wird gespeichert?“ z.B. rein elektronische Publikationen, elektronische Versionen gedruckter Publikationen, Dissertationen, Habilitationsschriften, Dokumente von Studierenden)
    11. Open-Access-Erklärung (Darlegung welcher Teil des Angebotes im Sinne von Open-Access frei verfügbar ist bzw. welcher Teil nicht, außerdem die generelle OA-Strategie des Dienstes)

[Edit]Unterstützung für Autoren und Herausgeber

  1. Art und Umfang variiert je nach Ausrichtung des Services und Art der Dokumente
  2. Grundsätze für Autoren:
    1. Überzeugungsarbeit durch Darlegung der Vorteile dieser Publikationsform
    2. öffentlich zugängliche Informationen sowie Angebot der persönlichen Beratung (WWW, Email, Telefonnummern, Ansprechpartner)
    3. Unterstützung des gesamten Publikationsprozesses inkl. technischer und rechtlicher Fragen (Stichwort: SHERPA/RoMEO (http://www.sherpa.ac.uk/romeo/)-Liste zu urheberrechtlichen Bestimmungen)
    4. Bereitstellung von Onlineformular(en) zur Einbringung von Pre-/Postprints (Dateiupload, Metadatenvergabe)
    5. Bereitstellung von Dokumentvorlagen oder Stylesheets zur formalen Anfertigung wissenschaftlicher Publikationen
    6. Angebot eines Dokumentenbereitstellungs-Services durch den Repositoriumsbetreiber (Metadatenerschließung, PDF-Umwandlung und Archivierung der Publikation)
    7. Perspektivisch: Weiterbildungsangebot „elektronisches Publizieren“ für wissenschaftliche Autoren

[Edit]Rechtliche Aspekte

  1. Sicherstellung der unbedenklichen, urheberrechtlichen Verwertbarkeit für elektronische Archivierung muss für jede Publikation eines Autors/ Herausgebers geprüft werden
  2. Grundlage: In Form eines Copyright-Transfer-Vertrags (Deposit License) zwischen Dokumentenlieferant und Dienstbetreiber
  3. Grundsätzliche Unterscheidung:
    1. Primärpublikation
      1. Abschluss von Autorenverträgen
      2. Rechtseinräumung vom Autor/Herausgeber an den Dienstbetreiber:
        1. Elektronische Speicherung und Archivierung, öffentliche Bereitstellung zur individuellen Nutzung (Bildschirmwiedergabe und Ausdruck)
        2. Meldung und Weitergabe der Daten an Dritte (z.B. Bibliotheksverbünde, Langzeitarchivierungseinrichtungen)
        3. Anfertigung von Kopien und Konvertierung des Dokuments unter Wahrung inhaltlicher Integrität
      3. Rechtseinräumung vom Dienstbetreiber an den Autor/ Herausgeber:
        1. Bereitstellung der Publikation/ des Dokuments auf Server(n) der Institution
        2. Lizenzierung der publizierten Inhalte nach einem Lizenzmodell
      4. Versicherungserklärung vom Autor/ Herausgeber an den Betreiber bzgl. Rechte Dritter:
        1. Versicherung an den Betreiber, dass keine Rechte Dritter durch die elektronische Bereitstellung der Publikation oder Teile davon verletzt werden
        2. Freistellung des Betreibers von etwaigen Ansprüchen Dritter
        3. Klärung der Haftungsfrage bei Schadensersatz oder Rechtsfolgen
        4. Rechtssituation ist in den Metadaten jedes Dokuments zu speichern und bei Publizierung öffentlich zugänglich zu machen
    2. Autorenkopie
      1. Lizenzierung der Publikation durch den Autor, um Rechtssicherheit für alle Beteiligten zu gewährleisten (Autor, Rezipient, Repositorium-Anbieter)
      2. Voraussetzung: Open-Content-Lizenz für das Dokument, die den Nutzungsumfang des Werks eindeutig regelt u.a.
        1. Creative Commons Licence (CCL)
        2. Digital Peer Publishing Licence (DPPL)
        3. Open-Source Lizenzen (http://www.opensource.org./licences/) (z.B. GNU – General Public Licence)
        4. Deposit Lizenzen (http://open-access.net/de/allgemeines/rechtsfragen/lizenzen/depositlizenzen/#c1911) (z.B. SSOAR Deposit Licence)
      3. oder: Autorenvertrag, der die Bereitstellungsrechte von digitalen Autorenkopien enthält
      4. oder: Vertragsergänzung als Bereitstellungsregelung von digitalen Autorenkopien
    3. Tipp: es empfiehlt sich Hilfe durch die Rechtsstelle der jeweiligen Institution einzuholen und sich auf den Webseiten der DINI und IUWIS zu informieren
    4. Allgemeine Rechtsanforderung: Das Webangebot muss ein Impressum enthalten, das den Anforderungen des Telemediengesetzes (TMG) sowie ggfs. weiteren insb. Landesgesetzen gerecht wird

[Edit]Informationssicherheit des Dienstes

  1. Absicherung gegen:
    1. (Hacker-)Angriffe
    2. Missbrauch
    3. Fehlbedienung
    4. Technische Ausfälle
  2. Grundlegende Kriterien hierzu finden Sie in den Common Criteria (http://standards.iso.org/ittf/Publicly-AvailableStandards/index.html) (Int. Standard ISO/IEC 15408)
  3. Technisches Gesamtsystem
    1. Integration des Repositoriums in das übergreifende Sicherheitskonzept der betreibenden Institution
    2. Berücksichtigung von Risiken auf den Ebenen
      1. technisch (Betriebskonzept inkl. Wartungsplan s. oben 5. und Dokumentation s. oben 6.)
      2. organisatorisch
      3. personell
    3. Verantwortlicher: i.d.R. Sicherheitsbeauftragter
    4. Integrierung eines (technischen) Kontrollsystems zur Sicherstellung inhaltlich und rechtlich gewünschter Dokumente bei der Aufnahme in das Repositorium
    5. Schutz vor Suchmaschinenindexierung bestimmter Bereiche des Repositoriums (z.B. durch robots.txt Datei)
  4. Handhabung von Dokumenten
    1. Eingebrachte Dokumente dürfen inhaltlich nicht verändert werden
    2. Nachträgliche Änderung sind als neue „zusätzliche“ Versionen zu speichern; Alle Versionen sind zugänglich zu halten
    3. Datenübertragen beim Hochladen sollte per SSL (Secure Sockets Layer) und auf Basis vertrauenswürdiger Zertifikate erfolgen
    4. Datenintegrität der Dokumente ist über Hash-Verfahren und digitale Signaturen i.V.m. elektronischen Zeitstempeln sicherzustellen
    5. Langfristiger Zugriff auf ein Dokument muss mit einem Persistent Identifier (PI) erfolgen; der auch für folgende Zwecke einsetzbar ist:
      1. Dublettenprüfung
      2. Authentifizierungsmechanismen
      3. Zusammenführung von verteilt gespeicherten Dokumenten
      4. dauerhafte Zitierbarkeit eines digitalen Objekts
    6. Beispiele für Persistent Identifiers (http://www.persistent-identifier.de/):
      1. National Bibliography Number (NBN) als Unterraum von Uniform Resource Name (URN) die wiederum ein spezielles Schema von Uniform Resource Identifier (URI) darstellen
      2. Digital Object Identifier (DOI) (http://www.doi.org/) hptsl. für Online-Artikel von wissenschaftlichen Fachzeitschriften
      3. Persistent URL (PURL) (http://purl.oclc.org/)
      4. Handle (http://www.handle.net/)
      5. Archival Resource Key (ARK)

[Edit]Interoperabilität des Dienstes

  1. Akzeptierte Dateiformate
    1. Festlegung der Formate in der Policy
    2. PDF als gängigstes Format, aber auch Postscript, Rich Text Format und Multimediaformate
    3. Abgabeformat der Autoren ist i.d.R. nicht für Webpräsentation und Langzeitarchivierung geeignet
    4. Wahl des Formats sollte abhängig gemacht werden von:
      1. Nutzerakzeptanz des Formats
      2. Verfügbarkeit von Umwandlungsprogrammen (Convertern)[3] in dieses Format
      3. Zweck den das Repositorium verfolgt
    5. Die eingereichte Originaldatei ist immer mit zu archivieren; Ausnahme: Langezeitarchivierung
  2. Erschließung
    1. Mittels beschreibender Metadaten die zur maschinellen Weiterverarbeitung öffentlich bereit gestellt werden sollen; Zweck: Auffindbarkeit von Dokumenten und inhaltliches Suchen über mehrere Dokumentenserver hinweg
    2. Sachliche Erschließung der Dokumente mithilfe schriftlich fixierter und online bereitgestellter Leitlinien:
      1. Verwendete Erschließungsinstrumente
      2. Maßgaben zu dessen Anwendung
    3. Klassifikatorische Erschließung ist jener mit freien Schlagwörtern vorzuziehen
    4. Empfehlung: internationale Erschließungsinstrumente gemäß DINI-OAI-Empfehlungen
      1. Klassifikation nach Dewey-Dezimalklassifikation (DDC)
      2. Erfassung des Dokumenten-/Publikationstyps gemäß DINI-Empfehlung „Gemeinsames Vokabular für Publikations- und Dokumententypen“
      3. Verwendung mindestens eines weiteren normierten Systems verbaler oder klassifikatorischer Erschließung (allgemein oder fachspezifisch), z.B.:
        1. Schlagwortnormdatei (SWD)
        2. Library of Congress Classification (LCC)
        3. Library of Congress Subject Headings (LCSH)
        4. ACM Computing Classification System (CCS)
        5. Mathematics Subject Classification (MSC)
        6. Physics and Astronomy Classification Scheme (PACS)
      4. Verbale Verschlagwortung sollte auch in Englisch erfolgen
      5. Linklisten zur Verschlagwortung sollten für Suchmaschinen-Robots verfügbar sein
      6. Zu jedem digitalen Objekt sollte es eine prägnante Kurzbeschreibung (Abstract) geben
  3. Schnittstellen
    1. als Integrationsinstrument zum Einfügen des Dienstes in die eigene Informationsinfrastruktur und in externe Dienste (z.B. Service Provider, Fach-Communities mit Fachrepositorien ohne eigene Volltextinhalte)
    2. Zusammenführung des Repositoriums mit anderen bestehenden Diensten über ein lokales System zur Vereinheitlichung, z.B.:
      1. Shibboleth (Verfahren zur verteilten Authentifizierung und Autorisierung für Webanwendungen und Webservices)
      2. Lightweight Directory Access Protocol (LDAP)
      3. Central Authentication Service (CAS)
    3. Tipp: Manche Softwarelösungen für Repositorien haben dieses Feature standardmäßig, andere müssen kostenintensiv dafür angepasst werden
    4. OAI-PMH-2.0 als populärste ReposiorienSchnittstelle (nach den OAI-Richtlinien von DINI) ist als „Herzstück“ eines modernen Repositoriumsdienstes zwingend erforderlich und ist Bestandteil aller gängigen Softwarelösungen für Repositorien (z.B. DSpace, OPUS, MyCoRe, EPrints), diese funktionale Softwarekomponente liefert Metadaten der Dokumente des Repositoriums als Data Provider auf protokollgemäße Anfragen an einen Service Provider; weitere Vorteile:
      1. Gewährleistet die Beibehaltung eigener spezifischer Methoden zur Erfassung und Verwaltung von Daten
      2. Möglichkeit zur Verknüpfung der eigenen Daten mit denen anderer zu einem virtuellen, vernetzten Super-Repositorium
      3. Relativ einfach in einen Repositoriumsdienst zu integrieren und in der Bedienbarkeit (Nachteil: nur rudimentäre Abfragemöglichkeiten)
      4. Fähigkeit zum Austausch komplexer Metadatenschemata
    5. OAI-PMHAnforderungen:
      1. Dauerhafte Verfügbarkeit unter der registrierten Basis-URL
      2. Unterstützung des inkrementellen Harvestings
      3. Verwendung konsistenter Set-Informationen
      4. Verwendung der englischen Sprache für deskriptive Informationen in OAI-Antworten (z.B. für Anfragen Identify, setName, ListSets)
      5. Web-Schnittstelle für Endnutzer um auf Dokumente und Metadaten zuzugreifen
    6. Zusätzlich zu OAI-PMH werden bei Bedarf von komplexeren Abfragen folgende aufwändigere Schnittstellen genutzt:
      1. Search/Retrieve Web Service Protocol (SRW) oder Search/Retrieve via URL (SRU) per Retrieval-Sprache Contextual Query Language (CQL)
      2. Z39.50 Protokoll
      3. Nicht geeignete als Harvesting Protokolle: RSS, Atom
    7. Im-/und Export von Metadaten aus bibliographischen Datenbanken (z.B. Literaturverwaltungsprogramme, Verbünde, OPACs) sollte unterstützt werden
    8. Es ist eine visuelle Webschnittstelle für Endnutzer einzurichten, über die der Zugriff auf alle verfügbaren Dokumente sowie deren Metadaten möglich ist
  4. Metadaten
    1. Empfehlung: Metadaten sind grundsätzlich frei anzubieten
    2. Auslieferung mindestens im Format Dublin Core Simple (ISO 15836:2003) mit den Elementen:
      1. creator
      2. title
      3. date
      4. type
      5. identifier
    3. .Empfehlung: Hinzufügen weiterer, komplexerer Formate
      1. XMetaDissPlus
      2. Dublin Core Qualified
      3. ONIX
      4. MARCXML, MARC21
    4. Bei Langzeitarchivierung werden standardisierte technische und administrative Metadaten hinzugefügt; Formate:
      1. PREMIS (PREservation on Metadata Implementation Strategies)
      2. LMER (Langzeitarchivierungsmetadaten für elektronische Ressourcen)
    5. Entscheidung für weitere Formate abhängig von der Zielsetzung und dem Bestand des Dienstes
  5. Berücksichtigen Sie folgende Fragen:
    1. Wie soll mit Duplikaten, Ressourcen- und Metadatenübertragung verfahren werden?


[Edit]Zugriffsstatistik von Dokumenten

  1. Zugriffstatistiken für einen Dokumentenserver ermöglichen die Aggregation von Nutzungsdaten eines abgerufenen Dokuments und damit einen Mehrwert für den Publizierenden
  2. Problem: Datenschutz
    1. Daten sind zu anonymisieren
    2. Dokumentation und Beschreibung der Kriterien (Erstellung und Aufbereitung der Statistik) muss öffentlich einsehbar sein
    3. Sinnvoller Hinweis an die Nutzer: „Diese Zugriffswerte erlauben ausschließlich die Vergleichbarkeit bzgl. der Dokumente auf diesem Server.“
  3. Dynamisches Hinzufügen der Zugriffszahlen als Dokumentmetadaten; Tipp: Sichtbar für den Endnutzer
  4. Empfehlung: Aufbereitung der Web-Server-Logs nach etablierten Standards wie bspw. COUNTER, OA-Statistik oder PIRUS

[Edit]Langzeitarchivierung/ -verfügbarkeit der Dokumente

  1. Archivierte Dokumente müssen min. 5 Jahre verfügbar gehalten werden, diese Gewährleistung ist auch in der Policy zu verankern (s. 8.)
  2. Gewährung einer dauerhaften Verbindung der Metadaten mit dem Dokument
    1. Über Persistent Identifier (s. 11.)
    2. Über ein Containerformat wie PDF/A
  3. Zwei Wege (je nach finanziellen und technischen Möglichkeit der Institution):
    1. Selbst betriebene Archivierung z.B. per Depotsystem nach OAIS (Open Archival Information System)
    2. Externe Archivierung als Kooperation im Verbund mit anderen Repositorien z.B. per LOCKSS (Lots of Copies Keep Stuff Safe) über das das Projekt LuKII
  4. Unterlassung oder Entfernung von technischen Schutzmaßnahmen, wenn diese Mechanismen zukünftige Migration oder Emulation ausschließen und damit die Benutzbarkeit der Dokumente einschränken werden
  5. Nutzung geeigneter Formate für Langzeitarchivierung
    1. Open Document Format (ODF)
    2. Portable Doument Format für Archivierung (PDF/A)
    3. ASCII-Text (TXT)
    4. TeX Formate (z.B. LaTeX)
    5. HTML
    6. XML (sehr geeignet, da medienneutral und Trennung von Inhalt, Struktur, Layout innerhalb des Dokuments möglich)
  6. Tipp: Empfehlungen des Kompetenznetzwerks „nestor“ beachten

[Edit]Betrieb und Nutzergewinnung

[Edit]Content Akquise und Erschließung von Dokumenten

  1. Hauptstrategie
    1. Offensives Marketing, Aufklärungs- und Öffentlichkeitsarbeit (soweit finanzielle/personale Mittel dies erlauben)
  2. Empfehlenswerte Strategien
    1. Gezielte Ansprache von Wissenschaftlern durch
      1. Aktivierung und Überzeugung bestehender wissenschaftlicher Kontakte
      2. Vorbehalte und Widerstände gegenüber Open Access ausloten und systematisch an diesen Punkten ansetzen
      3. Unterstützung von Autoren suchen, die bereits in Open Access publiziert haben (Stichwort: Meinungsmultiplikatoren)
      4. Verweise auf vorbildhafte Wissenschaftler des jeweiligen Fachbereichs geben, die bereits auf dem Dokumentenserver publiziert haben (z.B. mit persönlichem Kommentar zum Dienst)
      5. Gezielte Ansprache von Personen die bereits auf ihrer eigenen Homepage publizieren
      6. Schaffung eines Basiskontingents an Dokumenten durch Kontaktierung „grüner Verlage“ die Selbstarchivierung zulassen; dadurch gezielte Ansprache der dort publizierenden Wissenschaftler die dem Zielpersonenkreis des Repositoriums angehören
    2. Institutionelle Selbstverpflichtung
      1. Explizite Bekennung der Institution zu Open Access
      2. Aufforderung der Wissenschaftler zur Open Access Publikation in dem Repositorium
    3. Institutionelle Verankerung
      1. Enge Zusammenarbeit mit der Hochschulleitung und mit Ansprechpartnern der Fachbereiche sind unerlässlich für langfristigen Erfolg
      2. Leitungsorgane der Fachbereiche besitzen i.d.R. das Vertrauen und Ansehen des wissenschaftlichen Personals sowie z.T. Publikationsdatenbanken bestehend aus Volltext- und bibliographischen Datenbanken
    4. Informations- und Schulungsveranstaltungen
      1. Vorstellung von Open Access und des Repositoriumdienstes in Instituten und Gremien
      2. Schulung des Personals z.B. zum Thema
        1. Anmelden von Dokumenten
        2. Urheberrecht
        3. Prinzipien von Open Access
    5. Weitere Werbemaßnahmen
      1. Nutzung von Events und der PR-Abteilung der Institution
      2. Qualitätsdarstellung der eingestellten Dokumente
        1. Instrumente: Qualitätsmanagement z.B.
          1. Einführung von Reihen mit sehr hohen Maßstäben für Dokumente
          2. Exponierte Darstellung besonders relevanter Dokumente (z.B. mithilfe von Top-Download-Listen)
      3. Nutzung interner Medien
        1. Platzierung von Artikeln,Nachrichten und Profilen im internen Newsletter
      4. Nutzung von Online (WWW-Seiten auch mit audiovisuellen Inhalten, Mailverteiler) und gedruckten Medien (Flyer, Broschüren, Plakate, Postkarten)
        1. Für alle Medien gilt: leicht verständlich und optisch ansprechend
    6. Metadatenbasiertes Repositorium
    7. Tipp: „Wie füllt man die Open-Access-Dokumentenserver?“ (Graf, Klaus)

[Edit]Sichtbarkeit und Vernetzung

  1. Von zentraler Bedeutung inner-/außerhalb der Institution für Leser, Autoren, Herausgeber, indizierende Suchmaschinen & Nachweisdienste
  2. Vernetzung des Dienstes durch:
    1. Kontaktdetails für Nutzerbetreuung auf der Website des Repositoriums angeben
      1. E-Mail Adressen
      2. Telefonnummern
      3. Benennung von Ansprechpartnern
    2. Vernetzung des Dienstes mit Webseiten der betreibenden Institution, Aggregatoren und Portalen (z.B. als OAI Data Provider bei DINI (http://www.dini.de/dini-zertifikat/repository/), Open DOAR (http://www.opendoar.org/), ROAR (http://roar.eprints.org/), OAI (http://www.openarchives.org/))
    3. Vernetzung des Dienstes innerhalb der inter-/nationalen Community von Repositorienbetreibern durch:
      1. Einspeisung der Metadaten in übergreifende Recherchedatenbanken
      2. Registrierung des Dienstes und der OAI-Schnittstelle bei:
        1. Der offiziellen OAI-Registratur
        2. Verzeichnissen (ROAR, OpenDOAR, DRIVER, OAIster, Openarchives.org)
        3. Zentralen Diensten
  3. Sichtbarkeit der Inhalte durch:
    1. Zugriff auf das Gesamtangebot über die Website der betreibenden Institution
    2. Verlinkung von der Website der betreibenden Institution auf die Website des Repositoriums
    3. Verfügbarkeit und Zugriff auf alle Dokumente des Repositoriums per Link
    4. Motivierung von Dozenten Open-Access-Verweise auf ihren Literaturlisten zu platzieren (Fachbibliothekare sollten hier hilfreich die Lehrenden unterstützen)
    5. Public Relations (PR)
      1. Einbeziehung des Repositoriums in die PR-Aktivitäten und Newsservices der Institution gerichtet an die Pressemedien und Bevölkerung
      2. Ziel ist hier nicht die Bekanntheit des Repositoriums als solches, sondern die der Dokumente durch das Anbieten von Links zu Volltexten des Repositoriums zu unterstützen
    6. (Google-)Sitemap um Suchmaschinen bei der Indexierung des Repositoriums zu unterstützen
    7. RSS-Newsfeeds
      1. Die Nutzer informieren, wenn im Repositorium oder bestimmten Teilbereichen (Fächer) davon neue Dokumente zugänglich sind
      2. Feeds können auch automatisiert von anderen Computern eingelesen und die Informationen entsprechend weiterverarbeitet werden
    8. Forschungsmanagement
      1. Um die Forschungsqualität zu verbessern, sollten sich Repositorienbetreiber zum Ziel setzen, detaillierte und systematische Verfahren zur Zusammenstellung bibliographischer Informationen über Forschungspublikationen zu bieten
      2. Sollen zentrale Forschungsmanagementsysteme in einer Institution zum Einsatz gebracht werden, sollten Repositorien in diese Informationsinfrastruktur fest eingebunden werden
      3. Platzierung von Forschung in OA-Repositorien und die damit einhergehende Sammlung , Erfassung und Beobachtung von Nutzungsdaten erhöht auch die Sichtbarkeit und Image der Einrichtung; Grund: bibliometrische Indikatoren als Zeichen für Qualität gewinnen zunehmend an Bedeutung
  4. Verbindungen zu Fachbereichen intensivieren
    Fachbereiche nutzen Repositorien vielfältig:
    1. Die Bewertung und Beurteilung wissenschaftlicher Arbeit setzt mit der Sichtung der Arbeitsergebnisse an (Bestandsaufnahme der Publikationen im Berichtszeitraum); Gutachter können mithilfe des Repositoriums über Literaturlisten hinaus direkt auf die Publikationen zugreifen
    2. Fachbereiche bieten auf Websites oft Publikationslisten an, die mit Hilfe von Daten des Repositoriums automatisiert erzeugt werden können (Vorteil: kein mehrmaliges Eingeben und Reduzierung von manuellen Übertragungsfehlern)
      1. Als Gesamtlisten des Fachbereichs
      2. Als individuelle Publikationsliste auf der Homepage des Wissenschaftlers
  5. Weitere Maßnahmen
    1. Dienste zum Durchsuchen von Repositorien sollten in die öffentliche Standardsuche der Institutswebsite eingebunden werden
    2. Förderung und Ausbau repositorienbasierter Suchdienste durch Registrierung bei entsprechenden Diensten (z.B. Open DOAR Content Search, ROAR’s Google Search, OAIster); Vorteil gegenüber Google und Google Scholar: es werden mit hoher Wahrscheinlichkeit OA Volltexte als Suchergebnisse angezeigt
  6. Berücksichtigen Sie folgende Fragen:
    1. Wie soll das Repositorium im Informationsumfeld der Institution positioniert werden; gibt es eine institutionsweite Strategie für das Informationsmanagement?


  1. ^ Dienstes
  2. ^ Für die technische Ausstattung eines Repositoriums stellt DRIVER folgende Kostenrechnung auf: Für etwa 2100 € lässt sich Soft-ware auf einem Standard-Server installieren. Hinzu kommen Arbeitskosten von etwa 1000 €. Weitere etwa 3000 € kommen – den Erfahrungen mit dem SHERPA-Projekt zufolge – in den ersten sechs Monaten der Laufzeit hinzu für Anpassungsarbeiten wie insbe-sondere die Entwicklung des Erscheinungsbildes und die Integration in Betreuungs- und Wartungsmechanismen der Trägerinstitution. Danach können die laufenden technischen Arbeiten in der Regel in die Standardwartungsdienste der Institution eingegliedert werden. Vgl.: http://www.driver-support.eu/tech/index.html. Diese Zahlen schließen Personalkosten mit ein.
  3. ^ Einen Überblick über mögliche Formatumwandlungen bietet das Glossary of Possible Conversions der Organisation Eu-ropéenne pour la Recherche Nucléaire (CERN).



Last changed: 27.08.2012 12:21 (CID: 1135) by Stefan Daniel -
Startseite der CARPET Knowledge Base Seite aktualisieren Bearbeiten Versionen Download HTML Version

Nach oben

No data


Benutzeranmeldung

Anmelden


Dieses Werk bzw. dieser Inhalt ist unter einer Creative Commons-Lizenz (CC BY-NC-SA 3.0) lizenziert.
Diese Webseite erfasst anonymisierte Daten zur Nutzung. Sie können dies für die Dauer ihres Besuchs unterbinden, indem sie folgenden Link klicken: Session Cookie deaktivieren