ConfIDent Migrationplan

Motivation

OPENRESEARCH LTS ist erforderlich, da die Menge an Detailproblemen für den Betrieb des aktuellen OPENRESEARCH:

• https://github.com/SmartDataAnalytics/OpenResearch/labels/WP%202.7%20Hosting

und insbesondere die zugehörigen "Showstopper" https://github.com/SmartDataAnalytics/OpenResearch/labels/showstopper einem wirtschaftlichen Weiterbetrieb entgegenstehen. Ohne einen "Befreiungsschlag" wird die Not nicht gelindert.

OPENRESEARCH LTS

(Purgatorium? ) OPENRESEARCH LTS wird eine Version von Openresearch ohne manuelle Kuratierungsmöglichkeit durch unqualifizierte Externe sein. Ausgesperrt werden:

1. SPAMMER
2. Verwender von defekten Tools wie z.B. CSV Import
3. Gelegenheits-User die den aktuellen Stand der agilen Entwicklung nicht mitverfolgen können (Ständiges Update des "Manual" ist nicht möglich, wenn hohes Tempo in der Entwicklung erfolgt ...)

Die Qualifikationsvoraussetzungen sind zu definieren - z.B. Mindestens Teilnahme am 1/2 Tag SMW Basics und 1/2 Tag Kuratierung in OPENRESEARCH.

D.h. zur Zeit erfüllen diese Voraussetzungen einige Kuratoren und Mitglieder des ConfIDent Teams. Sogar einige ehemalie OPENRESEARCH Projektteilnehmer wie Sahar Vahdati und Said Fathalla erfüllen die Voraussetzung zur Zeit nicht.

Bisher ist ein Termin für die Einarbeitung/Schulung nicht zu Stande gekommen. Es sind weitere Angebote geplant - die Wirkung hängt davon ab wie diese Angebote angenommen werden.

OPENRESEARCH LTS ist ein Migrationsvehikel zwischen dem aktuellen OPENRESEARCH und dem zukünftigen ConfIDent.

Es ermöglicht einen produktiven Datenserver als Backend der mit unterschiedlichsten Frontends bedient werden kann.

Beispielsweise könnte das OPENRESEARCH Calender Tool als Frontend eingebunden werden.

Die Frontends und zugehörigen APIs sind noch zu schaffen.

Eine weitere Möglichkeit dazu ist z.B. der WikiCMS ansatz der es ermöglicht bootstrap4/python wie in http://fb4demo.bitplan.com/ zu verwenden zu nutzen.

Eine andere Möglichkeit besteht darin unterschiedliche OPENRESEARCH Kopien mit einander zu synchronisieren (wie früher Lotus Notes). Als erster Schritt kann z.B. in einer der OPENRESEARCH Kopien mit Kuratoren getestet werden wie der Arbeitsablauf für Kuratoren optimiert werden kann. Damit die manuellen Ergebnisse dieser Test-Phase produktiv genutzt werden können wird einfach das wikipush - Toolkit verwendert.

So ist z.B.

wikibackup -q [[Modification date::>yesterday]]

geeignet um das WikiSON Markup der Ergebnisse zu erzeugen. Mit einfachen unix-Tools wie awk kann dieses Markup OPENRESEARCH LTS kompatibel gemacht werden und dann mit WikiRestore in das LTS System synchronisiert werden.

Pain Assessment

Feature Matrix

Features

Feature	Legacy	LTS	ConfIDent
from	2008	TBD>2021-03	TBD>2021-06
until	TBD < 2021-06	TBD>2024	TBD>2027
Entities
Event	✓	✓	✓
Event series	✓	✓	✓
Country
Region
City
Tool	✓	❌
Journal	✓	❌
Papers	✓	❌
Person	✓	❌
Organization	✓	Venue? ❌
Project	✓	❌
Queries
SMW #ask	✓	✓	✓
SQL	❌	✓	✓
SPARQL	❌	❌	✓
LAMP + SMW
Linux Version	Debian 9.13	Debian 10	>= Ubuntu 20.04/Debian 10
MediaWiki Version	1.31 LTS EOL 2021-06	1.35 LTS EOL 2023-09	>= 1.35 LTS
MariaDB Version	10.1.47	10.3.27	>= 10.3
PHP Version	7.0.33	7.3	>= 7.3
SMW Version	2.5.8 EOL 2018-10	3.2.0 EOL >= 2021-03	>= 3.2

