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

ob:DefiningProjectOrganization meta:updates ob:ProjectManager #266

Open AlfredWinter opened 5 years ago

AlfredWinter commented 5 years ago

The edge "ob:DefiningProjectOrganization meta:updates ob:ProjectManager" is incorrect.

Details das geht gar nicht :-(

LudwigWermke commented 5 years ago

@FranziskaJahn @BirgitSNIK @AnnaLoerke @KonradHoeffner : hier ist mir noch ein weiterer Fehler aufgefallen: Laut unserem Metamodell darf nu eine "Role" mit einer anderen "Role" durch "meta:roleComponent" verbunden sein. Die Sparql-Anfrage "select * { ?x meta:subTopClass meta:Function. ?y meta:subTopClass meta:Role. ?x meta:roleComponent ?y. }" liefert allerdings folgende Tupel, die nicht existieren dürften:

x y
http://www.snik.eu/ontology/ob/ProjectInitiation http://www.snik.eu/ontology/ob/DefiningProjectOrganization
http://www.snik.eu/ontology/he/Linienmanagement http://www.snik.eu/ontology/he/Technologiemanager

@KonradHoeffner -> die Abfrage kann ggf. in die Qualitätssicherungsabfragen von dir, oder?

LudwigWermke commented 5 years ago

Zusätzlich ist "DefiningProjectOganization" als "Rolle" Subklasse von "bb:Informationsmanagemnt", was eine Aufgabe ist... Auch bspw. die "Updates-Beziehungen" oder die ebenfalls illegale Veknüpfung mit "ob:Sponsor" (Rolle) durch "meta:isInvolvedIn" legen nahe, "DefiningProjectOganization" als Aufgabe zu modellieren Lösungsvorschlag:

  1. DefiningProjectOganization als Aufgabe
  2. Das Tripel (http://www.snik.eu/ontology/ob/ProjectInitiation meta:subTopClass, meta:roleComponent, http://www.snik.eu/ontology/ob/DefiningProjectOrganization) durch (http://www.snik.eu/ontology/ob/ProjectInitiation meta:subTopClass, meta:functionComponent, http://www.snik.eu/ontology/ob/DefiningProjectOrganization) ersetzen

Dadurch sollen zumindes keine logischen Folgekonflikte entstehen.

LudwigWermke commented 5 years ago

@KonradHoeffner Habe die Anfrage allgemeiner verfasst, liefert jetzt noch mehr illegale Beziehungen: select * { { { ?x meta:roleComponent ?y. } MINUS { ?x meta:subTopClass meta:Role. ?y meta:subTopClass meta:Role. ?x meta:roleComponent ?y. } } UNION { { ?y meta:roleComponent ?x. } MINUS { ?x meta:subTopClass meta:Role. ?y meta:subTopClass meta:Role. ?y meta:roleComponent ?x. } } }

KonradHoeffner commented 5 years ago

@LudwigWermke: Alle Domain- und Rangeverletzungen werden schon vom Quality Check abgedeckt, siehe:

https://imise.github.io/snik-ontology/2017/06/01/qualitycheck/#domain-violation https://imise.github.io/snik-ontology/2017/06/01/qualitycheck/#range-violation

KonradHoeffner commented 5 years ago

Ich verstehe die UNION nicht, sind das nicht gleiche Terme mit vertauschter Variablenbelegung? Ich denke der zweite Term hat das gleiche Ergebnis wie der erste, nur mit vertauschten Spalten.

@KonradHoeffner Habe die Anfrage allgemeiner verfasst, liefert jetzt noch mehr illegale Beziehungen: ...

LudwigWermke commented 5 years ago

Hm @KonradHoeffner du hast Recht. Tendentiell ging es mir nur um das MINUS. Die UNION erzeugt aber in der Tat Unsinn -> liegt das daran, dass die Beziehung meta:roleComponent symmtrisch modelliert ist oder habe ich da einen Denkfehler? Eigentlich wollte ich noch zusätzliche Tripel greifen, die die meta:oleComponent Beziehung verletzen. Können wir aber vmtl eher in Person besprechen

KonradHoeffner commented 4 years ago

Dazu gibt es ein Kapitel ab Seite 38.