buildingSMART
Do something about IfcPropertySetDefinitionSelect and IfcPropertySetDefinitionSet
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?
TYPE IfcPropertySetDefinitionSet = SET [1:?] OF IfcPropertySetDefinition;
END_TYPE;
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.
TYPE IfcPropertySetDefinitionSelect = SELECT (
IfcPropertySetDefinitionSet,
IfcPropertySetDefinition);
END_TYPE;
TYPE IfcPropertySetDefinitionSet = SET [1:?] OF IfcPropertySetDefinition;
END_TYPE;
ENTITY IfcPropertySetDefinition
ABSTRACT SUPERTYPE OF (ONEOF
(IfcPreDefinedPropertySet
,IfcPropertySet
,IfcQuantitySet))
SUBTYPE OF (IfcPropertyDefinition);
[...]
END_ENTITY;
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.
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
- less awkward and difficult to implement structure
what do we loose
- nothing
schema impact
- minor
instance model impact
- minor, need to change a set into a mandatory single attribute
backwards compatibility impact
- some, the cardinality of two attributes changes
automatic migration possible
- yes