Anwenderworkshop

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

Inhalt

1. Grundlagen

2. Die Benutzeroberfläche

3. Allgemeine Funktionen

4. Funktionsweise und Workflows im Detail

Grundlagen

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

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

Die Datenstruktur - Beispiel

Organisation

Name Gründung Bestand

Klasse

Eigenschaften

Person

Name Alter Raum Arbeitet_für

Die Datenstruktur - Beispiel

Organisation

Name SLUBGründung 1556Bestand 8.940.000

Person

Name Max MustermannAlter 34Raum 35bArbeitet_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

Die Datenstruktur - Linked Data

Organisation

Name SLUBGründung 1556Bestand 8.940.000

Person

Name Max MustermannAlter 34Raum 35bArbeitet_für SLUB

arbeitet für

TripelMax Mustermann arbeitet für die SLUB

Subjekt

Prädikat

Objekt

Die Benutzeroberflächevon amsl

● Startseite○ Anmeldung○ Wissensbasen○ Navigation

● Ressourcenlistenansicht○ Übersichtsseite○ Wichtige Termine○ Aktuelle Änderungen○ Ressourcenliste

Die Benutzeroberfläche von amsl

● Detailansicht für Ressourcen○ Eigenschaften○ Versionen

● amsl-Kontextmenü● Volltextsuche

Die Benutzeroberfläche von amsl

Allgemeine Funktionen in amsl

● Neue Instanzen anlegen○ Feldtypen

● Instanzen editieren○ Eigenschaften hinzufügen/bearbeiten○ Klonen○ Löschen

Daten erstellen, bearbeiten, anlegen

Funktionsweise und Workflows im Detail

Wissensbasen

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

Wissensbasen I

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

Wissensbasen II

KlassenBedeutung und Verwendung

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

konsortiale Klassen I

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

konsortiale Klassen II

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

konsortiale Klassen III

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

konsortiale und lokale Klassen I

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.

konsortiale und lokale Klassen II

Vertragsjahresdaten

- tendenziell dynamische Informationen- Beispiele:

- einzelne Gegenstände des Vertrags (im Folgenden Vertragspositionen genannt)

- Preise- Ansprechpartner (Kontakte) - Beteiligung eines Konsortiums

konsortiale und lokale Klassen III

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)

konsortiale und lokale Klassen IV

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

konsortiale und lokale Klassen V

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

konsortiale und lokale Klassen VI

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

lokale Klassen I

Fakultät

- pro Bibliothek individuell

- soll Zuordnung der Medien zu Fakultäten ermöglichen

- noch nicht abschließend modelliert

lokale Klassen II

Shibboleth Informationen

- noch nicht abschließend modelliert

- in Zukunft: konkrete Aussagen über Shibboleth-Zugänge (etwa Rechte vordefinierte Nutzergruppe hinsichtlich bestimmter Zugangsformen)

lokale Klassen III

Vielen Dank für Ihre Aufmerksamkeit

Der Graphical SPARQL Builder

● Das Wissen ist in einer Datenbank abgelegt● amsl bietet vorkonfigurierte Ansichten● keine beliebigen Anfragen

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

Der Graphical SPARQL Builder