Connection to materials (and profiles?)

[CBenghi]

It has come to my attention that Properties can be associated to objects other than IFCOBJECT or IFCOBJECTDEFINITION via instances of classes such as IfcMaterialProperties (see https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcMaterialProperties.htm)

Should we consider those paths valid for 1.0?

@atomczak, would you care to contribute to this discussion? You might have a number of use cases to support them in the verification of models, the counter-argument being implementation ease, of course.

Thanks, Claudio

[aothms]

In our implementation in ifcopenshell we already do.

I think it was also more or less the aim of working on a higher level of abstraction in IDS, so that these kind of idiosyncrasies and inconsistencies in the schemas can be uniformly addressed in IDS.

It is a very much a bit messy though, because for example quantities cannot be associated to materials and profiles.

Maybe also a moment to bring up the IfcPredefinedPropertySets https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcPreDefinedPropertySet.htm again, now mostly deprecated since IFC4X3_ADD2, except for 1 because it is too complex to represent in a conventional pset :(

I think neither of these have to be a priority though. If speccing this all out gets too messy I think we can safely say we defer it to e.g 1.1 because I'm pretty sure it can be added in a backwards compatible manner.

[Moult]

Psets can also be assigned to tasks, resources, material layers / material profiles, or material layer sets / profile sets ... etc.

We currently support all of these. I see no reason why it shouldn't be supported? For example properties on profiles / materials are critical for structural analysis.

[atomczak]

I agree, there are many use cases based on checking properties assigned to materials, tasks, etc. The whole field of BIM-based life-cycle assessment (LCA) relies on properties assigned to materials (ISO22057 is dedicated to EPD in BIM). I spoke yesterday with a general contractor who needs to review and accept material declarations, a process currently based on PDFs. He asked if he could receive and check all of that automatically with IDS.

Here is a sample IDS validating property of IfcMaterial, and I think it should be a valid IDS:

<ids:specification ifcVersion="IFC4X3" name="Material data quality" minOccurs="0" maxOccurs="unbounded" identifier="#1" description="Check that materials have expected properties and with reasonable values.">
    <ids:applicability>
        <ids:entity>
            <ids:name>
                <ids:simpleValue>IFCMATERIAL</ids:simpleValue>
            </ids:name>
        </ids:entity>
    </ids:applicability>
    <ids:requirements>
        <ids:property minOccurs="1" maxOccurs="unbounded" datatype="IFCMASSDENSITYMEASURE">
            <ids:propertySet>
                <ids:simpleValue>Pset_MaterialCommon</ids:simpleValue>
            </ids:propertySet>
            <ids:name>
                <ids:simpleValue>MassDensity</ids:simpleValue>
            </ids:name>
            <ids:value>
                <xs:restriction base="xs:integer">
                    <xs:minExclusive value="0"/>
                    <xs:maxExclusive value="9999"/>
                </xs:restriction>
            </ids:value>
        </ids:property>
    </ids:requirements>
</ids:specification>

[CBenghi]

We need to be explicit about all the relations that allow the assignment of properties. This will probably differ from one version of the IFC schema to another.

There are some implications on the auditing tool as well.

Right now the auditing expects properties to be compatible with a limited set of entities (based on IfcRelDefinesByProperties):

• IfcObject for ifc2x3
• IfcObjectDefinition for Ifc4
• IfcObjectDefinition for ifc4x3

We can extend it with the following:

• ifc2x3
  • https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/ifcmaterialpropertyresource/lexical/ifcextendedmaterialproperties.htm
  • How do we connect to psets?
• ifc4
  • https://standards.buildingsmart.org/MVD/RELEASE/IFC4/ADD2_TC1/RV1_2/HTML/schema/ifcpropertyresource/lexical/ifcextendedproperties.htm (new in 4)
  • this is abstract, its only subclass is ifcmaterialproperties (pointing to IfcMaterialDefinition)
• ifc4x3
  • https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcExtendedProperties.htm
  • two subclasses for materials (pointing to IfcMaterialDefinition) and profiles (pointing to IfcProfileDef)

What other relations should be included?

[MatthiasWeise]

Can you be more specific about the agreements for checking material and profile properties? I am specifically concerned about applicability settings. The example from @atomczak defines IfcMaterial in the applicability. Is it also allowed to use building elements like IfcWall (IfcWall -> IfcMaterial -> Material Property)?

[pjanck]

He asked if he could receive and check all of that automatically with IDS. Here is a sample IDS validating property of IfcMaterial, and I think it should be a valid IDS:

I'm wondering about the reporting of failure for such example. IfcMaterial has no GlobalID and does not know about the product it is assigned to, thus it is impossible to produce a BCF issue. How to proceed here @atomczak ?

[Moult]

@MatthiasWeise a property facet only checks properties of that the element (i.e. itself, or inherited by its type if it has one). It does not check properties of the materials of the element.

@pjanck BCF does not require a GlobalID so this is not a problem. You can apply an IDS requirement to any non-rooted class. BCF is also not the only report format.

[pjanck]

Psets can also be assigned to tasks, resources, material layers / material profiles, or material layer sets / profile sets ... etc. We currently support all of these. I see no reason why it shouldn't be supported? For example properties on profiles / materials are critical for structural analysis.

with

Here is a sample IDS validating property of IfcMaterial

vs.

a property facet only checks properties of that the element (i.e. itself, or inherited by its type if it has one). It does not check properties of the materials of the element.

seems contradictory. I think I am missing something here. @Moult Which facet can be used to check material properties, if not the one presented in the example of @atomczak ?

[Moult]

@pjanck no contradiction, just perhaps a misreading. @MatthiasWeise asked this:

Is it also allowed to use building elements like IfcWall (IfcWall -> IfcMaterial -> Material Property)?

And so I answered that no, a property facet will not traverse an assigned material to check properties of that material.

[MatthiasWeise]

@Moult Thanks for clarification! I was asking because IDS is meant to have a higher level of abstraction as pointed out by @aothms. Therefore, I was wondering if such traverse interpretation would be useful in some cases, e.g. asking for Pset_MaterialMechanical properties for load bearing elements only.

[atomczak]

@pjanck, in my example, the point is not to check material belonging to a particular element, just any material in the model. That is/should be possible with IDS, and as @Moult explained, you can report such issues with BCF.

[MarcelStepien]

There is also the connection to IfcMaterialUsageDefinition via the IfcMaterialSelect class hierarchy. In our tests with the material facet we discovered that some prominent software vendors prefer the material export using these entities. It may be good to simply list the options the material face is conceived for and how the material associations should be interpreted in general.

[atomczak]

I assume all the possible associations between an element and IfcMaterial should be checked, when someone specifies the material facet in an IDS. I tried capturing all the alternatives here:

[MatthiasWeise]

@atomczak Great overview, it very nicely shows all the options for defining material! If all agree on that interpretation, it should be added to the documentation of the material facet.

[andyward]

Just FYI, I think the test cases cover pretty much all those scenarios pretty well (although maybe not exhaustively across all permumtations). So 👍 to those who created them.

The one exception is the IfcBuildingElementPart via RelAggregates route. I must admit I think we overlooked that aspect for IDS in our validator.

Question: Presumably that traversal of IfcRelAggregates should also take place on other facet types, such as Classifications and maybe even Properties? Is this documented anywhere?

[aothms]

The one exception is the IfcBuildingElementPart via RelAggregates route. I must admit I think we overlooked that aspect for IDS in our validator.

Question: Presumably that traversal of IfcRelAggregates should also take place on other facet types, such as Classifications and maybe even Properties? Is this documented anywhere?

I don't think we should go as far. I would propose to exclude evaluation of IfcRelAggregates relatedobjects in any facet:

• It makes it a lot harder for downstream applications to find where information is specified.
• It further complicates any vs all semantics.
• Users already can be more explicit about this with partOf

[andyward]

I don't think we should go as far. I would propose to exclude evaluation of IfcRelAggregates relatedobjects in any facet

Yes, that makes sense for me. Agree on all the points.

Putting this into a real world example, IfcStairs and StairFlights are probably a common scenario we can use to test the hypothesis.

[NickNisbet]

Colleagues,

I am playing catch-up but can I ask some naïve questions?

1. What (where?) are the implementers agreements and why are they not included in the XSD, at least as annotations? Error 301: Invalid configuration for IDS implementation agreements

2. Why are new properties rejected ? Surely IDS isn’t only for official properties?

Error 103: Invalid property name DateOfConstruction

1. Why are valid property-set names being rejected?

Error 401: Reserved prefix 'Pset_' for property set name (Pset_ManufacturerTypeInformation)

On the positive side, we are close to having Sustainability IDS definitions for any Facility, for any Product, and later in the year for any EPD (Environmental Product Declarations).

Regards,

Nick.

[CBenghi]

Hi @NickNisbet,

The road to making the initial draft into an operational format has taken quite a lot of detours. In November and December last year we have gone through a thorough revision of the schema and I'm now working on rewriting the documentation and the samples in light of those changes.

I'll be presenting an updated document this Friday in the call (I'll send out the invite today).

May I ask you to rewrite the questions in independent issues and add ids snippets to help understand your questions better?

[NickNisbet]

What (where?) are the implementers agreements and why are they not included in the XSD, at least as annotations? Error 301: Invalid configuration for IDS implementation agreements Invalid cardinality on 'property' element at line 182, position 10.

Pset_BuildingCommon YearOfConstruction I’ve added these but the XSD does not make them mandatory. In fact it disallows them. Regards, Nick.

[CBenghi]

As mentioned, the documentation is improving and gonna be presented this Friday.

In the new schema minOccurs and maxOccurs are replaced with a cardinality attribute for the facets.

Please note that the new schema (0.9.7), which is available as PR at https://github.com/buildingSMART/IDS/pull/240

Or in the original repository at: https://github.com/CBenghi/IDS/blob/facetsReview/Development/ids.xsd

[NickNisbet]

@NickNisbet this issue is about materials. Property questions should be in a new issue

[EDIT] Moved to : https://github.com/buildingSMART/IDS/issues/241

[CBenghi]

@NickNisbet this issue is about materials, you should create new issues for unrelated matters.

I've moved your content to: #241