---
# System prepended metadata

title: Ontology Workshop

---

# 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
    - 





