search

snikproject / ontology

Public SNIK Ontology. An ontology of information management in hospitals.
https://snikproject.github.io/ontology/
Other
10 stars 1 forks source link

bb:Planning rdfs:subClassOf bb:Management #413

Closed AlfredWinter closed 3 years ago

AlfredWinter commented 3 years ago

Problem with the edge bb:Planning rdfs:subClassOf bb:Management (OntoWiki URL):

Löschen. Das iist keine SubclassOf sondern Komponente (diese Beziehung besteht schon).

KonradHoeffner commented 3 years ago

Dann hat bb:Planning allerdings keine Oberklasse mehr, was laut unseren Modellierungsregeln nicht erlaubt ist. Haben Sie eine alternative Oberklasse, die ich einsetzen kann?

AlfredWinter commented 3 years ago

Diese Modellierungsregel hat doch den Sinn, dass keine Klassen frei im Äther herumschweben, sondern über ine Hierarchie 'eingefangen' sind. Ist das denn nicht über die Komponentenbeziehung auch gegeben? Wäre es nicht eine Lösung, die Modellierungsregel so zu ändern: Muss Oberklasse haben ODER Komponente einer Klasse sein (die dann wieder Oberklasse haben muss oder Komponente ...)? Was meinen Sie?

KonradHoeffner commented 3 years ago

Also die Regel hat auch den Sinn, dass die Klassen visuell verbunden sind, hauptsächlich aber liegt es daran, dass eine Klasse, die nicht über rdfs:subClassOf mit der Hierarchie verbunden ist, auch nicht Teil der Hierarchie ist und damit keine Rolle/Funktion/ kein Entity Type mehr ist. Denn rdfs:subClassOf ist eine Teilmengenbeziehung, während die Komponentenbeziehung dies nicht ist. Z.B. ist ein Rad eine Komponente vom Auto, aber ein Rad ist kein Fahrzeug.

bb:Planning ist Unterklasse von bb:Management und bb:Management ist Unterklasse von meta:Function. Daher wissen wir (und SNIK Graph, SPARQL Queries und so weiter), dass es eine Funktion ist und können es auch als Dreieck darstellen. Wenn das wegfällt weiß z.B. SNIK Graph nicht mehr, welche Form bb:Planning haben soll. Und dann "ist" es auch keine Funktion mehr. Wir haben zwar noch die Hilfsbeziehung "meta:subTopClass" aber die wird auch nur aus den rdfs:subClassOf-Ketten erzeugt. Daher denke ich, dass die Modellierungsregel so bleiben muss, sonst sind die Daten "semantisch falsch" bzw. es fehlt etwas.

Was wir aber immer machen können, ist bb:Planning direkt an meta:Function hängen. Das haben wir aber immer versucht zu vermeiden, weil dann die Hierarchie so degeneriert und man auch nichts mehr sieht wenn alles an einem Knoten hängt. Ich glaube dazu hatten wir auch mal eine Issue, die finde ich aber gerade nicht. Daher versuchen wir immer erstmal eine alternative Oberklasse zu finden. Wenn es da aber keine gibt, können wir das aber direkt an meta:Function hängen.

AlfredWinter commented 3 years ago

Die Visualisierung ist mir nicht so wichtig. Das Anhängen an meta:Function ist doch dann die richtige Lösung

KonradHoeffner commented 3 years ago

OK, an meta:Function umgehängt. Falls jemand eine bessere Oberklasse findet, können wir das später noch verfeinern.