Stand 06.12.2019; Bitte beachten Sie, dass die Plattform MaterialDigital aufgrund ihres Entstehungsprozesses Veränderungen unterliegt. Aktuelle Informationen finden Sie stets unter www.materialdigital.de
Disclaimer: Die folgenden Ausführungen spiegeln Sicht und Planungsstand der Plattformverantwortlichen wider. Etwaige Widersprüche gegenüber Formulierungen im Ausschreibungstext sind in jedem Falle zu Gunsten desselben auszulegen.
Eine Ontologie für die Materialwissenschaft gemäß den Prinzipien des Semantic Web soll im Rahmen des Projekts bei der einheitlichen und standardisiert-anpassbaren Datenorganisation sowie -ablage, -abfrage und -aggregation helfen. Ein daraus resultierender Wissensgraph soll ermöglichen erzeugte Datensätze einheitlich zu strukturieren, inhaltlich zu analysieren, sowie neue Erkenntnisse aus den gewonnen Logiken abzuleiten. Die mittels des Wissensgraphen erreichbare Verknüpfung von Daten kann dann deren komplexe Zusammenhänge erschließbar machen, die in einfacherer Form heute in speziellen Modellen (in Form von Lehrbuchwissen) ausgedrückt werden. Aufgrund ihrer Komplexität kann die Ontologieentwicklung kaum isoliert stattfinden, sondern muss als gemeinsame Anstrengung der materialwissenschaftlichen Community in Angriff genommen werden.
Es ist nach Ansicht der Plattformverantwortlichen zentral die folgenden, grundlegenden Prinzipien zur Entwicklung der Ontologie anzuerkennen:
Die Ontologie für die Materialwissenschaft und Werkstofftechnik muss von den Domänenexperten und somit der jeweiligen Community, den Beitragenden und letztlichen Nutzern und Nutzerinnen definiert werden. Sprich, der eigentliche Prozess muss „Bottom-Up“ ablaufen. Die Informationswissenschaften können nur die grundlegende Struktur als Fundament des benötigten Datenraums beitragen.
Die Ontologie für die Materialwissenschaft und Werkstofftechnik muss gemäß geltender Forschungsgrundsätze auf eine Weise entwickelt werden, die niemals Vollständigkeit impliziert, sondern stets Adaptivität und weiteres Wachstum ermöglicht.
Die Ontologie für die Materialwissenschaft und Werkstofftechnik muss anwendungsorientiert innerhalb erster Domänen organisch wachsen und sich erst langfristig zu einer stärker gesamtheitlichen Abbildung der kompletten wissenschaftlichen Disziplin fügen.
Die Leistungsfähigkeit eines Ontologieansatzes muss sich in erster Linie an dessen praktischem Anwendungsnutzen für die Ziele Datenstrukturierung, -zugänglichkeit / Datenwiederverwendbarkeit und -auswertung bemessen. Eine Ontologie ohne Anwendungsnutzen ist irrelevant. Standardisierung ist dabei nur eine der erwarteten Nutzendimensionen der Ontologie.
Unter Beachtung dieser Aspekte befindet sich auch die materialwissenschaftliche Disziplin im Hinblick auf die entsprechende Entwicklung einer Ontologie nicht mehr am Anfang. Die Plattformverantwortlichen erkennen generalisierte Ontologiekonzepte und bestehende materialbezogene Bemühungen an, von denen mit der „Basic Formal Ontology“ und der „European Materials Modelling Ontology“ zwei im Folgenden weiter beleuchtet werden sollen. Dies sollte jedoch nicht als grundsätzliche Restriktion gegenüber anderweitigen Ansätzen zur Ontologieentwicklung verstanden werden, da die Ansätze aus Sicht der Plattformverantwortlichen ihre Leistungsfähigkeit noch nicht bewiesen haben.
Die Basic Formal Ontology (BFO) ist eine von der jeweiligen Domäne unabhängig anwendbare, prozessorientierte Ontologie die sich vor allem im Bereich der Technikwissenschaften zur einheitlichen Informationsabfrage, -analyse und -integration großer Beliebtheit erfreut. Die BFO ist eine „upper ontology“, die nicht die notwendige wissenschaftliche Tiefe der entsprechenden Domäne erreichen kann, aber die Ankopplung einer Domänenontologie an die semantische Beschreibung der Welt erlaubt.
Für die Materialwissenschaft versucht dies die European Materials Modelling Ontology (EMMO). Sie ist im Rahmen eines europaweiten Konsortiums initiiert worden und hat das Ziel die physikalische Realität von Materialverhalten wirklichkeitsgetreu abbilden zu können. Zum Beispiel basiert die grundlegende Struktur der EMMO auf dem hierarchischen Aufbau der Materialien (elektronische Bindung, atomare Bewegungen, Defektebene und Kontinuum). Damit erlaubt sie wesentlich tiefere Beschreibungen der Vorgänge in Materialien. Für den Anwendungsnutzen der angedachte Materialontologie wird mindestens eine solche Beschreibungstiefe unzweifelhaft notwendig sein. Bisher ist kein Anwendungsfall bekannt, der die EMMO in der kompletten Multiskalenbeschreibung ausnutzt.
BFO und EMMO stehen „vertikal“ zueinander: Während die BFO rein deskriptive Relationen aufzeigt, kann die EMMO oder eine andere Domänenontologie in einzelnen dieser Schritte eine ergänzende Sicht auf Zusammenhänge und Abläufe innerhalb der Mikrostruktur von Materialien ermöglichen.
Im Zusammenhang mit der Frage nach dem „richtigen“ Vorgehen im Zuge der oben beschriebenen Ausschreibung empfehlen die Plattformverantwortlichen eine sinnvolle Kopplung aus allgemeinen Ontologieansätzen wie der BFO und Elementen der EMMO. Im aktuellen Stand der Diskussion stellt dies die vielversprechendste Herangehensweise dar, um einen Wissensgraphen für die Materialwissenschaft zu erzeugen. Für interessierte Antragssteller läge es daher im Hinblick auf das zugrundeliegende gemeinsame Forschungsinteresse nahe, sich zunächst mit den genannten Ansätzen zur Ontologieentwicklung auseinanderzusetzen. Konkrete Realisierungen von Materialbezogenen Ontologien im Rahmen der Ausschreibung sind zentral um die Leistungsfähigkeit der Ontologieansätze im Anwendungsfeld der Materialwissenschaft auf die Probe zu stellen. Hierbei können sich auch andere Ontologieprinzipien als leistungsfähiger herausstellen als die genannten. Dennoch erscheint eine Abbildung hin zu BFO oder EMMO sinnvoll, damit die Integration in eine einheitliche Struktur ermöglicht wird
Die Plattformverantwortlichen sehen innerhalb der angestrebten, engen Zusammenarbeit die Aufgabe für sich, eine Infrastruktur zu schaffen an die die Domänenontologien „andocken“ können. Dies betrifft insbesondere die Gewährleistung einheitlicher Schnittstellen sowie die Definition von initialen Begrifflichkeiten und Ansprüchen, auf die die Teilontologien sich beziehen können. Auch eine erste, grundsätzliche Ontologie als Ausgangsschema will die Plattform bereitstellen.
Bereitstellung einer Beispielontologie zur nachvollziehbaren Darstellung der Erwartungen an die Lösungen.
Entwicklung und Bereitstellung einer Kollaborationsumgebung zur Ontologieentwicklung.
Ansprüche an eine Ontologie beispielhaft definieren.
Ansprüche an Metadaten und Linked Data initial definieren.
Entwicklung der Ontologie für die eigenen Anwendungsfälle sowie deren Integration innerhalb der erzeugten Umgebung und Anforderungen. Möglichkeit der Anwendung vorhandener Ontologieansätze überprüfen (vgl. o.)
Mapping gewährleisten, das die eigenen Datenbezeichnungen anhand der Ontologie zugänglich macht, Metadatensemantik nutzen und ergänzen
Ziel ist laut Ausschreibung die Etablierung von digitalen Workflows im Sinne des dezentralen Daten- oder Simulationskonzepts durch aktive Agenten innerhalb der Software-Umgebung der Innovationsplattform. Dabei ist die Nachhaltigkeit der Software-Lösungen und der einheitliche Zugriff auf Daten und Tools entscheidend. Die Plattform wird daher von Beginn an zwei Workflowumgebungen mit den Namen „pyiron“ und „Simstack“ zur Verfügung stellen. Von den Zuwendungsempfängern wird erwartet, dass sie ihre Lösungen so gestalten, dass sie innerhalb einer dieser Workflowumgebungen lauffähig gemacht werden können.
Eine genauere Aufschlüsselung der resultierenden Arbeitsteilung zwischen Plattform und Zuwendungsempfängern entsprechend der Vorstellung der Plattformverantwortlichen ist im Folgenden dargestellt
Es werden die Software-Umgebungen „pyiron“ und „SimStack“ zur Verfügung gestellt. Diese dienen der Programmierung und Ausführung von Simulationsprotokollen. Für „pyiron“ ist diese Umgebung durch ein Web-Interface und Jupyter Notebooks benutzerfreundlich sichergestellt.
Für jede Software-Lösung müssen die Voraussetzungen geschaffen werden, damit sie auf einer der Workflowumgebungen „pyiron“ oder „SimStack“ lauffähig ist. Es wird empfohlen, dass dies über ein Python-Interface (idealerweise Jupyter) erfolgt. Es wird nicht ausgeschlossen, dass die hier geschaffenen aktiven Agenten von weiteren Serverumgebungen außerhalb der Plattform zusätzlich unterstützt werden.
Ein Server zum Teilen und Verwalten von Tools wird eingerichtet. Die Workflowum- gebungen werden im Conda Community Channel zum Download bereitgestellt, um eine reibungslose Installation auf verschiedenen Computersystemen zu ermöglichen. Die Tools werden entsprechend ihrer Abhängigkeiten integriert.
Software-Lösungen müssen als Conda-Paket zur Verfügung gestellt werden. Damit diese in den App-Store integriert werden können, muss es sich um open-access Software handeln. Für jedes Tool muss es ein einziges Shell-Script geben, das aus dem Input den Output generiert.
Es wird auf dem MaterialDigital-Server (MDS) ausreichend Speicherplatz für Daten geben. Der MDS stellt die Workflowumgebungen zur Verfügung, die innerhalb von Udocker Containern genutzt werden können. Die Verwendung der Umgebung stellt automatisch (ohne, dass der Anwender Details kennen muss) sicher, dass die Daten konsistent gespeichert werden und dass die dazugehörigen Berechnungen auf einem Cluster ausgeführt werden. Für letzteres werden derzeit Konzepte wie AiiDA und SLURM unterstützt.
Der Zuwendungsempfänger muss einen eigenen Server zur Erzeugung und Speicherung eigener Simulationsdaten einrichten oder dafür den MDS nutzen (Ausnahme). Mittelfristig wird angestrebt, dass lokale Datenserver als Softwarestack vom MDS geklont werden können, dann also die Softwarestruktur des MDS aufweisen.
Die Workflowumgebung arbeiten mit klar strukturierten Datenformaten. Im Falle von „pyiron“ wird hdf5 verwendet. Auf dem MDS werden die generischen Metadaten (insb. Erzeugungsdatum, Ablageort, Zugriffsrechte) der erzeugten Daten abgelegt.
Um die Einheitlichkeit sicherzustellen, müssen alle Daten (Input und Output von Tools) als Python Dictionaries oder alternativen strukturierten Dateiformaten wie hdf5, JSON verfügbar sein. Die Daten müssen vollständig in diesen Formaten vorliegen (d.h. alle Informationen müssen aus den Daten erzeugbar sein), um in die Plattform integrierbar zu sein. Die Daten müssen an eine generische Ontologie gekoppelt sein. Die Metadaten (insb. Erzeugungsdatum, Ablageort, Zugriffsrechte) werden an die Plattform zur Ablage auf den MDS übermittelt.
Anwendungsnutzen der eingebrachten Beispiele gewährleisten, sowohl im Hinblick auf die Art der Datenablage, als auch den Mehrwert bei deren Analyse / automatisierter Anwendung
Initiale Anwendungsfälle entwickeln, um Plattform- und Digitalisierungsnutzen insgesamt aufzuzeigen.
Formate und Tools der Plattform auf den eigenen Anwendungsfall anwenden.
Formate und Tools der Plattform definieren und bereitstellen.
Erzeugte Ontologien und ergänzende Frameworks sind nachhaltig der Plattform zur Verfügung zu stellen. Gemeinsame Lerneffekte, die erst durch den Austausch entstehen, fließen in die Plattform ein. Darüber ergibt sich auch die übergeordnete Aufgabe, sich aktiv in die Zusammenarbeit und Abstimmung einzubringen.
Informationsbeschaffung proaktiv nach dem „Pull“-Prinzip, Verantwortung liegt bei den Use Cases.
Bereitstellung einer zugänglichen und zuverlässigen Kommunikations- und Beratungsumgebung.
Notwendigkeit entsprechende Anpassungen im Arbeitsplan der geförderten Projektei zu gewährleisten, z.B. über entsprechende agile Arbeitsweisen.
Grundsätzlich muss die Plattform die Industriebedarfe zentral berücksichtigen.
Teilnahme an entsprechenden Veranstaltungen, sowie inhaltliche Beteiligung.
Kommunikation der Veranstaltungen, Zugang sicherstellen.
