[ How to find the actual path of a node ]

[michelangelo-acca]

Not sure what title to give, not sure if you already tought about that and if it is a problem:

• suppose to have the hello-wall example, then add the 2nd storey from the course by declaring a new node that inherits from the existing storey

• since the original storey contained a Space Boundary, the new storey will have aswell

• now, when refering to the "relatingSpace", both will have as path: "e3035b71-bd9f-4cdc-86fd-b56e2f4605b6"

but in actual implementation, how do you know if it is refering to the space on the original floor, to the one on the new floor, or both?

I mean, if I ask, which is the space referred from the space boundary on the first floor, it is not possible to answer, because this is ambiguous

[aothms]

I'm planning to work on a demonstration of this as part of the "Domestic Hot Water" sample that uses a connectsTo attribute for the system topology on ports that are nested under the devices and segments. This works nice and easy, until we re-instantiate one of the devices, after which the ports nested under the device are no longer uniquely identify by their (not concatenated) path. Hence, a prefix needs to be constructed so that the port can be unique identified (example WIP).

We'll also see this with more heterogenous data, for example BCF topics serialised in IFC5X, what happens when the element that the issue pertained to gets re-instantiated, suddenly the scope of the issue is also changed. I don't think there are universal ways of working around this. For the systems connectivity we can constrain (how?) that in the final topology a port can only be 1 to 1 connected, otherwise it is a modelling error. But in the BCF case you don't know whether the issue was related to the data of the 'typical idea' or as the 'specific occurrence' (but you do have a choice to relate to the full path if you want to indicate that the issue is related to the specific occurrence).