Commit f6c352be authored by Ronny Gey's avatar Ronny Gey 👾
Browse files

articles online and archived

parent 284e49a2
# ManuMedImporter
Das Open-Source-Werkzeug ManuMedImporter überführt Daten aus dem [HIDA](https://www.startext.de/produkte/hida)-Format in das interne [Kitodo](https://www.kitodo.org/)-Format. Die Metadaten im HIDA-Format stammen aus dem Katalog der [Manuscripta Mediaevalia](http://www.manuscripta-mediaevalia.de/). ManuMedImporter wird auf der Kommandozeile ausgeführt, findet seine Anwendung im Digitalisierungsworkflow der UB Leipzig und wurde in Java implementiert. [Felix Kreißig](https://github.com/fe-kre), der Hauptentwickler von ManuMedInporter, hat uns etwas zur Software und zum Anwendungsgebiet erzählt.
## Das Grundproblem
An der UB Leipzig befindet sich [eines](https://www.ub.uni-leipzig.de/forschungsbibliothek/handschriftenzentrum/) der sechs deutschen Handschriftenzentren, weswegen bei uns im Haus häufig Buchhandschriften digitalisiert werden. Für diesen Vorgang verwenden wir [Kitodo](https://www.kitodo.org/), ein Werkzeug für den Digitalisierungsworkflow. Bei der Benutzung von Kitodo gab es jedoch einige Hürden zu überwinden. Zum einen bietet die Kitodo-Eingabemaske nicht die benötigten Felder für Metadaten. Zum anderen wurden die umfangreichen Metadaten bereits im Katalog der Manuscripta Mediaevalia (http://www.manuscripta-mediaevalia.de/) erfasst. Das dahinter liegende Format nennt sich HiDA (https://www.startext.de/produkte/hida). Für die Verwendung mit Kitodo müssten die HIDA-Daten nun in das Kitodo-interne Format umgewandelt werden. Die Übereinstimmung zwischen Ausgangsformat (HIDA) und Zielformat (Kitodo-intern) liegt in einer XML (Extensible Markup Language) Datei. Die jeweils verwendeten Felder sind jedoch vollkommen verschieden voneinander und waren damit nicht ohne weiteres nutzbar für uns.
## Die Umsetzung
In Zusammenarbeit mit zwei Kolleg*innen ([Annika Schroer](https://github.com/a-nnika) kümmerte sich um das Mapping, [Stefan Freitag](https://github.com/sfreitag) implementierte den [METS](http://www.loc.gov/standards/mets/)-Part) entstand eine erste Version, welche erfolgreich Metadaten überführt und eine Weiterverarbeitung in Kitodo ermöglicht. Als dann irgendwann eine Anfrage zur Benutzung des Werkzeugs von außerhalb der UB Leipzig kam, habe ich eine zweite Version entwickelt und [diese](https://github.com/ubleipzig/ManuMedImporter) auf den [Github-Account der UB Leipzig](https://github.com/ubleipzig/) hochgeladen und zur freien Nutzung verfügbar gemacht.
## Wie geht's weiter?
Momentan wird an der UB Leipzig in Kooperation mit weiteren Einrichtungen ([Staatsbibliothek zu Berlin (SBB-PK)](https://staatsbibliothek-berlin.de/), [Bayerische Staatsbibliothek München (BSB)](https://www.bsb-muenchen.de/), [Herzog August Bibliothek Wolfenbüttel (HAB)](http://www.hab.de/)) ein [Handschriftenportal für Deutschland](handschriftenportal.de/) entwickelt. Damit ergibt sich natürlich ein potentielles Anwendungsgebiet für die Nachnutzung und Weiterentwicklung von ManuMedImporter. Aber das steht alles noch in den Sternen.
**Github-Link**
https://github.com/ubleipzig/ManuMedImporter
# OAI-PMH
## Motivation und Entstehung
Im Jahr 2012 entstand an der UB Leipzig der Wunsch nach einem <abbr title="Unified Resource Name"><a href="https://de.wikipedia.org/wiki/Uniform_Resource_Name">URN</a></abbr>-Server, der nächtlich alle über den Tag neu erstellten URNs zusammenfasst und für die [Deutsche Nationalbibliothek (DNB)](https://www.dnb.de) abrufbereit präsentiert, damit diese in den Index der DNB aufgenommen werden können. Die DNB arbeitete damals wie heute mit <abbr title="Open Archives Initiative"><a href="http://www.openarchives.org/">OAI</a></abbr>-Clients zum Abrufen der URNs. [Stefan Freitag](https://github.com/sfreitag), mittlerweile Leiter der Softwareentwicklung an der UB Leipzig, hat daraufhin zunächst einen <abbr title="Open Archives Initiative Protocol for Metadata Harvesting">OAI-PMH</abbr>-Server für URNs unter Nutzung des [xepicur](https://wiki.dnb.de/display/URNSERVDOK/xepicur+-+XML-Datentransferformat+zur+Verwaltung+von+URN)-Formats implementiert. In 2018 wurde dieser unter Verwendung aktuellerer Technologien (u.a. Java 11, [vert.x-Framwork](https://vertx.io)) neu implementiert.
Zur gleichen Zeit entstand der Wunsch, METS/MODS-Dateien ebenfalls öffentlich verfügbar zu machen. METS/MODS-Dateien enstehen während des Kitodo-Digitalisierungsworkflows und werden zur IIIF-Verarbeitung herangezogen. Während IIIF zwar eine wunderbare Technologie zum Image-Austausch darstellt, fehlen hierbei jedoch manchmal die detaillierten bibliografischen Informationen, die in den METS/MODS-Daten aggregiert sind. Ich habe also den OAI-Server modifiziert, eine neue Instanz aufgesetzt und darüber nun die METS/MODS-Daten verfügbar gemacht. Eine Besonderheit ist hierbei die Datenbasis. Um die Schnittstelle performant zu gestalten, werden alle METS/MODS-Daten in einer Datenbank zwischengespeichert, die wiederum intervallmäßig aus einer selbst entwickelten Schnittstelle (igiL-Backend) mit den Daten versorgt wird. Wir erreichen somit ein recht performantes Caching für die sehr vielen und zudem teilweise sehr großen METS/MODS-Beschreibungen.
## Nutzung und Nutzungsbeispiel
Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) ist ein webbasiertes standardisiertes Protokoll für das Sammeln von Metadaten und bietet ein anwendungsunabhängiges Interoperabilitäts-Framework. Mit Hilfe eines Harvester (Clientanwendung), können Metadaten gesammelt werden.
Mithilfe von OAI-PMH werden bevorzugt Datenabgleiche zwischen Datenbanken vollzogen. Das schließt jedoch nicht aus, Metadaten ohne eigene Datenbank über die Schnittstelle zu beziehen. Wie eingangs erwähnt, findet die Schnittstelle bei uns hauptsächlich Anwendung beim Datenabgleich mit der DNB. So können Datensätze automatisiert und in einem festgelegten Standard zwischen den Einrichtungen ausgetauscht werden.
Die einfachste Art eines solchen Clients, ist beispielsweise ein Webbrowser. Es können aber auch Anfragen (Requests) in Computerprogrammen von Programmierern integriert werden, um diese an den Server zu senden, eine Antwort (Response) zu bekommen und diese Antwort entsprechend im Computerprogramm zu verarbeiten.
Im Folgenden zeigen wir Ihnen, anhand von 2 Beispielen, wie Sie die Schnittstelle nutzen können. Eine ausführliche Beschreibung des Protokolls finden Sie unter <https://www.openarchives.org/OAI/openarchivesprotocol.html>
## Request
OAI-PMH-Anfragen müssen entweder mit den Methoden HTTP GET oder POST gesendet werden. POST hat den Vorteil, dass die Länge der Argumente nicht eingeschränkt wird. Bitte achten Sie auf das URL-Encoding.
Für eine Anfrage (Request) benötigen Sie eine Basis-URL, welche durch Schlüsselwortargumente (keyword arguments) ergänzt wird. Zwischen der Basis-URL und den Schlüsselwortargumenten muss, wie üblich, eine Trennung durch ein Fragezeichen [?] erfolgen.
### Basis-URL der UBL
``` html
https://services.ub.uni-leipzig.de/digitalcollections/oai2
```
### Keyword Arguments
Zusätzlich zur Basis-URL bestehen alle Anfragen aus einer Liste von Schlüsselwortargumenten (keyword arguments), die die Form von Schlüssel-Wert-Paaren haben (key=value).
Die Argumente können dabei in beliebiger Reihenfolge aneinandergereiht werden. Mehrere Argumente müssen durch das kaufmännische Und [&] getrennt werden. Dabei ist zu beachten, dass jede OAI-PMH-Anfrage mindestens ein Schlüssel-Wert-Paar enthalten muss.
Beispiel für den Abruf des Impressums vom OAI-Server mithilfe des Wertes "Identify":
``` html
https://services.ub.uni-leipzig.de/digitalcollections/oai2?verb=Identify
```
Basis-URL:
``` html
https://services.ub.uni-leipzig.de/digitalcollections/oai2
```
keyword arguments:
``` html
verb=identify
```
Repositories machen standardmäßig ihre Basis-URL als Wert des baseURL-Elements in der sogenannten Identify-Antwort verfügbar.
Beispiel für die Eingrenzung der Records auf einen bestimmten Zeitraum:
``` html
https://services.ub.uni-leipzig.de/digitalcollections/oai2?verb=ListRecords&metadataPrefix=mets&from=2020-01-10&until=2020-05-15
```
Basis-URL:
``` html
https://services.ub.uni-leipzig.de/digitalcollections/oai2
```
keyword arguments:
``` html
verb=ListRecords
metadataPrefix=mets
from=2020-01-10
until=2020-05-15
```
## Response
Alle Antworten auf OAI-PMH-Anfragen sind wohlgeformte XML-Dokumente. Die Codierung des XML ist die UTF-8-Darstellung von Unicode.
Formate
<table>
<tr>
<td>METS</td>
<td>Metadata Encoding & Transmission Standard</td>
<td>Format zur Beschreibung von digitalen Sammlungen von Objekten mit Metadaten</td>
</tr>
<tr>
<td>MODS</td>
<td>Metadata Object Description Schema</td>
<td>Format für bibliografische Metadaten</td>
</tr>
Nachfolgend sehen Sie den Ausschnitt für den Response zum Beispiel 2. Das Beispiel enthält Elemente und Attribute, welche in den Schemadefinitionen hinterlegt sind. Diese werden mit entsprechenden Daten gefüllt, wie es die Schemadefinition verlangt. Die Schemadefinition können Sie entsprechend nachschlagen. Betrachten wir hierzu den folgenden Abschnitt, so werden Sie erkennen, dass die Bezeichnung recht eindeutig ist. Hier der Titel des Werks.
``` html
<mods:title>Dominica Aduentus Domini, Matth. 21.</mods:title>
```
``` html
<mets:mets xsi:schemaLocation="http://www.loc.gov/standards/premis/ http://www.loc.gov/standards/premis/v2/premis-v2-0.xsd http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-7.xsd http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/version17/mets.v1-7.xsd http://www.loc.gov/standards/mix/ http://www.loc.gov/standards/mix/mix.xsd" >
<mets:metsHdr CREATEDATE="2017-04-25T06:56:22" >
<mets:agent OTHERTYPE="SOFTWARE" ROLE="CREATOR" TYPE="OTHER" >
<mets:name>Goobi - UGH-1.11.0-7b3c2be - 26−March−2015</mets:name>
<mets:note>Goobi</mets:note>
</mets:agent>
</mets:metsHdr>
<mets:dmdSec ID="DMDLOG_0000" >
<mets:mdWrap MDTYPE="MODS" >
<mets:xmlData>
<mods:mods>
<mods:identifier type="goobi" >2552</mods:identifier>
<mods:relatedItem type="series" >
<mods:titleInfo>
<mods:title>VD16</mods:title>
</mods:titleInfo>
</mods:relatedItem>
<mods:identifier type="urn" >urn:nbn:de:bsz:15-0010-122769</mods:identifier>
<mods:identifier type="swb-ppn" >084461748</mods:identifier>
<mods:extension>
<slub:slub>
<slub:id type="source" >084461748</slub:id>
<slub:id type="tsl-ats" >DresPrec</slub:id>
</slub:slub>
</mods:extension>
<mods:identifier type="vd16" >VD16 D 2761</mods:identifier>
<mods:titleInfo>
<mods:title>Precationum formulae Ex Singvlis Evangeliis Dominicorvm, Et Festorvm Diervm Deliberate</mods:title>
<mods:subTitle>Latinè, &amp; Graecè</mods:subTitle>
</mods:titleInfo>
<mods:titleInfo type="alternative" >
<mods:title>Precationum formulae ex singulis Evangeliis Dominicorum, et festorum dierum deliberate</mods:title>
</mods:titleInfo>
<mods:language>
<mods:languageTerm authority="rfc3066" type="code" >grc</mods:languageTerm>
</mods:language>
<mods:language>
<mods:languageTerm authority="rfc3066" type="code" >lat</mods:languageTerm>
</mods:language>
<mods:originInfo>
<mods:place>
<mods:placeTerm type="text" >Lipsiae</mods:placeTerm>
</mods:place>
<mods:dateIssued keyDate="yes" >1596</mods:dateIssued>
<mods:dateOther encoding="w3cdtf" type="order" >1596</mods:dateOther>
<mods:publisher>Lantzenberger</mods:publisher>
</mods:originInfo>
<mods:name type="personal" >
<mods:role>
<mods:roleTerm authority="marcrelator" type="code" >aut</mods:roleTerm>
</mods:role>
<mods:namePart type="family" >Dresser</mods:namePart>
<mods:namePart type="given" >Matthaeus</mods:namePart>
<mods:displayForm>Dresser, Matthaeus</mods:displayForm>
</mods:name>
<mods:physicalDescription>
<mods:extent unit="leaves" >[176] Bl.</mods:extent>
</mods:physicalDescription>
</mods:mods>
</mets:xmlData>
</mets:mdWrap>
</mets:dmdSec>
<mets:dmdSec ID="DMDLOG_0001" >
<mets:mdWrap MDTYPE="MODS" >
<mets:xmlData>
<mods:mods>
<mods:titleInfo>
<mods:title>Dominica Aduentus Domini, Matth. 21.</mods:title>
</mods:titleInfo>
</mods:mods>
</mets:xmlData>
</mets:mdWrap>
</mets:dmdSec>
```
# provit - A data object provenance tool
## Idee und Anforderungen
Während unserer datenbasierten Forschung zu Videospielkultur haben wir ein Vielzahl
von heterogenen Datenquellen erschlossen. Zur Beanwortung unserer Forschungsfragen
war es notwendig die Informationen und Inhalte dieser Quellen auf verschiedenen
Ebenen zu vereinen, anzureichen und neu zusammenzustellen. Diese Prozesse waren z.T.
zeitintensiv, erforderten Bearbeitung durch verschiedene Menschen und Programme.
Anfang 2018 begannen wir nach einer Möglichkeit zu suchen, diese Bearbeitungsschritte
strukturiert und nachvollziehbar zu dokumentieren. Es sollte also zu jedem Forschungs-
datensatz den wir erstellt hatten jederzeit nachvollziehbar sein:
1. Wie aktuell sind die zugrunde liegenden Rohdaten?
2. Wann und wie wurden diese aquiriert?
3. Welche weiteren Bearbeitungsschritte wurde wann und in welcher Reihenfolge durchgeführt?
Provenance Management Systeme sind keine Erfindung von uns, sondern gibt es bereits
in verschiendenen Geschmacksrichtungen aus Varianten. Unseren Anfordungen entsprach
aber Keines, denn wir wollten ein System mit folgenden Eigenschaften:
1. Keine zentrale Infrastruktur/Datenbank
2. Informationsspeicherung möglichst dateibasiert
3. Basierend auf einem etablierten und interoperablen Datenformat
4. Möglichkeit der einfachen Integration in bestehende ETL-Pipeline
5. Nutzbarkeit durch Forscher*innen ohne Programmierkenntnisse
Das von uns entwickelte Tool "provit" ist ein erster Versuch diesen Anforderungen so
gut es geht gerecht zu werden, und diese auf ihre Praxistauglichkeit zu testen.
## Zielgruppe
Die Zielgruppe von "provit" sind Forscher*innen und wissenschaftliche Softwareentwickler,
die allein oder in kleinen Gruppen über längere Zeiträume mit Daten, die insbesondere
viele Zwischenbearbeitungen (Bereinigung, Zusammenführung, ...) erfordern, bevor sie
zur Beantwortung von Forschungsfragen genutzt werden können.
## Funktionsweise
### Für Forscher*innen
Forscher*innen können mithilfe einer browserbasierten grafischen Benutzeroberfläche
oder per Kommandozeile mit "provit" interagieren.
Die grafische Benutzeroberfläche ermöglicht es auch auf einfache Weise vorhandene
Provenance-Informationen von Dateien anzuschauen und zu erkunden, sowie weitere
Punkte hinzuzufügen.
### Für Entwickler*innen
Entwickler*innen können "provit" sehr leicht in ihre bestehenden pythonbasierten
ETL-Pipelines integrieren. Dafür kann man aus dem Python Package Index (also direkt
per `pip install provit`) das Programm installieren und dann entsprechend der
Anleitung unter https://provit.readthedocs.io benutzen.
## Weitere Entwicklungen
Unser Forschungsprojekt endet im Juli 2020, daher wird die Weiterentwicklung,
sofern sich keine Maintainer*in findet vermutlich zu diesem Zeitpunkt eingestellt
werden (müssen).
# pyg - passable youtube grabber
## Wie ist die Idee zu XXX entstanden?
Im Jahr 2018 haben wir begonnen in unserer Forschungsgruppe (diggr) die Kommentarspalten von Youtube-Videos sowie Netzwerke von Youtubern zu analysieren um mehr über die Rezeption von Videospielen zu erfahren. Genauergesagt wurde "pyg" entwickelt um uns die Forschungsarbeit zu erleichtern, und insbesondere die zu dem Zeitpunkt technisch weniger versierten Forscher*innen zu ermächtigen eigenständig und automatisiert Daten von Youtube abzurufen.
## Wer sollte XXX benutzen?
Jede*r Forscher*in die sich mit Youtubern, deren Videos, Rezeption und Netzwerken im weitesten sinn befasst kann mit "pyg" eventuell Teile der Datenerhebung erheblich vereinfachen oder beschleunigen.
Leider muss man an dieser Stelle aber direkt auch einige einschränkende Dinge erwähnen. Einerseits kann sich der abrufbare Umfang der Daten täglich ohne Angabe von Gründen oder Vorwarnung ändern. Insbesondere für Forschungsanliegen die auf einer längerfristige Datenerhebung angewiesen sind (z.B. um Schwankungen/Trends/... zu analysieren) sollten damit klarkommen, wenn nach einem Bruchteil des Erhebungszeitraums keine Erhebung mehr möglich ist.
## Wie funktioniert pyg?
Zunächst einmal benötigt jede Nutzer*in einen API-Key für die Youtube-API. Diese Zeichenkette (eine Art Passwort) ist die Voraussetzung die Youtube-API überhaupt nutzen zu können. Dieser Key muss bei jeder Anfrage an die Youtube-API mitgeschickt werden. Damit lassen sich nicht durch die Herausgeber (Google) nicht nur Anfragen einem bestimmten Account/Key zuordnen, sondern Limitierungen was Anzahl und Umfang der Anfragen angeht einschränken.
### a) für den Nutzenden,
Entsprechend der von Google bereitgestellten Anleitung[1] beschafft man sich einen API Key. Anschließend kann es auch schon mit der Installation des Programms losgehen, diese gestaltet sich allerdings üblicherweise recht einfach und ist in wenigen Sekunden erledigt[2].
Nun kann es eigentlich auch schon losgehen mit der erstellung des ersten Projekts. *pyg* hat keine grafische Benutzeroberfläche, sondern wird ausschließlich über die Kommandozeile aufgerufen aber über Textdateien konfiguriert, d.h. man kann den Texteditor der eigenen Wahl benutzen (Hinweis: Microsoft Word/LibreOffice/... sind Textverarbeitungsprogramme und keine einfachen Texteditoren und daher nicht geeignet).
Um Youtube-Channel zum herunterladen vorzumerken, werden die Channel IDs in die von *pyg* erstellte Datei *channels.yml* eingetragen. Mit dem nächsten Aufruf des Programms werden alle dort enthaltenen Channel dann automatisch heruntergeladen.
```yaml
main_group:
- channel/UCdQHEqTxcFzjFCrq0o4V7dg
- channel/UCI06ztiuPl-F9cSXsejMV8A
other_group:
- channel/UCZzPA6tCoQAZNiddpE-xA_Q
```
*pyg* lädt lediglich Metadaten herunter, und bereitet diese zur Weiterverarbeitung z.B. in elasticsearch auf. Damit bleiben die heruntergeladenen Datensätze relativ kompakt. Dadurch das *pyg* keine Werkzeuge zur Analyse mitbringt muss diese mit Hilfe eines anderen Programms erfolgen. Wir haben dazu einen Export nach Elasticsearch eingebaut, aber auch andere Exportformate sind denkbar, allerdings derzeit nicht implementiert.
### b) für die Entwickler*in
Das Programm befindet sich mit Dokumentation und Quelltext auf github und kann dort von jeder und jedem heruntergeladen und entsprechend der Freiheiten welche die GNU General Public License einräumt modifiziert, vertrieben, etc. werden.
Das Programm ist vollständig in Python (>3.5) implementiert und benutzt ansonsten noch YAML (für die Konfiguration) und Elasticsearch (für den Datenexport) als weitere Technologien.
## Welche weiteren Entwicklungen sind geplant?
Da wir mit größten Schritten auf das Projektende zugehen wird es von unserer Seite aus leider keine weiteren Updates der Software geben. Sollte es interessierte Menschen geben, die die Software maintainen möchten, sollte sie mit dem Bereich Digitale Dienste der Universitätsbibliothek Leipzig in Kontakt treten.
[1] Youtube API Keys https://developers.google.com/youtube/v3/getting-started
[2] Installationsanleitung https://github.com/diggr/pyg
......@@ -3,7 +3,7 @@
- Launch der Website zum Digitaltag 2020 (https://digitaltag.eu)
## Zeitplan
- Digitaltag 2020: 19.06. 14h
- Digitaltag 2020: 19.06. 14h Podium, 18h UBLab
- Feedbackschleife
- Webseite fertig: 09.06. - Präsentation DB
- Feedbackrunde (OSO, ÖA): OSO: 03.06.
......@@ -27,22 +27,20 @@
- Testen
## Do
- Neues Template customizen
- Hinweise Barrierearmut Claas umsetzen (https://projekte.ub.uni-leipzig.de/issues/17319)
- Backlog erstellen:
- Blogbeitrag 'UB Lab' für den UB Blog (in Bearbeitung: [UB Lab - Software für die Wissenschaft](UBLab_Blogbeitrag.md))
- Martin: Siskin
- Provit (Florian done, Ronny Feinschliff)
- PYG (Florian done, Ronny Feinschliff)
- Schnittstellendokumentation
- IIIF : Leander (old: http://lab.ub.uni-leipzig.de/?p=992&preview=1&_ppp=1aa5be9b9f)
- OAI-PMH: Prosa - Stefan F./Ronny (Ronny: Finalisieren), Anwendungsbeispiel - (Stefan D.)
## Done
- Backlog erstellen:
- [Was ist Forschungssoftware](was-ist-forschungssoftware.md) (Ronny)
- [ManuMedImporter](ManuMedImporter.md) (Felix/Ronny)
- DFG FID- Kurzinterview mit Seb. Stoppe (als WP-Draft: https://lab.ub.uni-leipzig.de/?p=1262&preview=true)
- Provit (Florian)
- PYG (Florian)
- Online:
- Blogbeitrag 'Mit Open-Source-Software durch die Krise': https://pad.gwdg.de/Hcv_CbNaTO6sIClXqRHpkA#
- [VuFind Module für die Nutzung in Fachinformationsdiensten](https://lab.ub.uni-leipzig.de/softwareentwicklung/vufind-fid-module/) (André)
......@@ -50,3 +48,4 @@
- [IIIF-Producer](https://lab.ub.uni-leipzig.de/iiif-producer/) (Stefan/Ronny)
- Schnittstellendokumentation
- [SRU](https://lab.ub.uni-leipzig.de/daten-und-schnittstellen/sru/), [Z39.50](https://lab.ub.uni-leipzig.de/daten-und-schnittstellen/z39-50/) (Stefan Dombek)
- OAI-PMH (Stefan F./Stefan D./Ronny)
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment