Limit all "user" properties to be expressed by property sets / remove "direct" attributes

[TLiebich]

today 98% of all properties that are either set by users in BIM software, or are derived by the software systems based on user entries, are handled by property sets. But there are a few exceptions, like:

• IfcRoot.Name
• IfcRoot.Description
• IfcElement.Tag
• IfcSpatialElement.LongName
• a few more

and there are still many deprecated direct attributes in the schema for backward compatibility issues, like:

• IfcStairFlight.NumberOfRisers, etc.
• IfcMechanicalFastener.NominalDiameter

all those attributes should be removed (or at least repurposed) in order to use only late-binding property sets. The very specific handling of such few attributes makes it already today difficult to use configuration files for IFC mapping of properties in BIM authoring tools.

[berlotti]

But (i hope) still have propertysets on the ifcRoot level so they are inherited by specializations of IfcRoot?

[jwouellette]

How would this affect efforts to pass enough parametric data for enhanced object translation (design transfer)?

[TLiebich]

to @berlotti - my proposal does not change the way, properties can be handled genericly. But today, there is a conflict by sending the name of a pump (lets call it "electric pump #1") directly as an attribute at IfcPump.Name (inherited by IfcRoot), whereas all other pump properties are send as IfcPropertySet associated to the pump. So I need two different code in order to retrieve the name of the pump and all the rest.

NOTE - strictly speaking, IfcRoot.Name needs to be repurposed and not deleted, as there is still valid use of it (but not to duplicate user properties at element level).

[TLiebich]

@jwouellette - all attributes that control object translations shall remain as is.

[jwouellette]

@TLiebich the "naming/ID" of things could be an explicit issue itself. As you point out, there are multiple methods to identifying a single object by some kind of

1. instance name (short) "DOOR-202A"
2. instance description (long) "Door, Room 202 to Hallway 200"
3. type name "D-3"
4. tag/keynote (could be any combo or use of type or instance name, or a new ID system)
5. GUID/UUID

Maybe it is a matter of documentation clarity, maybe a redaction/reduction of attributes on objects to prevent overlap, or changing the name of the attribute dependent on object class?

[pipauwel]

I am fully in favour of putting all attributes in one place. Yet, I would not put them in propertysets, and instead put them all directly with the object. Where attributes actually belong,

It is really impossibly difficult, and also totally pointless, to explain any IFC starting developer or student why they need to do:

myWall.IsDefinedBy.RelatingPropertyDefinition.HasProperties.Name and 
myWall.IsDefinedBy.RelatingPropertyDefinition.HasProperties.NominalValue

to figure out that a wall isExternal.

I suggest: myWall.isExternal = true; just like myWall.Name = "myWallName" currently exists.

If this

myWall.IsDefinedBy.RelatingPropertyDefinition.HasProperties.Name and 
myWall.IsDefinedBy.RelatingPropertyDefinition.HasProperties.NominalValue

becomes the standard, also for GUIDs and names, then even more starting developers will drop out from IFC, rightfully.

[TLiebich]

actually I am in full disagreement to @pipauwel here. The main question is not the number of steps (".") in myWall.IsDefinedBy.RelatingPropertyDefinition.HasProperties.Name, but whether the IFC schema, declaring a wall, which normally has a time span of 5 years (e.g. between 2 ISO versions) can be dynamicly extended without a change in the static part. At least, as long as EXPRESS/SPF needs to be maintained as a definition/serialization option, anything like adding a direct attribute resulting in a schema change is a show stopper.

However, seeing the other thread about objectified relationships, there is room to improvement without going that far. E.g. myWall.HasPropertySets.HasProperties.Name

[pipauwel]

myWall.HasPropertySets.HasProperties.Name

