-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify relation recursion and cardinality #155
Comments
It seems clear to me in the testcases: https://github.com/buildingSMART/IDS/blob/master/Documentation/testcases-partof.md#pass-an-aggregate-entity-may-pass-any-ancestral-whole-passes Whether people agree with the decision proposed by the testcases is another matter. |
The current proposal, to be properly documented, is: relation is not required
I've prepared an improved version of the document to present in the calls. |
Is it possible that requirements of Specification will specified for two entities or how can describe this logic in ids:
#123= IFCBUILDING('31atqolsbBix6RN8sQNzEj',#42,' building',$,$,#33,$,'building',.ELEMENT.,$,$,#119); |
Currently the partof facet seems to be recursive by default as suggested by these IDS and IFC files.
This isn't very clear for example in the case when there's an assembly that contains another assembly that contains a slab and the slab is required to be part of one assembly. Would that cardinality fail in this case, since it is indirectly contained in two?
Should there be a flag in the partof requirement explicitly saying whether it should be applied recursively? Or should the relation be traversed until a parent is found that fits the requirement and stop there?
Also now it is not possible to require a direct relationship. A flag would help also in that case.
The text was updated successfully, but these errors were encountered: