Allowed entity types

[CBenghi]

Hello all,

During meetings, my understanding was that IDS specifications were scoped to the descendants of IfcObject and IfcTypeObject. Now I see test cases on classes that do not inherit from these, and the documentation seems to state that every IFC class is valid.

Has this constraint changed lately or was I always mistaken?

I think the benefit of the constraint was to make editing UIs a little less intimidating for end users.

Thanks, Claudio

[Moult]

I'm OK with all classes :) Is it really that big of an issue? The UI thing sounds like it has a few solutions...

[aothms]

Just confirming @cbenghi's observation that I've also seen this transition kind of organically occurring.

For me being able to constrain things directly on IfcMaterial is a considerable advantage of the current approach, because multi-layered materials still behave a bit awkwardly. There's probably some direct use cases on geo referencing.

So all in all I'm in favour of allowing all classes.

I imagine there could be an issue though for the tools not operating directly on IFC. It will not be trivial for them to arbitrarily support classes. So what you'll probably see then is that they are able to only partially check conformance pre-export (products, types, materials for ex) and that the rest has to be checked post-export.

[CBenghi]

I think this should be considered carefully, as it might make implementation harder with limite practical benefits. Of the available facets today:

1. Attribute: this one is simple and can be used for any ifc class
2. Classification: this one only makes sense fo entities inheriting from IfcDefinitionSelect (IfcContext, IfcObject, IfcTypeObject and IfcPropertyDefinition)
3. Property: this one only makes sense fo entities inheriting from IfcObjectDefinition (IfcContext, IfcObject, IfcTypeObject)
4. Material: this one only makes sense fo entities inheriting from IfcDefinitionSelect (IfcContext, IfcObject, IfcTypeObject and IfcPropertyDefinition)
5. PartOf: this one only makes sense fo entities inheriting from IfcObjectDefinition (IfcContext, IfcObject, IfcTypeObject)

So restraining types to IfcObject and IfcTypeObject we would hit the vast majority of the semantic values for the facets, other than for just attribute use.

@aothms, can you elaborate on ways in which you would use the constraint on IfcMaterial or for georeferencing?

[aothms]

I think @Moult can maybe copy some of the cases he has been writing for his company, otherwise I'll give some examples later.

[rubendel]

I am also keen to learn about the use cases of allowing all entities. I do agree with @CBenghi on the fact that for most non IfcObject/IfcTypeObject entities, classifications, properties, materials and partOf are not relevant. I think allowing all types is perhaps more something for the future, version 2 of IDS where potentially traversal of IFC entities is also supported 😁

A potential performance issue I see with allowing all types is that when a user does not specify any type requirements in the applicability stage, the software will potentially have to iterate over every single entity in the IFC model. Smart software might be able to pre-emptively filter based on what's in the requirements, but with regexes being allowed everywhere that can be tricky.

[Moult]

I use attribute for specifying projected crs names, mapconversion coords, context/subcontext identifiers, ifcmaterial categories and names, profile names, organisation names (for FM), documentinformation (for FM mainly), ifcgridaxis tags.