Versions

• https://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki_Version_History

Triples / Queries

Triple access e.g. via the https://www.semantic-mediawiki.org/wiki/Architecture_Tradeoffs work-around should be possible. Better Queries should be possible using SQL/SPARQL

Nightly Backup Sync

1. Curator
2. Kompatible
3. Bridge - Problem
4. Master System ... OPENRESEARCH LTS - Entitäten

OPENRESEARCH - ConfIDent

1. Provenance Data Pflicht

OPENSOURCE

Ist den Openresearch Open Source? Wikipush ... Get your own copy of Research ...

1. Forschungswikis

Trigger

1. WikiCFP
2. Openresearch Calendar Trigger
3. Generator - WP3 / WP1

Quality Gate

1. Purgatorium
   1. Automatic Metrics
   2. Manual Metrics
   3. https://wiki.tib.eu/confluence/pages/viewpage.action?pageId=112070529

Issues

Migrationsplan ...

After Repair

• Regular Expression
• length
• nightly script for check

SMW limits

1. query
2. macro limit
3. PHP limits and debugging issues see http://wiki.bitplan.com/index.php/PHP_Mediawiki_Eclipse_debugging

There are no proper "Functions" at this point only PHP extensions and MediaWiki Macros. For future needs like ... import / export ... and other fucntionalities and external function system via API is needed

Bots

Standard MediaWiki bot frameworks like

1. MWClient
2. pywikibot

have been extended with py-3rdparty-mediawiki see wikipush- Toolkit

Way out

... do not push limits ... nach uns die Sinnflut ...

Meetings

Brainstorming 2021-03-01

• https://wiki.tib.eu/confluence/display/openresearch/2021-01-18+Brainstorming+Session
• https://wiki.tib.eu/confluence/display/openresearch/2021-03-01+Brainstorming+Session
• https://wiki.tib.eu/confluence/display/openresearch/2021-03-08+Besprechungsnotizen

Fr. Sens JF Notes

in 2020 bis heute insgesamt knapp 4.000 Bearbeitungen von allen Usern, davon knapp 3.000 neue Seiten, davon knapp 2.000 Events.

   TIBKAT hatte in 2018 über 11.000 neue Konferenzbände (in allen Technik-Wissenschaften)
   Fokus auf Informatik zeigt aber: OpenResearch hat insgesamt ca. 1.000 Event Series, DBLP hat 5.000
   RWTH ist mit dem Import von DBLP-Serien in das Semantic-Media-Wiki-Format fast fertig, könnte ohne weitere Hindernisse in OpenResearch übernommen werden.
   Die aus DBLP importierten Serien werden gerade abgeglichen mit den Serien, die schon in OpenResearch drin stehen, und werden mit den notwendigen Provenance-Metadaten aus mehreren LOD-Quellen angereichert (Zusammenarbeit in der Community mit Simon Cobb, Master Librarian Uni Exeter, UK – er verwendet ein Toolkit, das große Datenmengen in kurzer Zeit bereinigen kann)
   Bisheriges Hindernis für Event-Import: unvollständige Signatur (z.B. Ordnungsnummer, Jahr, Land, Ort sind nicht zuverlässig in OpenResearch verfügbar)
       Deshalb wichtig: richtige Migrationsstrategie wählen, um die Interessen bzgl. Tempo und Qualität in angemessene Balance zu bringen
           z.B. 60% des OpenResearch-Bestands (d.h. die Events mit guten Metadaten) gehen in wenigen Tagen
           80% in wenigen Wochen
           95% dauert Monate und erfordert manuelle Kuratierung