IfcPropertyDependencyRelationship always raising IFC105 - Resource entities need to be referenced by rooted entity

[fg55b]

Hello everyone,

A particular case falling under the scope of IFC105 is IfcPropertyDependencyRelationship. It appears impossible to use this class in compliance with IFC105, as the rule's traversal logic cannot reach it.

The relationship references IfcProperty instances. While IfcProperty is reachable from IfcPropertySet (a rooted entity) via the HasProperties attribute, the traversal cannot proceed further to IfcPropertyDependencyRelationship. This would require traversing the inverse attributes PropertyForDependance or PropertyDependsOn of IfcProperty, which are not currently in the whitelisted inverses defined in the rule.

Consequently, valid usage of this relationship is always flagged as an error. Based on this definition, it seems that other subtypes of IfcResourceLevelRelationship may exhibit the same behavior, although they were not individually tested.

[aothms]

I assumed that this kind of relationship would always be between two properties that are each used in the context of a property set (either the same or another one) and are as such reachable from a rooted instance. Because otherwise you don't really know the context of the property. Do you know of (other) tools that write this data so that we can look at their usage patterns? I'm fine with giving it the benefit of the doubt for all resourcelevelrelationships, better safe than sorry.

[fg55b]

In the file that triggered the error, the IfcPropertyDependencyRelationship related two properties within the same IfcPropertySet. I was careful to avoid referencing any orphaned IfcProperty instances, which would be a true positive for the rule.

The file was generated using IfcOpenShell, and I am not aware of other tools that employ this relationship. I haven't seen it used outside of our data model.

Regarding a solution, creating an exception for the relevant IfcResourceLevelRelationship subtypes (this needs verification) seems reasonable. I suspect that limiting the exception to the relationship instances themselves would not compromise the IFC105 verification, as orphaned properties (like the IfcProperty mentioned earlier) would still be caught, even if referenced by the exempted relationship.

[aothms]

In the file that triggered the error, the IfcPropertyDependencyRelationship related two properties within the same IfcPropertySet. I was careful to avoid referencing any orphaned IfcProperty instances, which would be a true positive for the rule.

Then I don't understand. Could you attach something that exhibits the issue? Thanks

[fg55b]

Of course! Here is an example of a file that raises only the IFC105 error.

ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1');
FILE_NAME('','2026-02-25T17:01:03',(''),(''),'IfcOpenShell 0.8.0','IfcOpenShell 0.8.0','');
FILE_SCHEMA(('IFC4'));
ENDSEC;
DATA;
#1=IFCPERSON('id','user','user',$,$,$,$,$);
#2=IFCORGANIZATION($,'org',$,$,$);
#3=IFCORGANIZATION($,'org',$,$,$);
#4=IFCPERSONANDORGANIZATION(#1,#2,$);
#5=IFCAPPLICATION(#3,'0.0','IFCTester','IFCT');
#6=IFCOWNERHISTORY(#4,#5,$,$,$,$,$,1772049663);
#7=IFCCARTESIANPOINT((0.,0.,0.));
#8=IFCAXIS2PLACEMENT3D(#7,$,$);
#9=IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,$,#8,$);
#10=IFCGEOMETRICREPRESENTATIONSUBCONTEXT('Body',$,,,,,#9,$,.NOTDEFINED.,$);
#11=IFCPROJECT('3a_MKonSn43fs5Hd6JdOIQ',#6,'Project ID',$,$,'Project long name',$,(#9),#15);
#12=IFCSIUNIT(,.LENGTHUNIT.,.MILLI.,.METRE.);
#13=IFCSIUNIT(,.AREAUNIT.,$,.SQUARE_METRE.);
#14=IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#15=IFCUNITASSIGNMENT((#13,#14,#12));
#16=IFCSITE('0cYo0Jtbn3RBB4K4dL5rd$',#6,'Site','Description of the site','GenericSite',$,$,$,$,$,$,$,$,$);
#17=IFCRELAGGREGATES('2_fRqqoqP6YPLyyPStWt$U',#6,'IfcProject decomposition relationship','Relationship of the IfcProject instance and its decomposed parts.',#11,(#16));
#18=IFCBUILDINGELEMENTPROXY('2Vdodf$jz6QQ_B3pKROlap',#6,'Test element',$,'TestElement',$,$,$,$);
#19=IFCRELCONTAINEDINSPATIALSTRUCTURE('2EBBgP4BfCWh7goz7Zerya',#6,'Containment relationship','',(#18),#16);
#20=IFCPROPERTYSINGLEVALUE('Property 1',$,IFCTEXT('Value property 1'),$);
#21=IFCPROPERTYSINGLEVALUE('Property 2',$,IFCTEXT('Value property 2'),$);
#22=IFCPROPERTYSET('16pZVJu3jEbRfblNvt4JlK',#6,'Property set','Example property set',(#20,#21));
#23=IFCRELDEFINESBYPROPERTIES('0raIUSVGj1pAre5kdt5RD$',#6,'Properties relationship','',(#18),#22);
#24=IFCPROPERTYDEPENDENCYRELATIONSHIP('Property dependency','Property dependency of two properties of the same property set',#20,#21,$);
ENDSEC;
END-ISO-10303-21;

