Projekt AMSL
ERMS mit Linked Data
Kick-off-Meeting sächsicher Hochschulbibliotheken
27.06.2014, UB Leipzig
AMSL
Next Steps
Überblick
AMSL
und
Linked
Data
AMSL
Daten und
Funktionen
Sachsen
Konsortium
AMSL
Community
Was ist
AMSL?
AMSL
Projekt
AMSL Projekt
Entwicklung eines Electronic Resource
Management Systems für Bibliotheken auf
Basis von Linked Data Technologien
Projektlaufzeit: 06/2013 - 09/2014
AMSL Projekt
Rahmenprojekt:
Wissenschaftskommunikation im
Semantischen Web
➔ SLUB Dresen und Avantgarde Labs
➔ UB Leipzig und InfAI
AMSL Team
Lydia Unterdörfel (Anforderungserhebung, Modellierung)
Andreas Nareike (Coding und Modellierung)
Norman Radtke (Coding und Modellierung)
Karsten Krahl (Systemadministration und Coding)
Leander Seige (Projektleitung)
Björn Muschall (Koordination)
+ InfAI (Outsourcing von 4 Teilbereichen)
+ AG E-Medien UBL (Anforderungsanalyse)
Ziele
Erfassung, Verknüpfung und Auswertung
aller Informationen, die im Lebenszyklus
einer E-Ressource vorkommen
Ziele
Zeitersparnis beim Verwalten von E-
Ressourcen, ohne Verschiebung des
Aufwands in die IT
Ziele
Integration in existierende Workflows und
Systemumgebungen
Ziele
Wissensgewinn im Bereich Linked Data
Was ist AMSL?
➔ AMSL ist ein Projekt
➔ AMSL ist eine Open-Source Anwendung
➔ AMSL ist Auseinandersetzung mit ERM
➔ AMSL ist Anforderungsanalyse
➔ AMSL ist ein Vokabular
Was kann AMSL werden?
Was kann AMSL werden?
eine Diskussionsplattform für ERM in
Sachsen
Was kann AMSL werden?
eine gemeinsam genutze Software-
(Plattform)
Was kann AMSL werden?
eine kooperative Knowledgebase für das
Sachsenkonsortium
Was kann AMSL werden?
eine der ersten internen
Bibliotheksanwendungen auf Basis von
Linked Data
AMSL und Linked Data
Der Begriff Linked Data bezeichnet eine
Methode für die Veröffentlichung und
Vernetzung strukturierter Daten im Web.
Grundkonzept
Grundkonzept LD
1. Verwende zur Bezeichnung von Objekten URIs.
2. Verwende HTTP-URIs, so dass sich die Bezeichnungen
nachschlagen lassen.
3. Stelle weitere Informationen bereit, wenn jemand eine solche
URI nachschlägt (mittels der Standards RDF und SPARQL).
4. Zu diesen Informationen gehören insbesondere Links auf andere
Dinge, die über ihre URIs aufgerufen werden können.
RDF: Resource Description
Framework
➔ Standard zur Beschreibung von Linked Data
Prinzip: jede Aussage besteht aus
Subjekt - Prädikat- Objekt (= Tripel)
Bsp.: Die ISSN 1234-5678 hat den Titel “Nature”.
RDF: <urn:ISSN:1234-5678> dc:title “Nature”.
LD Vokabulare
● Sammlung von Termen und Regeln, um bestimmte
Sachverhalte zu beschreiben
● pro Vokabular eigene Klassen & Prädikate
● via URI weitere Informationen hinterlegt (= Semantic
Web) = Bedeutung für jeden interpretierbar
● Elemente können nachgenutzt oder für spezifische
Probleme selbst entwickelt werden
Warum Linked Data?
Titel-
listen
(csv)
ZDB
(RDF/xml)
COUNTER
(xml)
Integration heterogener
Daten
ONIX
-PL
(xml)
in ein einheitliches, flexibles und
erweiterbares Datenmodell
Warum Linked Data?
➔ Trend mit Potential und steigender Verbreitung:
● ZDB Linked Data Service
● Ausarbeitung gemeinsamer Vokabulare und Empfehlungen der
DINI AG KIM
● lobid.org
● Global Open Knowledgebase (GOKb)
● etc.
AMSL und Linked Data
➔ AMSL nutzt OntoWiki (by AKSW) als Editor zum
Bearbeiten von RDF
➔ AMSL programmiert OntoWiki Extensions für den
Bedarf eines ERM Systems
➔ AMSL nutzt existierende und modelliert eigene
Vokabulare
AMSL-Vokabular
➔ projektorientiert, aber flexibel
➔ Sichtung, Wertung, Modellierung für Anforderungen
➔ Strategie:
1. vorhandene Vokabulare nutzen
◆ bibo, dc, umbel, aiiso, owl, foaf, vcard...
◆ COUNTER: Masterarbeit Annika Domin
2. ERMI-Paper der Digital Library Federation nutzen
3. neu erschaffen: http://vocab.ub.uni-leipzig.de/bibrm
Daten und Funktionen
Lokale Verträge
Verträge, Lizenzen
Pakete, Holdings
Administration
Workflow
Statistiken
Konsortiale Verträge
Verträge, Lizenzen
Pakete, Holdings
Administration
Workflow, Statistiken
Nationale Identifier
Bibliographische Metadaten
Paketinformationen
Nationale Lizenzen
Zentrale Services
Globale Identifier
Verlagsinformationen (ID)
Bibliographische Metadaten
Paketinformationen
Standard-Lizenzen
AMSL KBs
Bibliothek A Bibliothek B Bibliothek C Bibliothek D
derzeitiger Entwurf
...
Geplanter Funktionsrahmen
➔ Rechtemanagement über lokale und konsortiale KBs
➔ Konsortiale und lokale Sichten
➔ Erfasste Informationen werden pro Jahr archiviert
➔ Änderungshistorie auf Datenebene (roll-back)
➔ Erinnerungsfunktion
Geplanter Funktionsrahmen
➔ Upload lokaler und konsortialer Titellisten (Pakete)
➔ Anreicherung und Linking bibliographischer Metadaten (ZDB LD)
➔ Anreicherung und Linking weiterer KBs und Identifier
➔ Eingabe und Verknüpfung eigener ERM Metadaten
Geplanter Funktionsrahmen
Definition von Eingabeformularen via Vokabular und Templates
● Lizenz- und Vertragsinformationen (License Information)
● Nutzungsbedingungen (Terms of Use)
● Nutzungsstatistiken (Usage Statistics, COUNTER-compliant)
● Administrative Informationen (Administrative Information)
● Titel- und Produktinformationen (Bibliographic Data, Package
Management)
● Budget- und Rechnungsinformationen (Budget / Fund Management,
Invoicing)
● Kommunikation
Geplanter Funktionsrahmen
➔ Automatisierter Download von COUNTER/Sushi
➔ Grafischer SPARQL Editor
➔ Erstellen, Organisieren und Teilen von Reports
➔ Unterstützung der GUI durch integrierte Suchmaschine
Next steps
➔ Interne Evaluation
➔ Fertigstellung von Basisfunktionen
➔ Anpassung der KBs auf konsortiale
Funktionalität
➔ Definition Schnittstellen d:swarm Projekt
(SLUB Dresden)
➔ Testzugänge für Sachsen-Konsortium
➔ Nutzer-Workshop
Fragen und Diskussion

