gemeinsame Datenbank/Datenquelle für verschiedene Software

  • Hallo,

    es gibt schon verschiedene Software, die den Spielern hilft in der Spiel-Vorbereitung oder im Spiel selbst.

    Ich selbst hab auch grad eine veröffentlicht. (https://play.google.com/store/…panyname.probensimulator2)

    Diese greifen alle mehr oder weniger auf Spieldaten zu, welche auch auf dem offiziellen Regelwiki stehen.

    (Ein bekannteres Beispiel für solche SW wäre Optolith)

    Ich sehe da ein paar längerfristige Herausforderungen:

    - wie (organisatorisch/technisch) kommen die Daten von Ulisses in die jeweilige Software.

    - wie stellen wir sicher, dass es keine Inkonsistenzen gibt in den Daten.

    (Ich könnte z.B. etwas anderes schreiben als Optolith, als du, als das offizielle Regelwiki...X/)

    - wie reduzieren wir für alle den Aufwand der Datenimportierung und Umformatierung.

    - wie reduzieren wir die Zeit von der Veröffentlichung neuer Daten/Ergänzungen/Korrekturen bis zur Bereitstellung an die User.

    - Wie stellen wir sicher, dass sich immer einer drum kümmert. Gerade in der community kommt und geht das interesse und das Zeitbudget einzelner Personen.

    - und natürlich steht alles unter dem Vorbehalt der lizenzrechlichen Situation, dass der Verwender der Daten ein rechtlich solide

    Einigung mit dem Rechte-Inhaber regelt haben muss. Darum geht es hier NICHT, sondern ich gehe davon aus, das hat der SW-Verantwortliche geregelt.


    Bitte gebt mir einen Tipp, wenn es dazu schon Lösungen gibt.


    Falls nein, hätte ich ein paar Empfehlungen/Meinungen/Wünsche und würde mich freuen über die Meinung anderer:

    - Wir sollten eine zentrale Datenplattform nutzen.

    - das Datenmodell sollte skalierbar sein, denn man kann heute nicht wissen, wie das Datenmodell in 5 Jahren sein wird.

    (Themen, Inhalte, Datenfelder, Sprachen, Sortierbegriffe/Metadaten/tags/Kategorien, technische Ausgabeformate)

    - Ulisses sollte mindestens die Schirmherrschaft dafür übernehmen. ich denke, es wäre in deren Interesse, diese zu betreiben und

    Zugriff zu kontrollieren, denn schließlich haben sie ja auch ein begründetes wirtschaftliches Interesse.

    Es wäre überraschend, wenn die intern nicht schon eine Datenbank und ein Datenmodell haben.

    Die Frage ist also eher, wie dieses mit extern verknüpft werden soll/darf.

    - Wenn es zur Bereitstellung Aufwand erfordert (vermeidbar mit der vorhandenden Technologie und dem Willen diese zu nutzen),

    dann sollte wer Daten nutzt, auch einen Beitrag leisten zur Pflege derselben. Wir sollten diese Aufwand aus Effizienzgründen
    allerdings in einer gemeinschaftlichen Initiative betreiben bzw. Ulisses darin personell unterstützen.

    So holen wir mehr aus der verfügbaren Zeit der Profis und Freiwilligen raus und die commuity und die digitalen Inhalte darin blühen auf.

    Es bietet sich an, das bereits vorhandene Engagement aufzugreifen/einzubinden. ich könnte mir vorstellen, dass Ulissses die Daten

    jeweils "abhakt" und auch kontrolliert, aber Leute aus der community ihr Dienste/Zeit bereitstellen und natürlich im Gegenzug von der

    Verfügbarkeit der Daten profitieren.

    - Datenzugriff muss irgendwie mit einem financial business modell für Ulisses kompatibel sein (€).

    - Die Datenbasis sollte in einer halbwegs modernen Form bereitgestellt werden. Da lasse ich mich gerne beraten von Leuten,

    die mehr von IT verstehen als ich. Ich tippe auf eine echte Datenbank mit Export in XML, oder near-realtime per webservice.

    Wobei natürlich auch profanerer EXCEL--> XML-->"whatever"-Konverter programmierbar wären.


    Wäre es nicht klug, wenn mehrere einschlägige player aus der community, die mit digitalen Angeboten am Start sind,

    sich mal mit Ulisses zusammensetzen und eine Digitalstrategie besprechen? - speziell den Aspekt des Datenflusses.


    Wenn es solch ein Forum schon gibt, dann macht mich schlau.


    Liebe Grüße


    Matthias

  • Hi Matthias, danke für deine professionellen und fundierten Überlegungen!


    Ich gehöre zu denjenigen, die ebenfalls regelmäßig Daten aus dem Wiki verarbeiten, und hab hier und hier schon mal ein bisschen was dazu geschrieben.


    Mein Senf zusammengefasst:

    • Rein technisch halte ich immer noch einen dateibasierten Ansatz für am sinnvollsten, und ganz aktuell wäre in meinen Augen ein Ausgabeformat wie JSON oder XML am besten geeignet. Beide lassen sich in praktisch jeder aktuellen Programmiersprache mit Bordmitteln verarbeiten. Für beide gibt es Möglichkeiten zur automatischen Validierung (XSD bzw JSON Schema).
    • Ich würde in den meisten Fällen 1 Datei pro Eintrag machen und dafür komplexe Verzeichnisstrukturen. Das ist extrem leicht zu warten und viel konfliktfreier, als wenn es z.B. eine Datei mit 1500 SF drin gibt.
    • Hier ist ein Screenshot von der temporären Struktur, die mein Parser erzeugt. So in etwa könnte man eine wundervolle Basis aufbauen, auch mit vielfältigen Dateiformaten (siehe weiter unten) dsa sf.png
    • Mein persönlicher Favorit wäre an dieser Stelle übrigens ganz klar YAML (statt JSON), weil das am einfachsten zu lesen und schreiben geht. Das bekommen auch nicht-Techniker ganz schnell gebacken!
    • Für die Versionierung, Abnahme und alles weitere bietet sich dann ein git-Repository an. git kann alles, was hier gebraucht wird, inklusive der dringend benötigten Möglichkeit, erfolgte Änderungen mitbekommen zu können.
    • Sobald man bei einem der bekannten git-Provider sitzt (github oder gitlab), kann man ziemlich einfach per Bots bzw CI vollautomatisch Dinge erledigen, wie z.B. zusammengefasste JSON- und XML-Dateien zu erzeugen (es spricht nichts dagegen, beide Formate automatisch anzubieten). Diese sozusagen fertig getesteten und "kompilierten" Dateien könnten dann die Basis für die eigentlichen Endabnehmer sein und einfach statisch auf einer Webseite veröffentlicht werden.
    • Weiters können dort beliebig viele Leute mit unterschiedlichen Rollen eingebunden werden: die Community könnte per Merge Requests bzw Pull Requests Änderungen einreichen, die dann im Review landen und nur von bestimmten Personen freigegeben werden können. Sogar ein 4-Augen-Prinzip (Freigabe erfordert Zustimmung durch mehr als eine Person) wäre technisch denkbar.
    • Weiters könnte auch die Diskussion darüber, wie die Formate konkret auszusehen haben (z.B. wenn neue Felder hinzugefügt werden), direkt über Tickets auf der jeweiligen Plattform geführt werden.
    • Und last but not least ein ganz wichtiges Feature, das so möglich wäre: Übersetzungen. In einem Daten-basierten Ansatz müssen lediglich echte Beschreibungstexte übersetzt werden, alles was Zahlen ist, muss NIEMAND ein 2. Mal angreifen, wenn es einmal da ist. Sprich: wenn eine Waffe 2W6+4 Schaden macht, dann macht sie das auch auf Englisch (bzw dort halt 2D6+4), und das kann man direkt übernehmen, sofern die Schadensberechnung als echte Formel und nicht als stumpfer Text erfasst wurde. Genauso muss niemand die ganzen Probenwürfe übersetzen - wenn auf Deutsch "MU/IN/KL" hinterlegt ist, lässt sich das ganz automatisch auch für Englisch bereit stellen.
    • Für sehr Textlastige Inhalte (also Regeltexte) würde ich ganz klar auf Markdown als Format setzen. Das ist etabliert, damit kann man ausreichend viele Dinge tun, und wenn mal wirklich ein komplexeres Layout nötig ist, kann man sich immer noch was anderes überlegen.


    Es wäre überraschend, wenn die intern nicht schon eine Datenbank und ein Datenmodell haben.

    Ganz ehrlich: das kann ich mir beim besten Willen nicht vorstellen. Wenn es das gäbe, dann hätten sie das als Basis fürs Regelwiki herangezogen. Mehr als ein Konvolut aus uneinheitlichen Excel-Tabellen ist wahrscheinlich nicht vorhanden. Liebe Ulisses-Leute: belehrt mich gerne eines Besseren! :thumbup:


    Wäre es nicht klug, wenn mehrere einschlägige player aus der community, die mit digitalen Angeboten am Start sind,

    sich mal mit Ulisses zusammensetzen und eine Digitalstrategie besprechen? - speziell den Aspekt des Datenflusses.

    Da wäre ich auch sofort mit dabei! <3

  • Dieser Thread hat mich zu einer kleinen Änderung in Optolith bewogen, daher würde ich gerne auf deine ( mayana70) Fragen aus Optolith-Sicht antworten und anschließen auf davil s Antworten eingehen.


    Quote

    Wie (organisatorisch/technisch) kommen die Daten von Ulisses in die jeweilige Software?

    Wie reduzieren wir für alle den Aufwand der Datenimportierung und Umformatierung?

    Wie reduzieren wir die Zeit von der Veröffentlichung neuer Daten/Ergänzungen/Korrekturen bis zur Bereitstellung an die User?

    Wie stellen wir sicher, dass sich immer einer drum kümmert. Gerade in der community kommt und geht das interesse und das Zeitbudget einzelner Personen?

    Aus Optolith-Sicht sind diese alle ähnlich zu beantworten: Ich habe immer ein paar Helfer, die mir beim Übertragen oder korrigieren helfen, da ich es alleine gar nicht in dem Umfang schaffen würde. Wenn auch über die Zeit ein paar gewechselt haben, so habe ich da nach wie vor durchgehend Hilfe (wofür ich mich an der Stelle übrigens auch nochmal in aller Form bedanken kann!) habe. Da noch mehr gefragt haben, ob sie helfen können, glaube ich nicht, dass in absehbarer Zeit es an Leuten fehlt, die unsere Daten befüllen. Und Korrekturen sind ja recht einfach zu bewerkstelligen. Aktuell funktioniert das über das Kopieren aus dem Regelwiki und der anschließenden Abgleichung der genauen Textformatierung über die PDFs. Viel einfacher dürfte man es auch nicht machen können.


    Quote

    Wie stellen wir sicher, dass es keine Inkonsistenzen gibt in den Daten? (Ich könnte z.B. etwas anderes schreiben als Optolith, als du, als das offizielle Regelwiki...X/)

    Plump beantwortet: Nicht jeder macht sich seine eigene Datenbank! :P


    Und damit komme ich auch schon zu davil s Antwort.


    Rein technisch halte ich immer noch einen dateibasierten Ansatz für am sinnvollsten, und ganz aktuell wäre in meinen Augen ein Ausgabeformat wie JSON oder XML am besten geeignet. Beide lassen sich in praktisch jeder aktuellen Programmiersprache mit Bordmitteln verarbeiten. Für beide gibt es Möglichkeiten zur automatischen Validierung (XSD bzw JSON Schema).


    [...]


    Mein persönlicher Favorit wäre an dieser Stelle übrigens ganz klar YAML (statt JSON), weil das am einfachsten zu lesen und schreiben geht. Das bekommen auch nicht-Techniker ganz schnell gebacken!

    Das sehe ich genauso.


    Ich würde in den meisten Fällen 1 Datei pro Eintrag machen und dafür komplexe Verzeichnisstrukturen. Das ist extrem leicht zu warten und viel konfliktfreier, als wenn es z.B. eine Datei mit 1500 SF drin gibt.

    In dem Punkt kann ich dir aber leider nicht wirklich zustimmen. Denn so viele Dateien sind extrem unübersichtlich. Wenn man nur eine kleine Korrektur ausführt mag es ganz nett sein, aber sobald man mehrere Sachen - zum Beispiel beim Einpflegen eines neuen Buches - bearbeiten möchte, und zwar möglichst zeiteffizient, ist eine Aufteilung sehr hinderlich. Jedenfalls war das meine Erfahrung.


    Für die Versionierung, Abnahme und alles weitere bietet sich dann ein git-Repository an. git kann alles, was hier gebraucht wird, inklusive der dringend benötigten Möglichkeit, erfolgte Änderungen mitbekommen zu können.

    Das stimmt. Das vermisse ich aktuell auch bei meinen Excel-Tabellen! ^^


    Sobald man bei einem der bekannten git-Provider sitzt (github oder gitlab), kann man ziemlich einfach per Bots bzw CI vollautomatisch Dinge erledigen, wie z.B. zusammengefasste JSON- und XML-Dateien zu erzeugen (es spricht nichts dagegen, beide Formate automatisch anzubieten). Diese sozusagen fertig getesteten und "kompilierten" Dateien könnten dann die Basis für die eigentlichen Endabnehmer sein und einfach statisch auf einer Webseite veröffentlicht werden.

    Das ist auch eine sehr gute Idee! GitHub Releases würden dafür ja auch schon reichen. Dann hätte man alles an einem Ort.


    Und last but not least ein ganz wichtiges Feature, das so möglich wäre: Übersetzungen. In einem Daten-basierten Ansatz müssen lediglich echte Beschreibungstexte übersetzt werden, alles was Zahlen ist, muss NIEMAND ein 2. Mal angreifen, wenn es einmal da ist. Sprich: wenn eine Waffe 2W6+4 Schaden macht, dann macht sie das auch auf Englisch (bzw dort halt 2D6+4), und das kann man direkt übernehmen, sofern die Schadensberechnung als echte Formel und nicht als stumpfer Text erfasst wurde. Genauso muss niemand die ganzen Probenwürfe übersetzen - wenn auf Deutsch "MU/IN/KL" hinterlegt ist, lässt sich das ganz automatisch auch für Englisch bereit stellen.

    Das sollte sowieso Voraussetzung sein, denke ich. Ansonten wäre nicht nur der Aufwand zum Einpflegen, sondern auch die generelle Fehleranfälligkeit sehr hoch.


    Quote

    Für sehr Textlastige Inhalte (also Regeltexte) würde ich ganz klar auf Markdown als Format setzen. Das ist etabliert, damit kann man ausreichend viele Dinge tun, und wenn mal wirklich ein komplexeres Layout nötig ist, kann man sich immer noch was anderes überlegen.Das hab ich für Optolith auch eingeführt, im Zweifelsfall kann man ja immer HTML nutzen, damit lässt sich also alles abbilden. Außerdem bietet YAML durch die Block-Syntax sehr angenehmes Markdown-Schreiben.


    Und damit dann zu dem, zu was mich dieser Thread angeregt hat:

    Bisher habe ich die Quelldaten für Optolith - wie bereits angedeutet - in Excel-Tabellen angelegt, ein Relikt aus der Zeit, in der ich noch JavaScript gelernt hab und mich dann nicht noch mit Datenbanken groß auseinandersetzen wollte. Ich habe in den letzten Tagen die Optolith-Daten in YAML konvertiert- andere Sprachen noch unvollständig, aber Deutsch und die Universaltabellen vollständig. Außerdem existieren für jede Datei möglichst strikte Schemata.


    pasted-from-clipboard.pngpasted-from-clipboard.pngpasted-from-clipboard.png


    Die Dateien in univ sind vollkommen sprachunabhängig, sodass - wie du es auch vorgeschlagen hast - möglichst wenig in den Übersetzungsdateien steht.

    Für alle Nicht-Techniker habe ich ein Tutorial geschrieben, an dem man sich entlanghangeln kann, um das erste Mal Git zu verwenden. Ein weiterer Vorteil ist, dass mittlerweile ein paar auf Optoliths ID-Mappings zugreifen wollen, da sie die Speicherdateien von Optolith nutzen möchten. Durch YAML-Dateien kann man diese Mappings viel einfacher umsetzen, da man sie nicht aufwändig parsen muss.

    Aus meiner Sicht ist der einzige Nachteil an dieser Lösung, dass die Dateien an den Umfang von Optolith gebunden sind bzw. es dadurch nicht sinnvoll wäre, ohne Koordination mit Optolith Änderungen am Schema vorzunehmen.


    Das alles ist aufgrund der urheberrechtlichen Situation in einem privaten Repository auf GitHub. Aber ich sehe da kein Problem, dass andere Anwendungsprogrammierer auch Zugriff auf das Repo bekommen.


    Das alles ist jetzt eher kein(e) direkte(r) Empfehlung/Meinung/Wunsch, dafür aber ein Lösungsansatz für die Community.


    Würde mich über Meinungen freuen! :)


    Liebe Grüße,

    Ely/Lukas

    "Der Schwarzmagier? Ach, der wartet mit seinem Ritual schon auf uns, das ist eh gescriptet." ... :rolleyes:

    Mein Heldengenerator für DSA5: Thread und Eintrag im Scriptorium

  • In dem Punkt kann ich dir aber leider nicht wirklich zustimmen. Denn so viele Dateien sind extrem unübersichtlich. Wenn man nur eine kleine Korrektur ausführt mag es ganz nett sein, aber sobald man mehrere Sachen - zum Beispiel beim Einpflegen eines neuen Buches - bearbeiten möchte, und zwar möglichst zeiteffizient, ist eine Aufteilung sehr hinderlich. Jedenfalls war das meine Erfahrung.

    Ja, da hast du wohl Recht :) gerade mit YAML ist das diff-technisch auch gut handhabbar.

    Das alles ist aufgrund der urheberrechtlichen Situation in einem privaten Repository auf GitHub. Aber ich sehe da kein Problem, dass andere Anwendungsprogrammierer auch Zugriff auf das Repo bekommen.

    Du bekommst jetzt eine PN :D

  • Finde ich eine super Idee. mayana70 Tolle App, ich bin gerade am basteln einer ähnlichen App für iOS.


    Habe auch schon darüber nachgedacht, dass eine zentrale Datenbank mit den Infos sinnvoll wäre.

    Aus dieser könnte sich dann ebenfalls das Wiki bedienen. Es gäbe dann eine zentrale Stelle für die Infos. Evtl. direkt per API abfragbar?


    Die Idee mit YAML und github gefällt mir auch sehr gut. Ist zum einen gut wartbar, man hat klare Versionsstände und YAML ist trotzdem noch einfach zu handeln (nun gut der git overhead ist vielleicht noch eine Hürde).


    Bleibt aber noch die rechtliche Frage bzgl der IP von Ulisses. Bisher war die Freigabe ja auf das Wiki und Produkte im Skritporium eingegrenzt. Wie wäre das nun bei einer API, oder einem git Archiv?

  • Die Idee mit YAML und github gefällt mir auch sehr gut. Ist zum einen gut wartbar, man hat klare Versionsstände und YAML ist trotzdem noch einfach zu handeln (nun gut der git overhead ist vielleicht noch eine Hürde).

    Gerade bei YAML und wenn man automatische Syntax Checks drin hat reicht für die meisten einfachen Änderungen sogar die Online-Editing-Funktion von github/gitlab aus, d.h. Gelegenheitsuser benötigen lediglich einen Account und könnten direkt auf der Plattform im Browser Änderungen einpflegen und PRs erstellen. Für Power User kann man dann immer noch ein git-Tutorial bereit stellen falls nötig. Gerade hier sehe ich sehr viel Potential, Leute aus der Community einzubinden, die wenig technisches Vorwissen mitbringen.

  • Das ganze hört sich doch schon ganz gut an. Wie leicht könnte man denn aus den Daten die Wiki nachbauen? Wenn man ulisses schon eine fertige Website die aus den Daten generiert wird und vllt eine einfache Art der editierung anbietet, würden sie sich vllt eher bereitstellen so etwas offiziell anzunehmen

  • Die Daten sind aktuell zur Verarbeitung in entsprechenden Programmen gedacht. Eine direkte Darstellung eines Eintrags rein aus dem Objekt selbst ist nicht möglich; der Client muss auf die gesamte Datenbank zugreifen, um einen Eintrag vollständig generieren zu können (was exakt das ist, was Optolith im Wiki macht). Für das Regelwiki wäre wohl ein weiterer Schritt notwendig, nämlich dass vollständige Markdown-Dokumente für die einzelnen Einträge generiert werden. Und das muss automatisiert passieren. Am sinnvollsten wäre dafür wohl ein Reuse des Codes aus Optolith, da dort bereits alles vorhanden ist, was man braucht. Zu gegebener Zeit hatte ich auch vor, mich darum zu kümmern.

    "Der Schwarzmagier? Ach, der wartet mit seinem Ritual schon auf uns, das ist eh gescriptet." ... :rolleyes:

    Mein Heldengenerator für DSA5: Thread und Eintrag im Scriptorium