IfcTask diagram needs updating as IfcCalendarDate does not exist

[Moult]

Originally https://forums.buildingsmart.org/t/ifctask-diagram-needs-updating/3576

In the below diagram, IfcCalendarDate no longer exists and should be removed.

[TLiebich]

here an updated figure, also tried to improve the values using the correct ISO6801 notation. However, in the new spec the figure is completely missing

compare IFC4 with IFC4.3 documentation

[Moult]

Ping @aothms the diagram isn't showing up because the concept doesn't exist.

[aothms]

The issues

There's several issues at play here:

(a) Usage naming does not correspond to template name

Nesting

The Object Nesting concept applies to this entity.

Apparently in mvdXML there is the ability to name a usage differently from the name of the concept. When importing we have apparently assigned the description to the wrong label. Nesting instead of Object Nesting.

(b) Inconsistent parametrizations

We have made concept parametrization within a template consistent among adopting entities. We already discussed this earlier. But a concept is either:

• unary: e.g axis representation
• binary: e.g pset association to element or predefined type
• n-ary e.g port nesting, complex usage

There are small variations on whether the association is directed or not, but fundamentally this is what we have.

This means that existing parametrizations that are inconsistent have been dropped in the UML model, but may still have documentation in the Markdown. For example:

Spatial Composition

We see here that a IfcBridge can be part of (Project,Site,Bridge) and a IfcFacilityPart can be part of ... something. This will have to be fixed in UML. We have chosen for this template to be encoded in a binary form. That means that the unary statements in this table need to be converted to binary e.g IfcFacilityPart (if it still exists...) can be part of (IfcSpatialStructureElement,). These manual adjustments have not been made yet. NB Spatial Composition does still need to be modelled anyway after the changes in this repo!!

(c) Human readable parametrizations

What's even worse there are also usages without a computer readable parametrization and in case of Object Nesting this is also inconsistent.

with parametrization

without parametrization

Note that absence of a DocTemplateItem. In the case of Object Nesting apparently IfcEvent, IfcTask, IfcProcedure IfcTaskType IfcWorkSchedule are without computer interpretable binding.

Apparently these definitions without a computer interpretable binding have been lost in the process (I have implemented a IfcDoc to mvdXML converter and mvdXML to UML converter). Not 100% intentionally, but with mvdXML being touted as a computer interpretable format, it's also not crazy that the solely human readable template usages got lost in their migration to UML.

The way out.

(🗸) As suggested on Slack I'm going to provide the cross-referencing between Markdown and UML using SHACL and flag the discrepancies. That's the good thing that we have two sources. This is also a nice prioritization because the usages with extensive human readable parametrization are a good initial attack vector. Done https://github.com/buildingSMART/IFC4.3.x-development/commit/6b3eed9d0de17986b1c2740e802bb2b7a4cf7521

(b) I will also create a listing of all usages without computer interpretable parametrization and a list of usages that do not conform to the prevalent encoding form. In most cases these are not shocking. For example seen in the listing below, where only IfcOpeningStandardCase is parametrized differently, but it's deprecated.

Or in the case below where Annotation and Geomset are selected, but these are actually explicit subtemplates already of FootPrint Geometry, so should have been parametrized there.

(c) Worthwhile nonconforming parametrization will be migrated to the prevalent parametrization form.

[aothms]

I've now made progress with recovering entries for the solely human readable concepts. That means we can compare the parametrization output. Either (a) diff output from before feb 2022 to after feb 2022 to or (b) look at gaps in columns. For example for MLS-usage we see the list extended with the items that are missing in UML but are represented in Md.

Example: Material Layer Set Usage parametrization

Computer readable (prior to feb 2022)

Computer readable and human readable (after feb 2022)

The question then remains how to unify this. Because the template usage is in fact facilitating two different use cases:

1. On the one hand nominating valid material layer names for certain entities. E.g IfcDuctFitting -> {Casing, Coating, Insulation, Lining}
2. On the other hand documenting the geometric procedure to align the MLS geometrically to the representation items in the element

For 1. it seems like this usage is misplaced and should probably be unified with the concept MaterialConstituentSet (which also aims at providing labels for the various material parts) into something like MaterialLabelsForElements. Regardless of whether you decompose an element into constituents or layers you should pick from the same set of labels.

(MaterialConstituentSet concept broken too though, because on the one hand because it references a Identification called Name=... where in fact we have Identification="MaterialName" and Identification="ConstituentName")

[Moult]

Ok that was mindnumbingly boring but thank goodness it's over.

I'll take a closer look tomorrow to see what the actual impact was. I suppose I need to write some code to actually take advantage of the level 4 headings otherwise they don't do anything.

I'm still a bit suspicious - IfcTask doesn't have object nesting (see your screenshot for issue type "a"), are you sure it was the right move to rename "Nesting" to "Object Nesting"? Perhaps IfcTask also needs to have the object nesting concept added in UML?

[aothms]

Ok that was mindnumbingly boring but thank goodness it's over.

🙏

IfcTask doesn't have object nesting

The instantiated template is really Object Nesting. See the DocTemplateUsage/Definition[href] But indeed it doesn't have an DocTemplateItem, so you don't know what an IfcTask can be nested with. So we need to complete the table in the xlsx and remodelled in UML.

code to actually take advantage of the level 4 headings otherwise they don't do anything.

When we still had the tables, we had this incomprehensible code for it [0]. But the situation has improved slightly. The Md parser is now much more a general tree, in this case specifically you can ask md.py for the "children" of a level 3 heading [1] which will give you a list of markdown_section [2]

[0] https://github.com/buildingSMART/IFC4.3.x-development/commit/3562964534e5f75bc5788426dc4e0b62d1f9f753#diff-1f6dfaec2163372691fdb1ee1aebff3bd43b0840944919ecf4c56d16691e91a6R730-R748 [1] https://github.com/buildingSMART/IFC4.3.x-development/blob/master/code/md.py#L111-L113 [2] https://github.com/buildingSMART/IFC4.3.x-development/blob/master/code/md.py#L15

[Moult]

Ah nice I also see the QA scripts have caught it:

The concept usage 'Object Nesting' for entity 'IfcTask' in MVD 'GeneralUsage' is not modeled in UML