In einem Bildungsnetzwerk, wie der Nationalen Bildungsplattform sollten alle Repositorien ihre Statistiken für Statistikservices im Netzwerk bereitstellen. Damit wird die Verfügbarkeit (Anzahl, Qualität u.a. Eigenschaften) sowie die Verwendung (Anzahl, Feedback, Verwendungszweck) transparent. Dies hilft Entscheider:innen und Akteuren bei:

1. Lenken od. Investment für Erschließung oder Erstellung von Inhalten
2. Lenken od. Investment für Qualitätsverbesserung (zu den Inhalten selbst, oder zu Erschließung / Metadaten)
3. Informieren / Stöbernangebotfür Nutzende, die Inhalte zu einem Thema, einer Lizenz o.a. suchen
4. Quellen-Auswahlunterstützung (Information für Länder, Bildungsorganisation oder Fach-/Berufsgesellschaften, die für eigene Contentangebote für ihre Zielgruppe passende Quellen suchen)

Eingesammelt werden sollten Statistiken von allen Repositorien im Netzwerk. Das sind alle Systeme, die Bildungsinhalte in sich haben, z.B. Lernplattformen (Moodle, Ilias, Olat, Opal, StudIP, itsLearnig), Online-Editoren (Tutory, Serlo, Memucho, Quizzlet, Kahoo). Statistiken sollten auch Referatorien liefern, welche ihrerseits Verweise auf Inhalte sammeln (um dann Doubletten-Informationen zu erkennen braucht es für Inhalte eindeutige IDs).

Eingesammelt werden die Statistikinformationen in so einem Szenario von Statistikservices. Sinnvolles einzeitliches Sammeln und Auswerten ist nicht so einfach wie es klingt. Das zeigten JOINTLY-Hackathons (s.u.).

Diese Statistikservices könnten Teil von sogenannten Metadatensammelstellen werden, auch HUB oder Redaktionsknoten genannt. Solche Knoten sammeln zu einem Thema oder Sammelgebiet. Hier im Bild ist ein OER-Statistikservice dargestellt, der alle OER in Deutschland verweisen will und dazu auch die Statistikdaten sammelt. Statistikdaten sind Eigenschaften der Dokumente aber auch Verwendungshäufigkeiten.

In einem Bildungsnetzwerk würden Lernplattformen eines Bundeslandes oder einer größeren Organisation ihre Inhalteverwaltung über ein Repository oder Referatory des Landes organisieren, wie z.B. das OER-Repository ZOERR, dass Inhalte aus Lernplattformen Baden-Württembergischer Hochschulen "erschließt" und an andere Bundesländer und bundeszentrale Sammelknoten weitergibt. Lokal für die Redaktionen wie des ZOERR sind lokale Statistiken für die eigene Arbeit interessant. Für bspw. eine bundeszentrale Sammelstelle, wie das OERSI-Projekt sind alle OER-Statistiken des Hochschulbereichs interessant.

Sinnvoll ist eine Standardisierung von statistischen Auskünften, die eine Doublettenfilterung ermöglicht.

In diesem Artikel werden bisherige Arbeiten an diesem Thema, insbesondere die zwischen dem edu-sharing Open Source Team und Verein und dem Hochschulbibliothekszentrum NRW (OER Worldmap) zusammengefasst. Außerdem wird beschrieben, wie das edu-sharing Repositorium Verwendungsstatistiken aus angeschlossenen Lernplattformen sammelt und aggregiert (z.B. beim ZOERR).

1. Welche Statistiken sind für wen interessant

1.1 Politiker & Entscheider

1. Wie viele OER Repositorien gibt es im Bund / Land / Bezirk?
1. Wie viele Materialien sind da zu finden?
2. Wie viele OER Materialien gibt es insgesamt?

1.2 Repositorien / Informationsaggregatoren z.B. OER-Worldmap

Bezogen auf alle Materialien/ Nutzer, idealerweise aber auch je Suchanfrage/begriff
(in dem Repo vs. über Quellen angeschlossen):

1. MATERIAL-Anzahl
   1. INSGESAMT: Wie viele Inhalte sind in diesem System verfügbar
   2. FREI: unter freien Lizenzen (CC0/PD, By, NC, ND, SA)
   3. OER: unter OER(-förderlichen) Lizenzen (CC0/PD, BY, SA)
   1. LEARNING RESSOURCE TYPE (Videos, Arbeitsblätter, Kurse, Präsentationen)
   2. FILETYPE (video, bild, …, präsentation, ...)
   1. FACH/LEHRPLAN-THEMA
   2. SUBJECT
   3. BILDUNGSBEREICH / SCHULART
   1. Lernende / Schüler
   2. Lehrende
   3. ...