AMSL Kick-off-Meeting sächsischer Hochschulbibliotheken

  • 1.
    Projekt AMSL ERMS mitLinked Data Kick-off-Meeting sächsicher Hochschulbibliotheken 27.06.2014, UB Leipzig
  • 2.
  • 3.
    AMSL Projekt Entwicklung einesElectronic Resource Management Systems für Bibliotheken auf Basis von Linked Data Technologien Projektlaufzeit: 06/2013 - 09/2014
  • 4.
    AMSL Projekt Rahmenprojekt: Wissenschaftskommunikation im SemantischenWeb ➔ SLUB Dresen und Avantgarde Labs ➔ UB Leipzig und InfAI
  • 5.
    AMSL Team Lydia Unterdörfel(Anforderungserhebung, Modellierung) Andreas Nareike (Coding und Modellierung) Norman Radtke (Coding und Modellierung) Karsten Krahl (Systemadministration und Coding) Leander Seige (Projektleitung) Björn Muschall (Koordination) + InfAI (Outsourcing von 4 Teilbereichen) + AG E-Medien UBL (Anforderungsanalyse)
  • 6.
    Ziele Erfassung, Verknüpfung undAuswertung aller Informationen, die im Lebenszyklus einer E-Ressource vorkommen
  • 7.
    Ziele Zeitersparnis beim Verwaltenvon E- Ressourcen, ohne Verschiebung des Aufwands in die IT
  • 8.
    Ziele Integration in existierendeWorkflows und Systemumgebungen
  • 9.
  • 10.
    Was ist AMSL? ➔AMSL ist ein Projekt ➔ AMSL ist eine Open-Source Anwendung ➔ AMSL ist Auseinandersetzung mit ERM ➔ AMSL ist Anforderungsanalyse ➔ AMSL ist ein Vokabular
  • 11.
  • 12.
    Was kann AMSLwerden? eine Diskussionsplattform für ERM in Sachsen
  • 13.
    Was kann AMSLwerden? eine gemeinsam genutze Software- (Plattform)
  • 14.
    Was kann AMSLwerden? eine kooperative Knowledgebase für das Sachsenkonsortium
  • 15.
    Was kann AMSLwerden? eine der ersten internen Bibliotheksanwendungen auf Basis von Linked Data
  • 16.
    AMSL und LinkedData Der Begriff Linked Data bezeichnet eine Methode für die Veröffentlichung und Vernetzung strukturierter Daten im Web.
  • 17.
    Grundkonzept Grundkonzept LD 1. Verwendezur Bezeichnung von Objekten URIs. 2. Verwende HTTP-URIs, so dass sich die Bezeichnungen nachschlagen lassen. 3. Stelle weitere Informationen bereit, wenn jemand eine solche URI nachschlägt (mittels der Standards RDF und SPARQL). 4. Zu diesen Informationen gehören insbesondere Links auf andere Dinge, die über ihre URIs aufgerufen werden können.
  • 18.
    RDF: Resource Description Framework ➔Standard zur Beschreibung von Linked Data Prinzip: jede Aussage besteht aus Subjekt - Prädikat- Objekt (= Tripel) Bsp.: Die ISSN 1234-5678 hat den Titel “Nature”. RDF: <urn:ISSN:1234-5678> dc:title “Nature”.
  • 19.
    LD Vokabulare ● Sammlungvon Termen und Regeln, um bestimmte Sachverhalte zu beschreiben ● pro Vokabular eigene Klassen & Prädikate ● via URI weitere Informationen hinterlegt (= Semantic Web) = Bedeutung für jeden interpretierbar ● Elemente können nachgenutzt oder für spezifische Probleme selbst entwickelt werden
  • 20.
    Warum Linked Data? Titel- listen (csv) ZDB (RDF/xml) COUNTER (xml) Integrationheterogener Daten ONIX -PL (xml) in ein einheitliches, flexibles und erweiterbares Datenmodell
  • 21.
    Warum Linked Data? ➔Trend mit Potential und steigender Verbreitung: ● ZDB Linked Data Service ● Ausarbeitung gemeinsamer Vokabulare und Empfehlungen der DINI AG KIM ● lobid.org ● Global Open Knowledgebase (GOKb) ● etc.
  • 22.
    AMSL und LinkedData ➔ AMSL nutzt OntoWiki (by AKSW) als Editor zum Bearbeiten von RDF ➔ AMSL programmiert OntoWiki Extensions für den Bedarf eines ERM Systems ➔ AMSL nutzt existierende und modelliert eigene Vokabulare
  • 23.
    AMSL-Vokabular ➔ projektorientiert, aberflexibel ➔ Sichtung, Wertung, Modellierung für Anforderungen ➔ Strategie: 1. vorhandene Vokabulare nutzen ◆ bibo, dc, umbel, aiiso, owl, foaf, vcard... ◆ COUNTER: Masterarbeit Annika Domin 2. ERMI-Paper der Digital Library Federation nutzen 3. neu erschaffen: http://vocab.ub.uni-leipzig.de/bibrm
  • 24.
    Daten und Funktionen LokaleVerträge Verträge, Lizenzen Pakete, Holdings Administration Workflow Statistiken Konsortiale Verträge Verträge, Lizenzen Pakete, Holdings Administration Workflow, Statistiken Nationale Identifier Bibliographische Metadaten Paketinformationen Nationale Lizenzen Zentrale Services Globale Identifier Verlagsinformationen (ID) Bibliographische Metadaten Paketinformationen Standard-Lizenzen
  • 25.
    AMSL KBs Bibliothek ABibliothek B Bibliothek C Bibliothek D derzeitiger Entwurf ...
  • 26.
    Geplanter Funktionsrahmen ➔ Rechtemanagementüber lokale und konsortiale KBs ➔ Konsortiale und lokale Sichten ➔ Erfasste Informationen werden pro Jahr archiviert ➔ Änderungshistorie auf Datenebene (roll-back) ➔ Erinnerungsfunktion
  • 27.
    Geplanter Funktionsrahmen ➔ Uploadlokaler und konsortialer Titellisten (Pakete) ➔ Anreicherung und Linking bibliographischer Metadaten (ZDB LD) ➔ Anreicherung und Linking weiterer KBs und Identifier ➔ Eingabe und Verknüpfung eigener ERM Metadaten
  • 28.
    Geplanter Funktionsrahmen Definition vonEingabeformularen via Vokabular und Templates ● Lizenz- und Vertragsinformationen (License Information) ● Nutzungsbedingungen (Terms of Use) ● Nutzungsstatistiken (Usage Statistics, COUNTER-compliant) ● Administrative Informationen (Administrative Information) ● Titel- und Produktinformationen (Bibliographic Data, Package Management) ● Budget- und Rechnungsinformationen (Budget / Fund Management, Invoicing) ● Kommunikation
  • 29.
    Geplanter Funktionsrahmen ➔ AutomatisierterDownload von COUNTER/Sushi ➔ Grafischer SPARQL Editor ➔ Erstellen, Organisieren und Teilen von Reports ➔ Unterstützung der GUI durch integrierte Suchmaschine
  • 30.
    Next steps ➔ InterneEvaluation ➔ Fertigstellung von Basisfunktionen ➔ Anpassung der KBs auf konsortiale Funktionalität ➔ Definition Schnittstellen d:swarm Projekt (SLUB Dresden) ➔ Testzugänge für Sachsen-Konsortium ➔ Nutzer-Workshop
  • 31.