predefined Pset_ and Qto_ sets in Express schema and IfcOS C++ API?

[dirkolbrich]

How are the multiple predefined Pset_ and Qto_ sets defined in the IFC express schema and as a result in the IfcOS C++ API?

I was looking through the schema and code base and found no definitions of these.
In the schema (here in IFC4X3_ADD2) I only found the abstract IfcPropertySetTemplateTypeEnum which defines the super types of e.g. Pset_WallCommon, but not the properties defined for this Pset:

TYPE IfcPropertySetTemplateTypeEnum = ENUMERATION OF
	(PSET_MATERIALDRIVEN
	,PSET_OCCURRENCEDRIVEN
	,PSET_PERFORMANCEDRIVEN
	,PSET_PROFILEDRIVEN
	,PSET_TYPEDRIVENONLY
	,PSET_TYPEDRIVENOVERRIDE
	,QTO_OCCURRENCEDRIVEN
	,QTO_TYPEDRIVENONLY
	,QTO_TYPEDRIVENOVERRIDE
	,NOTDEFINED);
END_TYPE;

Thus the generated C++ files also do not have the exact definitions of Pset_ and Qto_ or some classes to represent these. The only definition in the IfcOS source is under the src/ifcopenshell-python/ifcopenshell/util/schema folder with a ifc4x3_properties.json file which seems to be only available to the IfcOS Python API.

The official source for the predefined Pset_ and Qto_ is apparently a downloadable .zip file from the buildingSmart IFC specifications database with the single specification as a .xml file.

Is there a way to bring the Pset_ and Qto_ definitions to the C++ API as well? Maybe by writing a separate XmlParser?

[Moult]

IFC defines a few classes to define property / quantity set templates, such as IfcPropertySetTemplate. There are certain rules to decide how to parse these to see which templates are applicable to which classes. This is implemented in Python in the util/pset.py module. The buildingSMART reserved prefix templates (Pset_ and Qto_) are provided in both IFC and XML format (though in the latest version, only XML, though I hope to change that by submitting our conversion of it). It's stored here: https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.7.0/src/ifcopenshell-python/ifcopenshell/util/schema in the *.ifc files (not the JSON files, those are only used for docstrings).

Note that anybody can define their own pset / qto templates - so an XML parser will not be enough as these will often be in IFC itself.

[dirkolbrich]

Understood, the IFC schema provides base entities like IfcPropertySetTemplate to build custom property sets.

But shouldn't the predefined official Pset_ and Qto_ sets like Pset_WallCommon and others, which basically are used as schema standards and not custom property sets, be also defined in the official IFC express schema?

I find that a bit inconsistent that these quasi-standards are only provided in a different schema language (express vs xml) and are defined separately to the base IFC schema.

In connection with IfcOS the thing I'm looking for is, if the official Pset_ are also defined within the C++ API, the creation or modification of these would be testable and their correctness enforcable by code.

Right now, I can define a Pset_ manually - see example in src/examples/IfcOpenHouse.cpp - but have to rely on my knowledge of the official predefined Pset_ set, which is a source of error.

[Moult]

I guess the difference is that the IFC EXPRESS schema defines core data types, which have a lower rate of change, and the Psets define more auxiliary, more opinionated, or country / locale specific standards which has a higher rate of change. I believe it is strategic to decouple them and I suspect there will be further decoupling in the future as the bSDD (a centralised API to host properties) becomes more widespread, i18n efforts become a little more mature, etc... there may be even decoupled release cycles.

[aothms]

and to add to that in IFC5 there are rather serious plans to move the IFC built element taxonomy also to a latebound (i.e string or data based) structure. None of this precludes a statically typed / early bound API to these more auxiliary structures though. Similarly to how we generate code from the express schema we could do the same from the psets.

[dirkolbrich]

it is strategic to decouple them and I suspect there will be further decoupling in the future as the bSDD (a centralised API to host properties) becomes more widespread

Interesting, I wasn't aware of the bSDD API yet. I played a bit with the API explorer. Unfortunately it seems to be not yet functional for Pset_ definitions - I was able get the definitions for a single class (e.g. IfcWall) or a single property (e.g. FireRating), but not for for a complete Pset_(e.g. Pset_WallCommon) although it has an entry into the bSDD database. As for now only the downloadable Pset_ definitions are available.

Note: I could theoretically scrap the Pset_WallCommon definition out of the the API provided IfcWall definition, but this would become cumbersome quickly. I would have to query all IFC classes to check which Pset_ definitions are available instead of having a single endpoint for all the available Pset_ and Qto_ definitions.

I see two possible implementations for the bSDD API, which are quite fascinating, as they could be completely automated:

1. have an automated CRON job on the tools developer side, which queries the bSDD API periodically (weekly should be enough) -> check the versionsDateUtc for any updates on the definitions -> if yes generate/update the API endpoints for the tool -> prepare and push a new release
2. give the user of the tool the possibility to update the definitions via an in-tool API function, maybe even update periodically on tool start-up time -> which I think is not preferable as the implication could be two users with the same tool version but different schema definitions - that would be a frustrating debugging process

Similarly to how we generate code from the express schema we could do the same from the psets.

Yes, write a xml-parser.py which generates the PSD_Ifc4x3.hand PSD_Ifc4x3.cpp files. This could be later modified to query the bSDD API during generation.

The bSDD API is interesting in another way as it can help in including schema documentation into the generated C++ schema files. Currently the documentation is used from fixed (and probably outdated and not fitting to the different schema versions) csv files - excerpt from src/ifcopenshell-python/ifcopenshell/express/documentation.py:

# This files uses the documentation files from buildingSMART to generate 
# descriptions from EXPRESS names that are suitable for comments in the C++
# code. The .csv files used by this file are generated from the MS Office
# Access database, which in turn has been generated from the IFC baseline
# documentation by the IFCDOC utility provided by buildingSMART.