The validation report was:

[aothms]

Ah, sorry, I'm stupid. It's about the dependency node itself, not the properties. Yes that's for sure, they need to be added.

[pjanck]

The IfcPropertyDependencyRelation is not part of Reference View 1.2 - see list of supported entities.

Do you know of (other) tools that write this data so that we can look at their usage patterns?

I would be curious if anyone else implemented this.

I haven't seen it used outside of our data model.

This is expected outcome, since it is not part of any officially published MVD - at least not to my knowledge.

they need to be added

I agree - validation service is schema-level checking and should not flag it as an error.

[aothms]

Ok, I looked up all inverses that get us to a resource level relationship. Side effect of adding them to the traversal is that - contrary to what we discussed - this means that both the node, but also the other end will be marked as reachable from rooted instance. This is the best we can do on a short time frame, as mentioned better safe than sorry. I will add a refinement (and also fully quality inverses, because only by name is likely going to result into name clashes now) for our next iteration of rule development next year.

>>> def inverse_attributes_for_attribute(ent, attr):
...     for other in ent.schema().entities():
...         inverses = other.all_inverse_attributes()
...         if other.supertype():
...             inverses = inverses[len(other.supertype().all_inverse_attributes()):]
...         for inv in inverses:
...             if inv.entity_reference().name() == ent.name() and inv.attribute_reference().name() == attr.name():
...                 yield other, inv
...
>>> def resource_level_relationship_inverses():
...     import ifcopenshell
...     w = ifcopenshell.ifcopenshell_wrapper
...     s = w.schema_by_name('ifc4x3_add2')
...     e = s.declaration_by_name('IfcResourceLevelRelationship')
...     for st in e.subtypes():
...         for attr in st.attributes():
...             for _, inv in inverse_attributes_for_attribute(st, attr):
...                 yield inv.name()
...
>>> print(set(resource_level_relationship_inverses()))
{'Relates', 'ApprovedResources', 'IsPointedTo', 'PropertyDependsOn', 'ExternalReferenceForResources', 'IsRelatedWith', 'PropertyForDependance', 'HasApprovals', 'PropertiesForConstraint', 'IsPointer', 'RelatesTo', 'HasExternalReference', 'IsRelatedBy', 'HasConstraints', 'HasExternalReferences'}

[fg55b]

Since this is a temporary solution, wouldn't adding the resource relationships directly to the visited set in the transversal search avoid this side effect? This way, the relationship nodes would be marked as valid, but the traversal would not proceed through them to the 'other end'.

[aothms]

This way, the relationship nodes would be marked as valid, but the traversal would not proceed through them to the 'other end'.

That's a nice idea but also potentially confusing because if they are also considered valid then when not reachable from a rooted instance. Which is not so bad, because if that would be the case, the same would apply to the resources that are being related. So I don't think it would result in a model being flagged as valid where it's actually not the case. My biggest concern is that it muddies up the logic of the rule, which starts with traversal from rooted instances. I don't like to deviate from that core premise. Anyway this is also case in point for the criticism on IFC wrt distributed authoring: how difficult it is to delineate "an object" and build incremental predictable exchanges on top of that. Since we have been discussing this so extensively anyway I will also add the condition that traversal stops at IfcResourceLevelRelationship, but traverses into it by means of its inverses. It's trivial anyway.

[aothms]

#502

[fg55b]

My biggest concern is that it muddies up the logic of the rule, which starts with traversal from rooted instances. I don't like to deviate from that core premise.

That makes perfect sense. Preserving the consistency is essential for maintainability, so I agree with your concern. In any case, the solution you implemented seems like the right approach, avoiding the approval of orphan resource entities. Thanks for the fix and the explanation!