1. nach Offenheit: 
2. nach Materialarten
3. nach Themen (
4. Welche Zielgruppe wird angesprochen (Schule, Hochschule, …) nicht so relevant?
2. NUTZER-Anzahl
   1. INSGESAMT
   2. OER-NUTZER (haben schon mal OER verwendet)
   3. OER-Produzenten (haben OER veröffentlicht)
   1. Lernende (Nutzer ohne besondere Rolle)
   2. Lehrende
   3. Autoren
   4. Redaktion
   5. Admins/sonstige
1. nach Offenheit
2. nach Typ

1.3 Allgemeine interne Statistiken (z.B. je Objekt)

1. Wie oft wird das Objekt verwendet?
2. Wie oft wurde es heruntergeladen?
3. In wie vielen Sammlungen ist es enthalten? In welchen?
4. Wie viele Nutzer haben darauf Zugriff?

1.4 Interne Admins (Repo-Betreiber IT-Bereich)

1. Server-Auslastung 
2. Wie viele Anmeldungen / Logins?
1. Wie viele sind gerade aktiv? (genau jetzt oder bestimmten Zeitraum einstellen)
3. hochgeladene / neue Objekte
4. Wie viel Speicherplatz ist verfügbar?
1. pro Organisation / Schule
2. pro Nutzer
5. …

1.5 Interner Support (Hilfe zu Software und pädagogische Verwendung)

1. Wie oft wird welches angebundene Tool verwendet?
2. s.o. Admin-Statistiken zu logins

1.6 Interne Redaktion

1. Für wie viele Objekte bin ich / sind wir zuständig?
2. Überblick über Arbeitsstände der Redaktionsgebiete (Wie viele offene Materialien in der OER Babyklappe, …)
3. Woran wird besonders viel bzw. besonders wenig gearbeitet?
1. An welchen Sammlungen?
2. An welchen Materialien?
4. Wie viele 
1. Objekte gibt es?
2. Sammlungen gibt es?
5. Welche verschiedenen Objektarten gibt es + Anzahl (Bilder, Videos, ...)

1.7 Interne Normalo-User

1. Wie viele Objekte habe ich erstellt?
2. Welchen Anteil habe ich an Gesamtfülle des Repos?
3. Wo werden meine Objekte nachgenutzt?
1. in welchen Tools (LMS, …) - wie oft 
2. geografisch
4. Wie viel Speicherplatz ist belegt, wie viel ist noch verfügbar?

2. Wie sollten Statistik-Informationen angeboten werden

Schnittstelle (für Abrufe von anderen Systemen)

In Prototypen haben wir mit Statistikfunktionen experimentiert:

Statistischer Abruf

Um Statistiken extern verfügbar zu machen, sollte jedes Repositium eine Schnittstelle bereitstellen. Es wird empfohlen einen REST Endpunkt zu implementieren. 

REST GET Request Beispiel https://playground.oer-contentbuffet.info/edu-sharing/rest/statistic/v1/public

Optional kann ein Parameter “properties” übergeben werden um weitere Informationen über die abgefragten Materialien zu erhalten, z.B.

https://playground.oer-contentbuffet.info/edu-sharing/rest/statistic/v1/public?properties=cclom%3Ageneral_keyword

Unter https://playground.oer-contentbuffet.info/edu-sharing/swagger/index.html#!/STATISTIC_v1/getGlobalStatistics kann eine Implementierung des API Endpunktes getestet werden.

Die Antwort erfolgt im JSON-Format  und enthält die Objekte “repository”, “materials” und “user”.

Die Materialien sind untergliedert nach Lizenzen (s.u.).

Beispielausgabe als JSON-Format

{
  "repository": {
    "name": "Playground",
    "domain": "playground.oer-contentbuffet.info",
    "queryTime": 1532686258
  },
  "materials": {
    "licenses": [
      {
        "name": null,
        "type": null,
        "count": 82,
        "facettes": [
          {
            "name": "cclom:general_keyword",
            "count": {
              "nass": 1,
              "blue merle": 1,
              "Frauenwahlrecht": 3,
             ...  

              "nachdenklich": 1
            }
          },
          {
            "name": "cclom:format",
            "count": {
              "file-powerpoint": 3,
              "file-image": 44,
              "file-word": 6,
              "file-zip": 2,
              "file-txt": 1,
              "file-video": 3,
              "file-script": 1
            }
          }
        ]
      },
      {
        "name": "CC_0",
        "type": null,
        "count": 9,
        "facettes": [
          {
            "name": "cclom:general_keyword",
            "count": {
              "nass": 1,
              ...
              "hund": 4,
              "nachdenklich": 1
            }
          },
          {
            "name": "cclom:format",
            "count": {
              "file-image": 9
            }
          }
        ]
      }
    ]
  },
  "user": {
    "count": 0
  }
}

Selbstauskunft des Repos

Eine Schnittstelle, die allgemeine Informationen über das Repositorium liefert.

Entwurf eines REST API Endpunktes /rest/about-this-service mit JSON Response

(siehe https://docs.google.com/spreadsheets/d/1S98e9dyuLUh1fULXahLQpY15BYKmuqIxYzL4iBcCkhY/edit#gid=724356893)

Bsp JSON muss mit Tabelle synchronisiert werden.

{
  "name": "string",
  "url": "string",
  "icon": "string",
  "logo": "string",
  "country": "string",
  "primaryLanguage": "string",
  "description": [
    {
       "value": "string",
       "language": "string"
    }
  ],
  "type": "string",
  "audience": [
    {
      "id": "string"
    }
  ],
  "about": [ "string", "string" ],  //z.B. Mathe, Physik
  "coverage": "string",
  "public": true,    //öffentlicher Zugang?
  "provider": {
    "name": "string",
    "location": "http://schema.org/GeoCoordinates",
    "url": "string",
    "email": "string",
    "admin": "string",
  },
  "creationdate": "long",
  "interfaces": [
    {
      "type": "OAI",
      "url": "string",
      "set": "string",
      "metadataPrefix": "string"
    },
    {
      "type": "statistics",
      "url": "string"
    },
    {
      "type": "API",
      "url": "string"
    },
    {
      "type": "sitemap",
      "url": "string",
      "format": "string"   //microdata, rdfa, json-ld
    },
  ]
}

OpenSearch

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
  <ShortName>Web Search</ShortName>
  <Description>Use Example.com to search the Web.</Description>
  <Tags>example web</Tags>
  <Contact>admin@example.com</Contact>
  <Url type="application/atom+xml"
       template="http://example.com/?q={searchTerms}&amp;pw={startPage?}&amp;format=atom"/>
  <Url type="application/rss+xml"
       template="http://example.com/?q={searchTerms}&amp;pw={startPage?}&amp;format=rss"/>
  <Url type="text/html"
       template="http://example.com/?q={searchTerms}&amp;pw={startPage?}"/>
  <LongName>Example.com Web Search</LongName>
  <Image height="64" width="64" type="image/png">http://example.com/websearch.png</Image>
  <Image height="16" width="16" type="image/vnd.microsoft.icon">http://example.com/websearch.ico</Image>
  <Query role="example" searchTerms="cat" />
  <Developer>Example.com Development Team</Developer>
  <Attribution>
    Search data Copyright 2005, Example.com, Inc., All Rights Reserved
  </Attribution>
  <SyndicationRight>open</SyndicationRight>
  <AdultContent>false</AdultContent>
  <Language>en-us</Language>
  <OutputEncoding>UTF-8</OutputEncoding>
  <InputEncoding>UTF-8</InputEncoding>
</OpenSearchDescription>

GUI (Öffentliches Schaufenster)

Um die Statistik eines Repositoriums zu visualisieren wird ein Microservice verwendet, der die übergebenen statistischen Werte verarbeitet und graphisch darstellt. Der generierte HTML/JS Inhalt kann an beliebiger Stelle eingebunden werden. Es empfiehlt sich einen festen Pfad pro Repo zu benutzen, beispielsweise http://reponame.orga-nisation.de/open-statistics.

Ein solcher Visualisierungsservice ist unter http://appserver7.metaventis.com:3000/ erreichbar. 

Beim Aufruf wird der Parameter “statsUrl” erwartet. Übergeben wird hierbei der URL zum oben beschriebenen API Endpunkt.

Ein Beispielaufruf lautet

http://appserver7.metaventis.com:3000/?statsUrl=https://playground.oer-contentbuffet.info/edu-sharing/rest/statistic/v1/public

was folgendes HTML generiert

GUI (interne Ansichten für Nutzer, Admins, etc.)

Statistiken pro Repositorium

Statistiken für normale Nutzer

• im Profil des Nutzers
• …

Statistiken für Admins

• in Admin-Tools
• Statistiken, die einzelne Nutzer betreffen in Nutzerverwaltungs-Komponente!?
• Würde ich dann so vorschlagen, dass der Statistik-Endpunkt (als Admin) auch mit einen Nutzernamen aufgerufen werden kann -> gibt dann die regulären Statistiken zurück, aber nur für den betreffenden Nutzer

Statistik pro Objekt

Informationssammlung aus Recherchephase: Möglicherweise nutzbare Standards und Wissenssammlung zu OER-Repositorien-Selbstauskünften

lieben Dank an die Jungs von der OER-Worldmap für den Input, erstes hier zusammengefasst.

Ziel ist ja, dass Plattformen wie die OER-Worldmap Repsoitorien wie unseres oder Lernplattformen abfragen können (Issue Wordmap). Abgefragt wird einerseits “Wer bist du” und “Wie gefüllt bist du und wie gut wirst du genutzt”. Wie die Daten strukturiert sein sollten, dazu gibt es einerseits (wohl recht individuelle) Praxis und andererseits Standardisierung(sbemühungen), aber leider nicht DEN Standard, der weltweit weitgehend akzeptiert und realisiert wird.

1. Standards wie COUNTER existieren, scheinen recht hohen Einarbeitungs- und Entwicklungsaufwand zu fordern. Es gibt außerdem mehrere Standards. DINI hat 2013 mal eine Publikation dazu rausgebracht. Was später entstanden ist, habe ich ggf. noch nicht erwischt.
   insgesamt sprengt die richtig gründliche Einarbeitung unser Hackathon und “Entwicklung fürs Karma-Budget”
2. Felix von der Worldmap hat mir ein JSON Object (nochmal verständlicher) gesendet, was er als Selbstauskunft gut fände. Das basierte schon auf einigen Standards (Vokabularen gepflegt mit SKOS)
3. Außerdem wurde mir eine Google-Tabelle von über 100 OER-Repositorien gesendet (die die Wordmap einlesen will - issue), aus der man ersehen kann, für welche Informationen sich Infosammler interessieren.

Eine Mischung von 2 und 3 scheint unser pragmatischer erster Weg zu sein, der auch unseren Partnern von der Worldmap helfen würde, deutsche Repos und LMS in ihrer Landkarte zu erfassen und deren Inhaltsmenge und Nutzungsgrad anzuzeigen. 

Parallel sollten wir uns in die gängigen Standards einarbeiten und sukzessive und pragmatisch hilfreiche Teile nutzen sowie unbedingt die Teile, die etabliert sind also Nichtnutzung peinlich ist.

Die Empfehlung möchte ich auch für andere Entwicklungsbereiche (Anbindung von Tools, Metadatengenerierung, Mapping, Austausch) ausweiten.

http://www.opendoar.org/find.php?format=charts

https://www2.archivists.org/groups/saa-acrlrbms-joint-task-force-on-public-services-metrics/standardized-statistical-measures-an

https://edoc.hu-berlin.de/bitstream/handle/18452/2152/13-oas-en.pdf?sequence=1&isAllowed=y

https://www.projectcounter.org/code-of-practice-five-sections/3-0-technical-specifications/

Im Dokument genannt ist das Projekt https://www.projectcounter.org/

COUNTER serves librarians, vendors, intermediaries and others by facilitating the recording and exchange of online usage statistics. 

The Code of Practice enables content providers to produce consistent, comparable and credible usage data for their online content.

The COUNTER Code of Practice Release 4 provides guidance on data elements to be measured, definitions of these data elements, output report content and format, as well as on data processing and auditing. To have their usage statistics and reports designated COUNTER compliant, vendors must provide usage statistics that conform to the Code of Practice.

Es gibt eine Liste von mehr als 100 Repos, die irgenwer mal gesammelt hat:

Da kann man Felder für die Selbstauskunft abschauen: https://docs.google.com/spreadsheets/d/1mHxu3zPTo4QwldXStx9iVeOGkx9QUETo3jzNP86f84w/edit?pref=2&pli=1#gid=0 

http://www.niso.org/apps/group_public/download.php/14833/z39_88_2004_r2010.pdf

Vocabulare

https://github.com/hbz/vocabs-edu 

https://github.com/dcmi/lrmi/tree/master/lrmi_vocabs

Note für den Post

• Anzahl Materialien
• Unterschieden nach Typ (CC-LOM-Format)
• Unterschieden nach Lizenzen
• User ist vorgesehen (noch nicht fertig)
• Tages- und Monatsstatistik: Uploads und Bearbeitungen

Die aktuelle WLO-Suche speichert anonym folgende Daten

- nicht personalisierte Informationen zum Client:
  - Bildschirm-Größe
  - User-Agent
  - Spracheinstellung
  - eine von uns vergebene SessionID
- Suchbegriff
- Abgerufene Seite der Ergebnisse
- Anzahl der Ergebnisse
- Genutzte Filter
- Angeklickte Ergebnisse
- Lifecycle-Events, wie Wechsel oder Schließen des Browser-Tabs

siehe Telemetrie

3.13 Trackingsservices Verwaltung (GELB)

3.21 Rückmeldung Metadaten an Netzwerk