Am 26.09.2014 fand in der SLUB Dresden ein 2. amsl Workshop statt. Neben der Ergebnispräsentation der EFRE-Förderphase hatten die Teilnehmer Gelegenheit, die Anwendung zu nutzen.

1. Anwenderworkshop
Electronic Resource Management mit amsl.
Lydia Unterdörfel, Sebastian Nuck
SLUB Dresden, 26.09.2014

2. Inhalt
1. Grundlagen
2. Die Benutzeroberfläche
3. Allgemeine Funktionen
4. Funktionsweise und Workflows im Detail

3. Grundlagen

4. Die Datenstruktur
● Datenkonzept (Klasse)
○ gibt Struktur vor mit der Wissen über ERM abgebildet
wird, z.B. Organisation oder Person
○ hat Eigenschaften wie Adresse usw.
● Instanz (Ressource)
○ tatsächliche Organisation oder Person
○ Exemplar einer Klasse
● Eigenschaft
○ Zeichenwert (Literal) oder
○ Ressource, und damit Verbindung zwischen Instanzen

5. Die Datenstruktur
● Datenkonzept (Klasse)
○ gibt Struktur vor mit der Wissen über ERM abgebildet
wird, z.B. Organisation oder Person
○ hat Eigenschaften wie Adresse usw.
● Instanz (Ressource ≠ elektronische Ressource)
○ tatsächliche Organisation oder Person
○ Exemplar einer Klasse
● Eigenschaft
○ Zeichenwert (Literal) oder
○ Ressource, und damit Verbindung zwischen Instanzen

6. Die Datenstruktur - Beispiel
Organisation
Name
Gründung
Bestand
Klasse
Eigenschaften
Person
Name
Alter
Raum
Arbeitet_für

7. Die Datenstruktur - Beispiel
Organisation
Name SLUB
Gründung 1556
Bestand 8.940.000
Person
Name Max Mustermann
Alter 34
Raum 35b
Arbeitet_für SLUB
arbeitet für
Die Ressource Max
Mustermann ist eine
Instanz der Klasse Person
Die Ressource SLUB ist eine
Instanz der Klasse
Organisation

8. Die Datenstruktur - Linked Data
Organisation
Name SLUB
Gründung 1556
Bestand 8.940.000
Subjekt
Person
Name Max Mustermann
Alter 34
Raum 35b
Arbeitet_für SLUB
Prädikat
arbeitet für
Tripel
Max Mustermann arbeitet für die SLUB
Objekt

9. Die Benutzeroberfläche
von amsl

10. Die Benutzeroberfläche von amsl
● Startseite
○ Anmeldung
○ Wissensbasen
○ Navigation
● Ressourcenlistenansicht
○ Übersichtsseite
○ Wichtige Termine
○ Aktuelle Änderungen
○ Ressourcenliste

11. Die Benutzeroberfläche von amsl
● Detailansicht für Ressourcen
○ Eigenschaften
○ Versionen
● amsl-Kontextmenü
● Volltextsuche

12. Allgemeine Funktionen in
amsl

13. Daten erstellen, bearbeiten, anlegen
● Neue Instanzen anlegen
○ Feldtypen
● Instanzen editieren
○ Eigenschaften hinzufügen/bearbeiten
○ Klonen
○ Löschen

14. Funktionsweise und
Workflows im Detail

15. Wissensbasen

16. Wissensbasen I
konsortiale Informationen
- enthält für alle Konsortialmitglieder relevante ERM-Informationen
- Verwaltung der Klassen Organisation, Kontakt und Plattform
- außerdem: Klassen Vertragsbasis- und Vertragsjahresdaten (bilden
gemeinsam vollständigen Vertrag), Paket und Vertragsposition
(jeweils konsortial)
- Daten für alle teilnehmenden Bibliotheken sichtbar und
weiterverwendbar

17. Wissensbasen II
lokales ERM
- enthält nur für die jeweilige Institution gültige ERM-Informationen
- Klassen: Vertragsbasis- und Vertragsjahresdaten, Paket und
Vertragsposition (jeweils lokal)
- außerdem: Klassen Budget, Fakultät und Shibboleth-
Informationen (optional)
- Daten werden von jeder Bibliothek individuell erstellt und nur
für diese sichtbar

18. Klassen
Bedeutung und Verwendung

19. konsortiale Klassen I
Organisation
- Bibliotheken, Unternehmen und Konsortien
- treten in einem Vertrag in verschiedenen Funktion auf:
Lizenznehmer, Lizenzgeber, Herstellers, Zahlungsempfänger,
beteiligtes Konsortium
- Kontaktpersonen (Kontakte) können Organisationen
zugeordnet sein

