subtract/exclude/remove from, for applicability? #177
Comments
|
Yes, we need Exceptions (not IfcSpace and not IfcOpeningElement) alongside Applicability and Requirement.
Also Selections (any IfcWindow and any IfcDoor) or (any IfcWindow and anything with ThermalTransmittance>0.2)
Regards,
Nick.
From: ay-ex ***@***.***>
Sent: 27 July 2023 07:06
To: buildingSMART/IDS ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [buildingSMART/IDS] subtract/exclude/remove from, for applicability? (Issue #177)
First of thank you for the amazing IDS mechanics, they are great for doing checks on IFC model quality. 🙂
One thing I was missing (or maybe just overlooked?) when reading through documentation and github issues
while creating rules for some of our projects, is the ability to subtract/exclude/remove something from applicability.
E.g.:
We would like to set the applicability to all elements of certain Ifc classes with a specific Pset.Property value,
then excluding the ones with a specific Name.
But the applicability steps seems to only append not subtract.(?)
Ideally it would possible to do the following:
* Applicability 1:
* Add all elements of
* IfcWall, IfcDoor, IfcWindow, IfcBuildingElementProxy
* with a specific "TestPset.TestProp"
* with value "Foo".
* Applicability 2:
* Remove from existing applicability all
* IfcBuildingElementProxy
* with "Attribute" "Name"
* with regex value: "Pyramid.*"
Is this currently (0.9) achievable with IDS?
Thank you for clarification and/or any pointers.
—
Reply to this email directly, view it on GitHub<#177>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABYIIJLHVOIWDIPOMLJOV53XSIANBANCNFSM6AAAAAA2ZSEICA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>
|
|
I quote form the enquiry below, seeking the implementation of Exceptions.
<< But the applicability steps seems to only append not subtract.(?) >>
Can I check if this is wrong? I expected that each entry in an Applicability list would progressively reducing the number of relevant entries. The message below suggests that it is acting as a Selection, progressively increasing the number of relevant entries.
Similarly I would expect that that each entry in an Requirement list would progressively make separate checks on relevant entries.
Where is the expected behaviour documented and is it clear enough?
Regards,
Nick.
Nicholas Nisbet FRSA MA(Cantab) DipArch(UNL)
Director: AEC3 UK Ltd
Direct: +44 (0) 1494 714 933
Mobile: +44 (0) 781 616 8554
***@***.***
Fellow Royal Society of Arts
Fellow buildingSMART International and buildingSMART UKI
Leader: buildingSMART International Regulatory Room
Vice-Chair: buildingSMART UKI Chapter
Member: UK BSI CB/5 Digitalization of the built environment and B555 Construction Information
Development of ISO 12006-2 on Classification structures and Breakdown structures
Development of ISO 19650-6 on Collaborative BIM for Health and Safety
Development of ISO 22014 on BIM library objects
Development of ISO 15686-3 Buildings and constructed assets - Service life planning: Part 3, Information and Calculations
********** Confidentiality Notice **********.
This e-mail and any file(s) transmitted with it, is intended for the exclusive use by the person(s) mentioned above as recipient(s). This e-mail may contain confidential information and/or information protected by intellectual property rights or other rights. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender and delete the original and any copies of this e-mail and any printouts immediately from your system and destroy all copies of it.
From: ay-ex ***@***.***>
Sent: 27 July 2023 07:06
To: buildingSMART/IDS ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [buildingSMART/IDS] subtract/exclude/remove from, for applicability? (Issue #177)
First of thank you for the amazing IDS mechanics, they are great for doing checks on IFC model quality. 🙂
One thing I was missing (or maybe just overlooked?) when reading through documentation and github issues
while creating rules for some of our projects, is the ability to subtract/exclude/remove something from applicability.
E.g.:
We would like to set the applicability to all elements of certain Ifc classes with a specific Pset.Property value,
then excluding the ones with a specific Name.
But the applicability steps seems to only append not subtract.(?)
Ideally it would possible to do the following:
* Applicability 1:
* Add all elements of
* IfcWall, IfcDoor, IfcWindow, IfcBuildingElementProxy
* with a specific "TestPset.TestProp"
* with value "Foo".
* Applicability 2:
* Remove from existing applicability all
* IfcBuildingElementProxy
* with "Attribute" "Name"
* with regex value: "Pyramid.*"
Is this currently (0.9) achievable with IDS?
Thank you for clarification and/or any pointers.
—
Reply to this email directly, view it on GitHub<#177>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABYIIJLHVOIWDIPOMLJOV53XSIANBANCNFSM6AAAAAA2ZSEICA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>
|
|
The current XSD pattern is not supporting this. |
|
I can see these kinds of 'composite' requirements will need some extra schema support - if we want to handle all the AND, OR, NOT boolean permutations in a future release... Presumably some kind of Grouping and Operator support in the schema - I'm not sure how a regex would cope!? Just on Nick's query on 0.9 schema, I've wondered the same thing:
My reading was that within a Requirements list the facets do refine. i.e. there's an implicit AND between facets on requirements. That seems to be the intent expressed in this test case fail-a_specification_passes_only_if_all_requirements_pass_1_2.ids i.e. For all Walls, the Name must be 'Waldo' AND the Description must be 'FooBar' So all checks have to be met on requirement facets to satisfy the overall requirement. On applicability lists, I couldn't find a test anywhere but my expectation is that multiple Applicability facets also refine the filter so more facets will produce fewer applicable matches (or never more). That's how we implemented in xbim, and seems in keeping with the examples in the developer documentation (e.g. "External load bearing walls need to have a fire rating property for code compliance" is clearly an AND in the Applicable facet)
For me, the Requirement behaviour seems generally well documented in the test cases. By comparison, the Applicability behaviour seems much less well defined. I'll open a separate issue for this - Feels like we need to get that right before we consider these more complex specifications! |
|
Back to the original question, how to implement:
... something like this might get close, but I'm not clear if cardinality can be used like that on Applicability facets: <specification>
<applicability>
<entity>
<name>
<simpleValue>IFCBUILDINGELEMENTPROXY</simpleValue>
</name>
</entity>
<property datatype="IfcLabel">
<propertySet>
<simpleValue>TestPset</simpleValue>
</propertySet>
<name>
<simpleValue>TestProp</simpleValue>
</name>
<value>
<simpleValue>Foo</simpleValue>
</value>
</property>
<property minOccurs="0" maxOccurs="0"> /* is this valid? */
<name>
<simpleValue>Name</simpleValue>
</name>
<value>
<xs:restriction base="xs:string">
<xs:pattern value="Pyramid.*" />
</xs:restriction>
</value>
</property>
</applicability>
/* and duplicate spec for Walls,Doors,Windows */ |
|
@berlotti Thank you for confirming it is currently not available. @andyward Thank you for the example and comments - fully agree. |
|
can't you split this into two specifications? Specification 1:
Specification 2:
? |
|
@berlotti thank you for your suggestion. Ideally we would be able to exclude the Pyramids from the applicability of specification 1. |
|
maxoccurs can work on the specification: 
|
|
@berlotti Thank you so much for the explanation! |
|
@berlotti I tried your approach with two specifications as I understood it from your suggestion with this ids: |
|
@andyward thank you for your suggested approach, which you seemed to have partly expected, judging by your comment. |
|
@ay-ex assuming this is ifcOpenShell's validator (which is not my area of expertise)? Try removing the minOccurs attribute from the property specification. I was writing the xml by hand, and minOccurs:0 is redundant when maxOccurs = 0. i.e. <property maxOccurs="0"> |
|
@andyward it is indeed. |
The specifications are independent (this makes it possible to select them from a library). |
|
@berlotti thank you for the explanation, then it is as I initially assumed. I have a model with ~1000 elements of Currently I cannot seem to be able to exclude the 6 pyramids, |
|
I suspect this is a relatively simple solution. Right now xs:occurs is only requirements. If we add xs:occurs to applicability, then we can treat Required as "filter applicable by matching this criteria" (current behaviour) and Prohibited as "filter applicable by not matching this critera" (i.e. the proposed subtraction). |
|
Closing and moving the discussion to the idea about exceptions: |
First of thank you for the amazing IDS mechanics, they are great for doing checks on IFC model quality. 🙂
One thing I was missing (or maybe just overlooked?) when reading through documentation and github issues
while creating rules for some of our projects, is the ability to subtract/exclude/remove something from applicability.
E.g.:
We would like to set the applicability to all elements of certain Ifc classes with a specific Pset.Property value,
then excluding the ones with a specific Name.
But the applicability steps seems to only append not subtract.(?)
Ideally it would possible to do the following:
Is this currently (0.9) achievable with IDS?
Thank you for clarification and/or any pointers.
The text was updated successfully, but these errors were encountered: