In IFC4 Add2 TC1, there are a total of 23 inverse relation attributes, where the domain of the direct attribute is different from the declaring type of the inverse attribute. In these cases the declaring type of the inverse attribute is a subtype or type in the selection of the direct attribute domain. In 19 of these cases, this is due to the direct attribute domain being a select type, where the inverse can not be declared. This is inevitable and not the primary subject of this issue.
For the remaining 4 cases and for 6 of the select cases the inverse attributes are only defined on a subset of the subtypes, resulting in "partial" inverse attribute declarations. These may be intentional or accidental for particular cases, but I would suggest to remove all of these partial inverse declarations. On a case by case evaluation it could be decided whether it is intentional and reasonable to keep and than either turned into one complete inverse definition or split into a complete inverse definition and a unidirectional part.
Describe how it contributes to the objectives:
See win below.
What do we win:
Better compatibility with other modelling languages / meta models.
What do we loose:
Complicated constructions that are hard to understand.
Potentially some conciseness in the schema, if some of the asymmetries prove to be reasonable.
Schema impact:
See numbers above. May result in some duplication of attributes when there are many subtypes and only one to be spared out. But this smells like an accident or a bad modelling decision and should likely be fixed otherwise.
Instance model impact:
None.
Backwards compatible:
Yes.
Automatic migration possible:
After deciding asymmetries to keep and split and which to completely remove, yes.
Description of the proposal:
In IFC4 Add2 TC1, there are a total of 23 inverse relation attributes, where the domain of the direct attribute is different from the declaring type of the inverse attribute. In these cases the declaring type of the inverse attribute is a subtype or type in the selection of the direct attribute domain. In 19 of these cases, this is due to the direct attribute domain being a select type, where the inverse can not be declared. This is inevitable and not the primary subject of this issue.
For the remaining 4 cases and for 6 of the select cases the inverse attributes are only defined on a subset of the subtypes, resulting in "partial" inverse attribute declarations. These may be intentional or accidental for particular cases, but I would suggest to remove all of these partial inverse declarations. On a case by case evaluation it could be decided whether it is intentional and reasonable to keep and than either turned into one complete inverse definition or split into a complete inverse definition and a unidirectional part.
Describe how it contributes to the objectives: See win below.
What do we win: Better compatibility with other modelling languages / meta models.
What do we loose: Complicated constructions that are hard to understand. Potentially some conciseness in the schema, if some of the asymmetries prove to be reasonable.
Schema impact: See numbers above. May result in some duplication of attributes when there are many subtypes and only one to be spared out. But this smells like an accident or a bad modelling decision and should likely be fixed otherwise.
Instance model impact: None.
Backwards compatible: Yes.
Automatic migration possible: After deciding asymmetries to keep and split and which to completely remove, yes.
Additional implications: Not