buildingSMART
Have more meaningful prefix than Pset or Qset for standardized property sets
Description of the proposal:
Having "Pset" and "Qset" as prefix for "official" property sets is quite funny. Could the prefix be something else, like IFC, or nothing. Why do we need them?
What do we win:
More meaningful property set names
What do we loose ?
Schema impact: None
Instance model impact: Small
Backwards compatible: None
Automatic migration possible: ?
Additional implications:
Note that not all points need to be satisfied! Backwards compatibility and file size are not concerns.
For geolocation in IFC2X3, the unofficial standard of EPset_ was created to represent an endorsed by buildingSMART but "not yet in the spec" pset.
If Pset_ and Qto_ is removed, then EPset_ can also be removed.
agree, but I would refer to issue #28.
If we have a clearly defined publication and referencing of those properties and quantities that are part of the international IFC specification, ISO 16739, then we don't need such prefixes anymore. Then any system can look-up the official publication to identify, whether it is an international property sets by definition, or not.
A PSet (again a set, not a list) is a fixed list of properties, for exactly one purpose. As we all know, the world is full of PSets, but more in the meaning of data templates:
- purpose specific
- specific for different access levels of different roles of users
- tool specific
Important will be the usage of agreed property definitions, but the data templates will be more dynamic. IFC itself has a good mechanism and semantics with the IfcSimplePropertySetTemplate and IfcComplexPropertySetTemplate. Why do we not use that, instead of PSet and QSets?
