ob:DefiningProjectOrganization meta:updates ob:ProjectManager

[AlfredWinter]

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

Details
das geht gar nicht :-(

[LudwigWermke]

@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]

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]

@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]

@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]

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]

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]

• http://www.snik.eu/ontology/ob/DefiningProjectOrganization ist momentan eine Rolle, das ist falsch. Es muss eine Aufgabe sein.

Dazu gibt es ein Kapitel ab Seite 38.

• Es ist im Metamodell nicht möglich auszudrücken, dass eine Aufgabe auf diese Art und Weise mit einer Rolle zu verknüpfen. Ändern zu meta:isAssociatedWith, da es keine andere Möglichkeit gibt.