IDS
IDS copied to clipboard
buildingSMART
Applicability logic
Ok, so I'm trying out the IDS Checking in Solibri (9.13.6.15) and I don't seem to get the Applicability to work as expected... Below I expect the applicability-rule to pass only if it is an IfcFurnishingElement AND it has the specified PropertySet/Property/Value. Am I correct in thinking so? To make it clear, if it is an IfcFurnishingElement but it has the value UglyDesk instead, it should NOT pass, right?
<applicability>
<entity>
<name>
<simpleValue>IFCFURNISHINGELEMENT</simpleValue>
</name>
</entity>
<property>
<propertySet>
<simpleValue>Identity Data</simpleValue>
</propertySet>
<name>
<simpleValue>OmniClass Title</simpleValue>
</name>
<value>
<simpleValue>Desk</simpleValue>
</value>
</property>
</applicability>
Best regards, Mikael
To meet your expectation, the applicability should have entity is a ifcfurnishingelement only but the requirement should hold the pset name and property value. This then would verbalise as passing when “either it is not a furnishing elect or it has identity data with Omniclass code ‘desk’. This would be false for your ‘ugly desk’ .
The IDS you show verbalises as passing when either it is not a furnishing element or it does not have identity data with omniclass code ‘desk’. This is true for your ‘ugly desk’ .
Remember:
To fail, an instance is applicable and not as required .
To pass either an instance is not applicable or it is as required.
Pass = or ( notand(a1,a2, ….), and (r1,r2, ….)
Sent whilst away from my desk.
Regards,
Nick.
Nicholas Nisbet FRSA MA(Cantab) DipArch(UNL) Fellow: Royal Society of Arts Fellow: buildingSMART International & UKI Chapter Director: AEC3 UK Ltd Web: http://www.aec3.comhttp://www.aec3.com/ E-mail: @.@.> Direct: +44 (0) 1494 714 933 Mobile: +44 (0) 781 616 8554 Registered Address: 46 St Margaret's Grove, Great Kingshill, High Wycombe, Bucks, HP15 6HP, UK
Vice-Chair: buildingSMART UK Chapter Convenor: buildingSMART Regulatory Room
********** 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.
On 21 Dec 2023, at 00:26, jomijomi @.***> wrote:
EXTERNE-EMAIL Bitte klicken Sie nicht auf Links oder öffnen Sie keine Anhänge! Es sei denn, Sie kennen den Absender und wissen, dass der Inhalt sicher ist.
Ok, so I'm trying out the IDS Checking in Solibri (9.13.6.15) and I don't seem to get the Applicability to work as expected... Below I expect the applicability-rule to pass only if it is an IfcFurnishingElement AND it has the specified PropertySet/Property/Value. Am I correct in thinking so? To make it clear, if it is an IfcFurnishingElement but it has the value UglyDesk instead, it should NOT pass, right?
Best regards, Mikael
— Reply to this email directly, view it on GitHubhttps://github.com/buildingSMART/IDS/issues/229, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABYIIJPJANOP32QKYD3LECTYKN62FAVCNFSM6AAAAABA5TPGT2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2TCNBYGQYTANI. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Thanks for your quick reply Nick! However, I realize I perhaps wasn't clear enough in my explanation. I do have a requirement also that I want to check (if the applicability passes, so to say), but I left that snippet out as my main concern was with the applicability. So, in plain text I want to check a requirement, but I only want to check for that "IF the element is a IfcFurnishingElement AND it has this specific PropSet/Prop/Value".
As such, this example is more like "I want to check for the occurrence of a certain property, but I only want to check for that on load bearing walls", hence in my applicability I would then check both Entity being IfcWall AND the PropSet/Prop/Value being Pset_WallCommon/LoadBearing/True. In fact, some of the IDS templates at the BIMCollab site was my starting point and I found this kind of usage in some of the applicability sections (se below). However, still, my case with IfcFurnishingElement didn't seem to work. At least not in Solibri... So, that is why I wanted to understand if this was the right syntax/structure.
<applicability>
<entity>
<name>
<simpleValue>IFCWALL</simpleValue>
</name>
</entity>
<property>
<propertySet>
<simpleValue>Pset_WallCommon</simpleValue>
</propertySet>
<name>
<simpleValue>LoadBearing</simpleValue>
</name>
<value>
<simpleValue>True</simpleValue>
</value>
</property>
</applicability>
It's supposed to be an AND (intersect) between the facets. (See #181) But whether the test passes or fails will depend on the "Cardinality" on the specification (note: we're talking about the spec cardinality, not the facet cardinality).
Current understanding (based on #203):
If the spec is required (minOccurs=1) and there are no applicable "IfcFurnishingElements classed as Desks" it should fail (regardless of the requirement) - because there are no applicable items matching. If it's an optional spec (minOccurs = 0), then it will only fail if the requirements are not satisfied for any of the applicable items (if there are no applicable items it will pass) If it's prohibited (maxOccurs = 0), then the test fails if there are any matching applicable items - i.e. if there are "IfcFurnishingElements classed as Desks"
So to answer we'd need to see the full spec. In your example it could pass if you only have UglyDesks and the spec is optional.
In fact, some of the IDS templates at the BIMCollab site was my starting point
Worth noting the IDS at https://download.bimcollab.com/Support/EN_Basic%20IDM%20Check.ids doesn't seem to adhere to the latest IDS 0.96 schema. If you run through a validator (e.g. the ids-tool or https://www.xbim.it/ids) it will flag up a number of issues. In particular that IDS doesn't specify any facet cardinalities, and the Attribute names being in UPPERCSASE may cause issues.
A further edge case is that it seems to expect that IDS simpleValues can contain wildcard patterns, which is not behaviour I've seen documented.
e.g. The use of "Type ??.*" in a simpleValue seems wrong here:
<applicability>
<entity>
<name>
<simpleValue>IFCDOOR</simpleValue>
</name>
</entity>
</applicability>
<requirements>
<attribute>
<name>
<simpleValue>NAME</simpleValue>
</name>
<value>
<simpleValue>Type ??.*</simpleValue>
</value>
</attribute>
</requirements>
... if the requirement is that Doors be named like this:
This would need to be a pattern constraint to work as expected across implementors.
Lastly, the use of this applicability is a bit of a workaround for the fact IDS doesn't yet support entity inheritance.
<applicability>
<attribute>
<name>
<simpleValue>GLOBALID</simpleValue>
</name>
</attribute>
</applicability>
It's basically saying, this applies to all elements descended from IfcRoot. It's novel, and because of that it may not be supported by all implementors (and kind of makes the case that we need entity inheritance/sub-typing)
Not sure who from Kubus/BIMCollab is on the project but hopefully they can chip in?
It would be good to add such multi-facet conditions to IDS/Documentation/testcases both for applicability and requirements
I am currently battling with writing the buildingSMART Sustainability IDS standard without it becoming tediously long and unmanageable:
I believe that there is a need for
- a Selection section listing alternative facets about being included (for example like IfcDoor and IfcWindow) and
- an Exception section listing cases which are not relevant (for example like IfcOpening or IfcSpace).
- And also sub-clauses.
This gives expressiveness exactly equivalent to First Order Logic but with the current clear structure extended (as in Xtensible Markup Language) to cover more powerful cases for IDS2.
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: I-Sokolov @.> Sent: 21 December 2023 11:44 To: buildingSMART/IDS @.> Cc: Nicholas Nisbet @.>; Comment @.> Subject: Re: [buildingSMART/IDS] Applicability logic (Issue #229)
EXTERNE-EMAIL Bitte klicken Sie nicht auf Links oder öffnen Sie keine Anhänge! Es sei denn, Sie kennen den Absender und wissen, dass der Inhalt sicher ist.
It would be good to add such multi-facet conditions to IDS/Documentation/testcases both for applicability and requirements
— Reply to this email directly, view it on GitHubhttps://github.com/buildingSMART/IDS/issues/229#issuecomment-1866110057, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABYIIJMHE3QU6SZ4DWDIAX3YKQOG5AVCNFSM6AAAAABA5TPGT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRWGEYTAMBVG4. You are receiving this because you commented.Message ID: @.@.>>
Hi @NickNisbet, help me better understand the ideas you propose:
- a Selection section listing alternative facets about being included (for example like IfcDoor and IfcWindow) and
- an Exception section listing cases which are not relevant (for example like IfcOpening or IfcSpace).
The IDS1.0 allows for listing many entities so you can ask for IfcDoor OR IfcWindow in one specification, so selection is there. The exceptions would only be needed if we would have inheritance, but the group agreed to list all entities explicitly, so if applicability asks for IfcBuiltElement then the IfcWall is not applicable. Or am I missing something? Of course this is what the XML file stores to avoid ambiguity, but the software interface can show "Built element" instead of 30+ child classes.
- And also sub-clauses.
Do you mean, for example, "applies to IfcDoors of type GATE or IfcWindows of type SKYLIGHT"? At the moment this needs to be split into two separate specifications (in one IDS file). If that's not it, can you provide an example?
Everything should be done to eliminate duplication and repetition in IDS files. Conciseness is the most important factor in getting sign-off and engagement from senior and junior stakeholders.
The suggestions below allow for situations where the 'entity' facet is not the only criteria being used. Increasingly, other facet types are becoming more important. Suggestion 1:
A Selection section listing alternative facets about being included * for example: IfcDoor and IfcWindow * for example: objects having a material set or having a model-label set * for example: objects in CISfB 21 or Uniclass Pr_20 * for example objects with volume > 0.01m3 or netarea > 0.1m2
Selections allow for alternative criteria for inclusion, making a 'specification' . Facets in a Selection operate as 'notor' whereas facets in an Application operates as 'notand'. The Selection section sits alongside the Application and Requirements sections.
Suggestion 2:
an Exception section listing cases which are not relevant * for example: exclude IfcOpening . * for example: exclude objects having a material set * For example: exclude objects having Uniclass Pr_20
Exceptions help make general understandable rules practical by excluding edge cases (of which IFC has many). Yes, if entity inheritance worked this would be doubly powerful, and the generation of the IDS for Sustainability and for Regulatory information had to include complex workarounds. Facets within the Exception section operate as 'or' whereas Facets within Requirement operate with 'and' . The Exeption section sits alongside the Selection, Application and Requirements sections. Suggestion 3: Allow sub-clauses. Specifically: allow 'Specification' as an additional type of Facet. This makes the IDS logically complete. This should also reduce the dependence on wildcarding and complex facet syntaxes a. Example:
Specification * Application * Specification * entity IfcDoor * property PredefinedType GATE * Specification * Entity IfcWindow * Property PredefinedType SKYLIGHT * Requirement * Property PrimeCost (required)