1. Projekt AMSL
ERMS mit Linked Data
Kick-off-Meeting sächsicher Hochschulbibliotheken
27.06.2014, UB Leipzig

2. AMSL
Next Steps
Überblick
AMSL
und
Linked
Data
AMSL
Daten und
Funktionen
Sachsen
Konsortium
AMSL
Community
Was ist
AMSL?
AMSL
Projekt

3. AMSL Projekt
Entwicklung eines Electronic Resource
Management Systems für Bibliotheken auf
Basis von Linked Data Technologien
Projektlaufzeit: 06/2013 - 09/2014

4. AMSL Projekt
Rahmenprojekt:
Wissenschaftskommunikation im
Semantischen Web
➔ 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 und Auswertung
aller Informationen, die im Lebenszyklus
einer E-Ressource vorkommen

7. Ziele
Zeitersparnis beim Verwalten von E-
Ressourcen, ohne Verschiebung des
Aufwands in die IT

8. Ziele
Integration in existierende Workflows und
Systemumgebungen

9. Ziele
Wissensgewinn im Bereich Linked Data

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. Was kann AMSL werden?

12. Was kann AMSL werden?
eine Diskussionsplattform für ERM in
Sachsen

13. Was kann AMSL werden?
eine gemeinsam genutze Software-
(Plattform)

14. Was kann AMSL werden?
eine kooperative Knowledgebase für das
Sachsenkonsortium

15. Was kann AMSL werden?
eine der ersten internen
Bibliotheksanwendungen auf Basis von
Linked Data

16. AMSL und Linked Data
Der Begriff Linked Data bezeichnet eine
Methode für die Veröffentlichung und
Vernetzung strukturierter Daten im Web.

17. 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.

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
● 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

20. Warum Linked Data?
Titel-
listen
(csv)
ZDB
(RDF/xml)
COUNTER
(xml)
Integration heterogener
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 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

23. 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

24. 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

25. AMSL KBs
Bibliothek A Bibliothek 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
➔ 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

28. 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

29. Geplanter Funktionsrahmen
➔ Automatisierter Download von COUNTER/Sushi
➔ Grafischer SPARQL Editor
➔ Erstellen, Organisieren und Teilen von Reports
➔ Unterstützung der GUI durch integrierte Suchmaschine

30. 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

31. Fragen und Diskussion