Complete IDS by adding two more sections and recursion

[NickNisbet]

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 Exception 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)

Each Specification is performing a role, Application in this case). The main Specification set is always playing the role of Requirement.

[atomczak]

For context, the topic was previously raised in Issues:

• Applicability logic #229
• subtract/exclude/remove from, for applicability? #177
• [Question] Can you set two requirements with some kind of OR in Requirements? #183

Let's continue the discussion here.

In my opinion:

• Suggestion 2: some form of 'exceptions' would add value to IDS, lowering reliance on regex patterns. For example "applies to all beams except those with steel as material".
• Suggestions 1 and 3: As of IDS.1.0, this can be addressed by splitting into multiple specifications or using the regex patterns in applicability, not ideal. However, instead of 'selection' and 'sub-classes' I think this can be addressed easily with the "or" logic as raised in [Question] Can you set two requirements with some kind of OR in Requirements? #183.

[NickNisbet]

I suggest that 'splitting into multiple specifications' is detrimental to the development and acceptance of information requirements. You only need three such issues to increase the size of an IDS by almost an order of magnitude. Just injecting 'or' into the sequence of facets (between facets or as an attribute of a facet) causes huge ambiguity:       facet1 facet2 or facet3 facet4 Could mean for requirements       (facet1 and facet2) or (facet 3 and facet4) Or it could mean       (facet1 and (facet2 or facet3) and facet4) For applicability, it gets harder:       facet1 facet2 or facet3 facet4 Could mean for applicability       not (facet1 or facet2) and not (facet 3 or facet4) Or it could mean       not (facet1 or (facet2 and facet3) or facet4) The Sustainability example has * (volume>0.01m3 or netarea>0.1m2) So we had to give up on * (has material or has model-label) The keyword for applicability is 'notand', for requirement is 'and', for exception is 'or' and for selection is 'notor'. The four cases are joined by 'or'. << * Suggestions 1 and 3: As of IDS.1.0, this can be addressed by splitting into multiple specifications or using the regex patterns in applicability, not ideal. However, instead of 'selection' and 'sub-classes' I think this can be addressed easily with the "or" logic as raised in #183<#183>.

…

[Moult]

I think we agree that using and/or without brackets is ambiguous.

An alternative to brackets is the strategy I've implemented in IfcOpenShell's syntax. The rules are simple:

1. Facets exist in groups. Groups of facets are equivalent to "OR".
2. Facets are chained together. E.g. they filter the results of the previous facet. (i.e. AND)
3. Facets can be negated to get the inverse of that facet.

https://docs.ifcopenshell.org/ifcopenshell-python/selector_syntax.html#filtering-elements

This is something that's continuously battle tested and used for all sorts of scenarios, and so far it holds up really well - certainly whenever I come across an "oh IDS can't do this" situation, the selector syntax can handle it - and it's not too different from IDS.

What are the chances of something like this being adopted for a future version of IDS? It's concise, readable, but more importantly: tried and tested in complex, real world requirements, auditing, and filtering for all sorts of usecases (clashes, data spreadsheet exports, model comparison, drawing generation filtering...)

[dgb2023tops]

Hi,
I'm a newbie to IDS, but I'm a true believer in its benefits.
But from what I have read, it would appear relevant based on the above reference, #177, to raise a question concerning my need to exclude elements from a specification's applicability.

Can I use the 'PartOf' facet to exclude any element that is part of an IfcRelAggregate association via IfcElementAssembly?
In other words, I'd like to specify a check on IfcElements in my IDS but exclude any element that is part of an IfcElementAssembly via an IfcRelAggregate relationship.

Is using the PartOf facet via applicability capable of this type of arrangement?
My plain English description:

I want to check this, but not these that are PartOf that :).

Thank you in advance for any assistance offered in reply.

[Moult]

Just voicing my support for this. 100% agree with the ability to handle "sub-clauses" in applicability (IfcOpenShell calls this a filter group), and 100% agree to add the ability to negate, exclude, or "except" facets. Those two in itself would make IDS writing much simpler.