This would be a great improvement already indeed. But indeed also more part of the other thread (#12).

Other than that, yes, they are two very contradicting views. I understand and appreciate the idea of late binding, but then that should be a clear technical choice and strategy (which I don't think it is now). Late binding has a lot of benefits to the industry, as (non-standard) property sets can be made, and they can still be called IFC. Standardisation and naming conventions are deferred to the user. Such late binding strategy also gives a right for bSDD-like technology to exist.

If we make that choice, then we should not pretend that we are standardising properties as part of IFC, and then predefined buildingSMART propertysets should not even exist. That is also the current strategy in the W3C Linked Building Data (LBD) group. When such predefined PSETs (in XML) disappear from the IFC spec, and move out to a bSDD-like mechanism, then we can easily keep those common identifiers (Name, ID, Description) close to the object. They don't need to be late binding - as we standardise those in the IFC core.

A very similar choice needs to be made in #23, where it is clear that also TYPEs are both included in the schema, and made available for late binding (predefinedType). @jmirtsch prefers late binding there as well, but then those predefinedtypes should also go and not clutter the schema. We then standardise on the overall structure, and leave standardisation of type names and property names outside the IFC core standard. BSDD and/or modularisation may be able to play a good role in this.

@berlotti Choosing for late binding probably deserves a separate thread.

[pbourreau]

I agree with @pipauwel on putting attributes in objects, and avoiding to use Property Sts. I see the use of Property Sets as a way to avoid using multiple inheritance; and it seems to have different drawbacks:

• the path between an object and the values of its attributes can be long because of the property sets in between. If we want to have transactional data exchange, this will add a lot of complexity to the implementers.
• the schema in itself is hard to read, and hard to maintain because you cannot see what are the attributes (or properties/quantities) associated to specific objects in a straightforward way.

It seems that avoiding using multiple inheritance is an historical choice that should perhaps be re-discussed by the community, and that could bring some solution to this kind of issues. Let's consider the example of the AirTerminal class. It has various PSets associated in its schema, for instance the PSet_ElectricalDeviceCommon. This could be replace with a class ElectricalDevice and the properties in PSet_ElectricalDeviceCommon can be transformed as attributes in ElectricalDevice. Then AirFlowTerminal can still be a subclass of FlowTerminal and inherits all its attributes, and now be also a sublass of ElectricalDevice.

[tldddd]

My view is that:

• Attributes should be for data that is truly global and universal.
• Properties are for when there could be variation (per country, per project, per company, even per person, or per workflow)

Different countries, projects, and companies very often need properties to be named specifically according to their needs. bsDD is a great starting point for standardisation but it is never going to be able to handle every need.

Trying to standardise the properties of an ElectricalDevice by putting one set of properties (which will not be suitable for many) directly in the spec will not help the situation. IFC needs to be flexible with property sets to allow for variation.

I think that currently there are some attributes that are not universal enough to warrant being included in the schema specification.

I would argue that Name, Description, ObjectType, and Tag are universal enough to justify being a part of the specification.

But, I feel like all "design" attributes from IfcElement downwards are not universally understood enough and should instead move into the bsDD which is specifically attempting a more universal understanding.

[pbourreau]

I agree with you @tldddd on moving some attributes to the bsDD.

My point is that, rather than adding attributes to an element through property sets (in the schema itself or for a specific country/project...) could be done through the definition of a new class, rather than through property sets. I think that using inheritance/new classes rather than new property sets would not impact the flexibility of IFC, while solving some counterparts of PSets.

So, perhaps, two different topics:

• how to add new attributes/properties to a concept?
• what is the minimal/universal set of attributes that need to be in the next IFC, for each separate concept?

[berlotti]

Don't turn this in a bSDD discussion please. When properties have a global agreed definition and consensus they are part of IFC. There is no reason to remove this semantic richness from the IFC standard, just because it is difficult or 'nicer' in the data model.

Let's circle back to the original issue: putting properties in a set. @TLiebich would you like to try to fill out the template?

• Description of the proposal:
• Describe how it contributes to the objectives set in https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC:
• What do we win:
• What do we loose
• Schema impact:
• Instance model impact:
• Backwards compatible:
• Automatic migration possible:
• Additional implications: