Open pipauwel opened 4 years ago
Perfect contribution according to the objective and goals of this repository. Thank you!
this awkward structure was the result of a desperate attempt to keep file-based backward compatibility (up till today, this was a strong demand in IFC development), when making the change to allow in IFC4 one relationship class, IfcRelDefinesByProperties
to link to multiple property sets (before, for each property set, also a new relationship class had to be added).
Given that this backward compatibility rules are not mandatory for the next schema change, the whole construct shall be deleted. We finally need a 1:N relationship between and object and the property sets assigned to.
seems to be an easy agreement, if we have the general agreement that file based backward compatibility is lifted as a strict requirement (the baseline for this repro). Proposed solution is:
step 1
ENTITY IfcRelDefinesByProperties
SUBTYPE OF (IfcRelDefines);
RelatedObject : IfcObjectDefinition;
RelatingPropertyDefinitions : SET [1:?] OF IfcPropertySetDefinition;
WHERE
NoRelatedTypeObject : SIZEOF('IFCKERNEL.IfcTypeObject' IN TYPEOF(RelatedObject)) = 0;
END_ENTITY;
a next step, depending on the other issue #17, like "no explicitly defined "user" attributes" and combining property sets and quantities, the need to have the additional layer of IfcPropertySetDefinition
goes away.
ENTITY IfcPropertySetDefinition
ABSTRACT SUPERTYPE OF(ONEOF(IfcPreDefinedPropertySet, IfcPropertySet, IfcQuantitySet))
SUBTYPE OF (IfcPropertyDefinition);
so step 2
ENTITY IfcRelDefinesByProperties
SUBTYPE OF (IfcRelDefines);
RelatedObject : IfcObjectDefinition;
RelatingProperties : SET [1:?] OF IfcPropertySet;
WHERE
NoRelatedTypeObject : SIZEOF('IFCKERNEL.IfcTypeObject' IN TYPEOF(RelatedObject)) = 0;
END_ENTITY;
there could be a step 3 by using a direct relationship between IfcObject
and IfcContext
and IfcPropertySet as of issue #12. It should be discussed there to allow an intermediate fix of this issue.
check list
what do we win
what do we loose
schema impact
instance model impact
backwards compatibility impact
automatic migration possible
There is only 1 EXPRESS TYPE in the IFC schema that is equivalent to a SET, namely
IfcPropertySetDefinitionSet
. This complicates matters drastically when converting to XML or JSON or RDF - for seemingly no reason?Who uses this? Can this be made an ENTITY in EXPRESS?
Slightly connected to this, is the
IfcPropertySetDefinitionSelect
TYPE. This TYPE is equivalent to a SELECT of either a TYPE (IfcPropertySetDefinition) OR a SET of ENTITIES (IfcPropertySetDefinitionSet). Also this is very (understatement) complicated to translate to any language other than EXPRESS and English.Because of these kinds of choices, everything needs to be objectified in any language other than EXPRESS. EXPRESS is one of the few languages that only knows 'datatypes' in its core (see ISO spec), where most other information modelling languages (Java, C#, RDF, XML, JSON) distinguish between objects/classes and attributes/values. So... EXPRESS allows to just link SETs to ENTITIES to LISTS to TYPES to INTEGERS to anything really, which is a problem for nearly all other languages. Suggestion: keep out these (relatively few) EXPRESS-specific constructs.