late binding approach to taxonomies and properties

[TLiebich]

as suggested by @pipauwel, lets open a new thread. I will label it both as enhancement and governance, because it can only be answered having both in mind.

enhancement - what would be the right way to: a) publish the "late binding" content as part of the internationally agreed IFC specification (and ISO 16739) b) reference from within the IFC structure to its external "late binding" definitions

governance - how to ensure that: a) the definitions that are currently in IFC (like the IFC class structure underneath IfcProduct, that is the baseline of many exchanges today and that is currently strongly enhanced for infrastructure) are internationally maintained as part of the IFC specification (specification =/= schema) b) that those definition can easily enhanced by national, regional, trade, etc. definitions using the reference structure from within the IFC

bSDD is a "theoretical" answer, but not a "practical" answer as of today. Any thoughts?

[jwouellette]

I agree with @TLiebich points and believe there should always be an official bSI "baseline" implementation of most, if not all of the schema, in a practical use sense. This includes such classes, taxonomies, and properties to serve the general purposes of the marketplace. This serves two purposes:

• an immediately usable solution for markets/project with no strong development, adoption or implementation of standards for such definitions (I hate to say it, but that's the US, folks, for some time to come);
• a basis for multi-jursidictional (national/market) cooperation of single domains (rail, road, bridge, products);

I also believe we had a general (gentlemen's?) agreement in Tokyo about what "level" in the schema the late binding alternative (e.g. bSDD) would occur....

[pipauwel]

Okay, so maybe we can make that gentlemen's agreement an explicitly written out agreement (maybe on the README cover page of this repository?)?

The late binding boundary line can be in three places in the class hierarchy:

1. Right after "IfcElement", so less than what is included now in the schema (no Wall)
2. Right after the main concepts of the hierarchy (as is the case now - incl Wall, excl CO2Sensor)
3. After the deeper level - so almost no late binding

Which one was the gentlemen's agreement, @jwouelette?

Thinking out loud: (2) is the easy vote - not much change - yet it allows to find a bSDD-like alternative for the predefinedType enums; (3) is not an option, as concluded in the other thread; (1) is a longer term option to consider.

If we can decide and (re-)confirm a specific choice, that would be great.

[jwouellette]

@pipauwel I'm trying to find the notes from that meeting. I believe Greg Schleusner has them.

We need to get him connected...

[pasi-paasiala]

Okay, so maybe we can make that gentlemen's agreement an explicitly written out agreement (maybe on the README cover page of this repository?)?

The late binding boundary line can be in three places in the class hierarchy:

1. Right after "IfcElement", so less than what is included now in the schema (no Wall)
2. Right after the main concepts of the hierarchy (as is the case now - incl Wall, excl CO2Sensor)
3. After the deeper level - so almost no late binding

Which one was the gentlemen's agreement, @jwouelette?

Thinking out loud: (2) is the easy vote - not much change - yet it allows to find a bSDD-like alternative for the predefinedType enums; (3) is not an option, as concluded in the other thread; (1) is a longer term option to consider.

If we can decide and (re-)confirm a specific choice, that would be great.

I'd go with option 1. However, this doesn't mean that we couldn't standardize the late-binding parts. The late-binding should also apply to relationships: It doesn't make sense to have relationships in the core schema that point to concepts that are outside of it.

[berlotti]

Principle solution:

123=IFCPRODUCT (... $345, ...) just one thing of certain type

345=IFCTYPEPRODUCT (......, , , IFCDOOR/DOUBLESWING, ...)

Decision: cutting point at IfcElement ór IfcProduct, depending on the implications. Consensus that IfcProduct is the best, but only when implications can be handled in a reasonable way.

Follow up: implications study

[TLiebich]

I would strongly propose to not make a premature decision about the cutting point. If looking at IfcProduct:

ENTITY IfcProduct
 ABSTRACT SUPERTYPE OF(ONEOF(IfcAnnotation, IfcElement, IfcPort, IfcPositioningElement, IfcProxy, IfcSpatialElement, IfcStructuralActivity, IfcStructuralItem))

it would mean, that an IfcAlignmentis now the same as an IfcWall, only differentiated by a label!? And maybe the label "Decision made" could be renamed "Decision in Vilnius" to better mark its source (being one source)?

[berlotti]

Decision: cutting point at IfcElement ór IfcProduct, depending on the implications. Consensus that IfcProduct is the best, but only when implications can be handled in a reasonable way. Thank you for providing your insight on the implications of IfcProduct cut-off

Alternative follow up: cut off at Ifc(Build)Element AND IfcSpatialElement