Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Applicability logic #229

Open
jomijomi opened this issue Dec 21, 2023 · 6 comments
Open

Applicability logic #229

jomijomi opened this issue Dec 21, 2023 · 6 comments

Comments

@jomijomi
Copy link

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
@NickNisbet
Copy link

NickNisbet commented Dec 21, 2023 via email

@jomijomi
Copy link
Author

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
Copy link
Contributor

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
Copy link
Contributor

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:
image

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
Copy link
Contributor

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

@NickNisbet
Copy link

NickNisbet commented Dec 21, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@andyward @I-Sokolov @NickNisbet @jomijomi