amsl - anwendungsworkshop und hands-on (l. unterdörfel, s. nuck)
DESCRIPTION
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.TRANSCRIPT
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