# Ontology Workshop

## Ziele

* Weiteres Vorgehen definiert mit Kunde
* Vorschläge zur Upper Ontology/gist diskutiert & entschieden ob und wie weiter
* Werkzeuge zumindest diskutieren, klarer Fokus auf Why und nicht spezifisches Tool
* Beispiele, wie das mit Data Mesh aussehen könnte in Bezug auf Ontologie

## Mögliche Hürden

* Was das Team macht muss mit anderen Teams/Architekten abgesprochen sein und Sinn machen
* Inhaltlich ist noch nicht klar, was man alles braucht
*

## Storyline

### Intro
* Sehr viele unterschiedliche Levels, die in einer "Ontologie" repräsentiert werden sollten
* Ob und wie die über Zeit überleben, ist schwer abzuschätzen
* Ausführlichkeit der verschiedenen Levels ebenfalls

* Ich sehe zwei Extreme
- Sehr konkrete, "physikalische" Daten, die im Katalog sind da sie aus echte Systemen kommen
- Abstrakte(-re) Konzepte (Partner), welche mehr oder weniger klar sind für Leute, die sich noch nicht mit der Materie befasst haben
* Zudem gibt es mögliche weitere Abstraktionen dazwischen (IOM!?)

### Why

* Warum machen wir dies? Was sind die Ziele?
* Werkzeuge und Abstraktionslevels sollten Zielgetrieben sein
* Kurzfristiges Ziel (!?)
- Datenprodukt PoC mit Linked Data (Data-Mesh)
* Langfristigen Ziele?
- "Mobi Onotologie"
- Kann alles sein von high-level Konzepten wie "Partner" bis zu Spalten in Tabellen
- Und einer Manifestation von konkreten Daten in dieser Ontologie

### Arbeitsweise

* Inhalte ändern sich, iteratives Vorgehen
* Die Ontologie sollte sowohl wachsen wie in Teilen "Depricated" werden können
* Zeit/Events sollten "first class citicens" sein können (aber nicht zwingend müssen)

Akzeptanzkriterien:

- Wir brauchen für die globale Semantik ein Tool um diese zu editieren
- Die initialen User sind festgelegt welche die Semantik definieren
- Wo/Wie wird die Semantik weiterverwendet?
- Weitere Optionen klären als Schema.Org Alternative

## Framing stories

* Unbedingt vermeiden: Elfenbein Ontologie (Beispiel MOPO)
* Tool sollte zumindest am Anfang (und wohl für den PoC) sekundär sein
* Im Zentrum sollte stehen, was semantisch (in RDF) rauskommt und wie es untereinander verbunden ist oder verbindbar ist
* Die Ontologie ist mit dem Datenprodukt PoC verwendbar und zeigt mögliche Abstraktionen auf unterschiedlichen Levels
* Möglichst wenig OWL
* Das Resultat muss präsentierbar sein an Leute, die sich nicht detailliert mit der Thematik auseinandersetzen
- Präsentiert werden wird es an leute, die kein RDF, OWL, SHACL, etc. kennen.
- Es geht mehr um die Abstraktionen als das Wie
- die Lösung darf kein Fremdkörper sein, nicht abgekoppelt mit der Mobi-Realität
- Man kann eine Abfrage machen die fachlich ist, kann es aber mit bekannten Konzepten in Verbindung bringen
* Ich möchte Datenprodukte designen könne
- Ich möchte mögliche Beispiele verbinden können, wo ich z.b. sage das in der neuen Welt entspricht ungefähr dem in der alten Welt
- Heute gibt es die Hierarchien, morgen anderen
- Zeigen, dass man den Weg gehen kann
- die Alte welt kann helfen, muss aber nicht zwingend das sein, was daraus entsteht
- Es sollte nicht einschränken, was man heute beschreiben will
- Man wird feststellen, dass es in der Applikations-zentristischen Welt viele Duplikate vom gleichen Konzept hat
- Man kann diese so verallgemeinern und verknüpfen, und mittelfristig aufräumen
- Wenn ich mehr Zeit hätte, wäre der Brief kürzer
- Könnte für die Ontologie stimmen, unser Prozess muss dies klar unterstützen können
- Ein Protokoll ist komplett, wenn man nichts rausstreichen kann
- Beispiel Andrea Data Warehouse:
- Er hat Metadaten erarbeitet, weil er sie nicht fand
- Er wollte das nicht, er musste quasi
- Im Idealfall kann man in der Zukunft ein Dataprodukt definieren, und findet alles in der Ontologie
- Rest ist Prozessfrage (wie )
* Dataproduct PoC
- wie weit geht man
- geht man konkret in die Tiefe oder macht man es nur sehr einfach
-