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