Applicability logic about ids

[NickNisbet]

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.com<http://www.aec3.com/> E-mail: ***@***.******@***.***> Direct: [phone] Mobile: [phone] 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? <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 — Reply to this email directly, view it on GitHub<#229>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABYIIJPJANOP32QKYD3LECTYKN62FAVCNFSM6AAAAABA5TPGT2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2TCNBYGQYTANI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jomijomi]

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>

[andyward]

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.

[andyward]

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?

[I-Sokolov]

It would be good to add such multi-facet conditions to IDS/Documentation/testcases both for applicability and requirements

[NickNisbet]

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 1. a Selection section listing alternative facets about being included (for example like IfcDoor and IfcWindow) and 2. an Exception section listing cases which are not relevant (for example like IfcOpening or IfcSpace). 3. 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: [phone] Mobile: [phone] ***@***.*** 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 GitHub<#229 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABYIIJMHE3QU6SZ4DWDIAX3YKQOG5AVCNFSM6AAAAABA5TPGT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRWGEYTAMBVG4>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>