20. konsortiale Klassen II
Kontakt
- real existierende Personen
- treten in 2 Funktionen auf:
- als externe Ansprechpartner
- als hausinterne Ansprechpartner (auf Seiten der Bibliothek)
zu Verträgen
- i. d. R. mindestens einer Organisation zugeordnet

21. konsortiale Klassen III
Plattform
- Oberfläche, über die auf eine elektronische Ressource
zugegriffen wird
- Verlage, Aggregatoren...
- geplant: Verknüpfung mit weiterer Klasse, die detailliertere
Aussagen über Shibboleth-Zugänge liefert

22. konsortiale und lokale Klassen I
Vertragsbasisdaten + Vertragsjahresdaten = Vertrag
- vollständiger Vertrag → Vielzahl von Informationen
- i. d. R. ändert sich ein Teil der Informationen nach einem Jahr
= Vertragsjahresdaten
- ein Großteil der Informationen bleibt häufig gleich
= Vertragsbasisdaten
- Vorteil: für einen Folgevertrag müssen nur Vertragsjahresdaten neu
angelegt werden
- bei Verknüpfung mit bestehenden Vertragsbasisdaten
→ vollständiger Vertrag

23. konsortiale und lokale Klassen II
Vertragsbasisdaten
- tendenziell statische Informationen
- Beispiele:
- Nutzungsbedingungen der elektronischen Ressource
(Aussagen zu autorisierten Nutzergruppen, Print- und
digitalen Kopien, Remote Access, Fernleihe usw.)
- zugehörige Plattform
- Lizenznehmer und Lizenzgeber
- Produktbeschreibung des Anbieters usw.

24. konsortiale und lokale Klassen III
Vertragsjahresdaten
- tendenziell dynamische Informationen
- Beispiele:
- einzelne Gegenstände des Vertrags (im Folgenden
Vertragspositionen genannt)
- Preise
- Ansprechpartner (Kontakte)
- Beteiligung eines Konsortiums

25. konsortiale und lokale Klassen IV
Paket
- Bündel mehrerer elektronischer Medien
- “Zwischenebene” zwischen Vertrag und einzelnen Medien
- wird benutzt um Eigenschaften abzubilden, die nicht für den
gesamten Vertrag gelten
- wichtig: nur wenn mehrere Pakete in einem Vertrag existieren!
(nicht vom Namen der ER irritieren lassen)

26. konsortiale und lokale Klassen V
Vertragsposition
- einzelne e-Medien im Kontext eines Vertrages und einer
bestimmten Vertragslaufzeit
- entweder einem Paket zugeordnet (wenn in einem Vertrag
mehrere Pakete existieren) oder direkt an einen Vertrag
(Vertragsjahresdaten) geknüpft
- notwendig, um den Preis eines Mediums in einem bestimmten
Jahr und Vertrag abzubilden
- zeigen ausgewählte Informationen aus der ZDB

27. konsortiale und lokale Klassen VI
Zeitschrift
- sind (initial) importierte ZDB-Ressourcen
- werden über eine Hilfskonstruktion (die der ZDB-Nummer eine
ISSN-Nummer zuordnet) mit Vertragspositionen verknüpft
- über Zuordnung von VP zu VJD → alle Informationen
- bisher kein Anwendungsfall, bei dem amsl-Nutzer Zeitschriften
selbst anlegen müssten

28. lokale Klassen I
Budget
- pro Bibliothek individuell
- mit Verträgen (VJD) verknüpfbar
- dienen keinen Finanzverwaltungszwecken
- bloße Zuordnung, um so Aussagen darüber treffen zu
können, welche Verträge über ein bestimmtes Budget gelaufen
sind

29. lokale Klassen II
Fakultät
- pro Bibliothek individuell
- soll Zuordnung der Medien zu Fakultäten ermöglichen
- noch nicht abschließend modelliert

30. lokale Klassen III
Shibboleth Informationen
- noch nicht abschließend modelliert
- in Zukunft: konkrete Aussagen über Shibboleth-Zugänge (etwa
Rechte vordefinierte Nutzergruppe hinsichtlich bestimmter
Zugangsformen)

31. Vielen Dank für Ihre
Aufmerksamkeit

32. Der Graphical SPARQL
Builder

33. Der Graphical SPARQL Builder
● Das Wissen ist in einer Datenbank abgelegt
● amsl bietet vorkonfigurierte Ansichten
● keine beliebigen Anfragen

34. Der Graphical SPARQL Builder
● Das Wissen ist in einer Datenbank abgelegt
● amsl bietet vorkonfigurierte Ansichten
● keine beliebigen Anfragen
→ Graphical SPARQL Builder
○ Erstellung von Reports
○ Anfragen von Informationen die so nicht in amsl
angezeigt werden (z.B. Liste von Organisationen mit
entsprechenden Kontaktpersonen)
○ Speicherung dieser Anfragen