Missing concept action plan

[aothms]

Aggregation

• The concept usage 'Aggregation' for entity 'IfcActionRequest' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Aggregation' for entity 'IfcController' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Aggregation' for entity 'IfcElementAssembly' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Aggregation' for entity 'IfcPerformanceHistory' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Aggregation' for entity 'IfcProjectOrder' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Aggregation' for entity 'IfcSlabElementedCase' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Aggregation' for entity 'IfcWorkSchedule' in MVD 'GeneralUsage' is not modeled in UML

Two issues here:

• One, we're referring to a parent concept without a parametrization https://github.com/buildingSMART/IFC4.3.x-development/issues/118
• Two, IfcElementAssembly IfcSlabElementedCase (2nd removed, so not relevant). Should use the child concepts. Element (De)composition.

Solution:

• [x] @Moult Move Aggregation block in Markdown from IfcXElementCase to IfcX
• [x] @Moult (optional, but I'd we should) Create concept diagram for Aggregation concept
• @aothms Parametrize Aggregation concept with (IfcActionRequest IfcAudioVisualAppliance IfcBuildingSystem IfcCableSegment IfcChiller IfcCommunicationsAppliance IfcController IfcCoolingTower IfcDistributionSystem IfcElectricGenerator IfcElementAssembly IfcFurniture IfcPerformanceHistory IfcPermit IfcProjectOrder IfcSlabElementedCase IfcStructuralAnalysisModel IfcUnitaryEquipment IfcWorkSchedule) minus IfcElement subtypes
• [x] well let's say we just open up this template to the applicable entity and remove parametrization from UML
• [ ] @aothms Add IfcElement subtypes above to Element (De)composition
• [ ] @TLiebich (optional, but I'd we should) Revise "Aggregation" text http://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Object_Composition/Aggregation/content.html to better reflect usage in scheduling domain and maybe remove the note that Aggregation about bidirectional concept because it seems to imply Aggregation in itself should not be used.

Axis 2D Geometry

• The concept usage 'Axis 2D Geometry' for entity 'IfcCurtainWall' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Axis 2D Geometry' for entity 'IfcRamp' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Axis 2D Geometry' for entity 'IfcRampFlight' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Axis 2D Geometry' for entity 'IfcStair' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Axis 2D Geometry' for entity 'IfcStairFlight' in MVD 'GeneralUsage' is not modeled in UML

Solution:

• [x] @aothms Somehow simply missing in UML. Hopefully fixed by the time you read this.

Body Geometry

• The concept usage 'Body Geometry' for entity 'IfcBridge' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcBridgePart' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcBuilding' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcBuildingStorey' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcFacility' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcFacilityPart' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcOpeningElement' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcOpeningStandardCase' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcProjectionElement' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcReinforcingBar' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcReinforcingMesh' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcSite' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Body Geometry' for entity 'IfcTendon' in MVD 'GeneralUsage' is not modeled in UML

Issues:

• Somehow the choice was made not to import this into UML. Can't recall the reason other than that I probably found this list too selective and hence insignificant. Everything can have a body geometry so no sense to parametrize this. Let's just assign this template to all subtypes of Ifc... (read below)
• Most of these are not an IfcElement The applicable root of this concept has to be changed to IfcProduct

Solution:

• [x] @aothms Change mode of this template to not be UML driven but applicable root driven
• [x] @Moult Change template root to IfcProduct

Body Tessellation Geometry

• The concept usage 'Body Tessellation Geometry' for entity 'IfcElement' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• No issue. This is a false positive.

Solution:

• [ ] @aothms Investigate

Classification Association

• The concept usage 'Classification Association' for entity 'IfcAsset' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Classification Association' for entity 'IfcCostItem' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Classification Association' for entity 'IfcDistributionControlElement' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Classification Association' for entity 'IfcGeographicElement' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Classification Association' for entity 'IfcObjectDefinition' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Classification Association' for entity 'IfcPerformanceHistory' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Classification Association' for entity 'IfcTask' in MVD 'GeneralUsage' is not modeled in UML

Issues:

• According to @Moult the usage above is not intended use of classification. Is there parametrization for this concept necessary?

Solution:

• [x] @Moult to propose solution.

Constraint Association

• The concept usage 'Constraint Association' for entity 'IfcConstructionResource' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Constraint Association' for entity 'IfcTask' in MVD 'GeneralUsage' is not modeled in UML

<Concept uuid="cb18b04b-641f-430e-a8ee-12050db80d00" name="Constraint Association" status="sample" override="false">
    <Template ref="c08b264c-f7c6-479f-af7f-5d645c130ea8"/>
    <Definitions>
        <Definition>
            <Body>Constraints may be applied to a resource to indicate fixed work (such as total person-hours) or fixed usage (such as simultaneous workers).</Body>
        </Definition>
    </Definitions>
    <Template ref="c08b264c-f7c6-479f-af7f-5d645c130ea8"/>
    <TemplateRules operator="and">
        <TemplateRule Description="Indicate fixed usage (such as simultaneous workers) such that changes to ScheduleWork should impact the assigned IfcTask.TaskTime.ScheduleDuration and vice-versa." Parameters="DataValue=IfcPositiveRatioMeasure;Attribute1=Usage;Attribute2=ScheduleUsage;"/>
        <TemplateRule Description="Indicate fixed work (such as total person-hours) such that changes to ScheduleUsage should impact the assigned IfcTask.TaskTime.ScheduleDuration and vice-versa." Parameters="DataValue=IfcDuration;Attribute1=Usage;Attribute2=ScheduleWork;"/>
    </TemplateRules>
</Concept>

<Concept uuid="216de181-6d09-4242-8fd5-42b11dfa2c15" name="Constraint Association" status="sample" override="false">
    <Template ref="c08b264c-f7c6-479f-af7f-5d645c130ea8"/>
    <Definitions>
        <Definition>
            <Body>Constraints may be applied to a task to indicate fixed task duration, fixed start or fixed finish, where _IfcMetric_.ReferencePath is set to the corresponding attribute on the _IfcTaskTime_ entity.</Body>
        </Definition>
    </Definitions>
    <Template ref="c08b264c-f7c6-479f-af7f-5d645c130ea8"/>
    <TemplateRules operator="and">
        <TemplateRule Description="Indicate fixed duration of task with ConstraintGrade=HARD and Benchmark=EQUALTO such that changes to an assigned _IfcConstructionResource.ResourceTime.ScheduleWork_ should impact _IfcConstructionResource.ResourceTime.ScheduleUsage_, and vice-versa." Parameters="Constrained Attribute=TaskTime.ScheduleDuration;"/>
        <TemplateRule Description="Indicate constrained start date with ConstraintGrade=HARD and Benchmark of EQUALTO, GREATERTHANOREQUALTO, or LESSTHANOREQUALTO to indicate &quot;must start on&quot;, &quot;start no earlier than&quot; or &quot;start no later than&quot; respectively where _IfcMetric.DataValue_ indicates the specific _IfcDateTime_. Use SOFT constraint having LESSTHAN benchmark to indicate &quot;start as soon as possible&quot;." Parameters="Constrained Attribute=TaskTime.ScheduleStart;"/>
        <TemplateRule Description="Indicate constrained finish date with ConstraintGrade=HARD and Benchmark of EQUALTO, GREATERTHANOREQUALTO, or LESSTHANOREQUALTO to indicate &quot;must finish on&quot;, &quot;finish no earlier than&quot; or &quot;finish no later than&quot; respectively where _IfcMetric.DateValue_ indicates the specific _IfcDateTime_. Use SOFT constraint having GREATERTHAN benchmark to indicate &quot;finish as late as possible&quot;." Parameters="Constrained Attribute=TaskTime.ScheduleFinish;"/>
    </TemplateRules>
</Concept>

Issues:

• Sorry I don't really know what to make of this? Is this normative? It seems like just some sort of examples? The ParameterRule on Constrained Attribute= does not relate to a defined term it seems.
• It's probably also that the validation fails to recognize the parametrization as it does exit.

Solution:

• [x] @Moult Given that the examples relate to scheduling, please propose something.
• [ ] @aothms To look into validation issue.

Control Assignment

• The concept usage 'Control Assignment' for entity 'IfcActionRequest' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Control Assignment' for entity 'IfcControl' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Control Assignment' for entity 'IfcCostSchedule' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Control Assignment' for entity 'IfcPermit' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Control Assignment' for entity 'IfcProjectOrder' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Control Assignment' for entity 'IfcWorkCalendar' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Control Assignment' for entity 'IfcWorkControl' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Control Assignment' for entity 'IfcWorkSchedule' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• Inconsistent parametrization in mvdXML.

Solution:

• [x] @Moult Since this is bout scheduling please propose something. Is parametrization for this concept necessary? What's the rows with only applicability version the ones with two columns?

Element Nesting

• The concept usage 'Element Nesting' for entity 'IfcJunctionBox' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Element Nesting' for entity 'IfcSanitaryTerminal' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• You're not going to tell me these are the only two things that can be nested.

Solution:

• [x] @aothms remove parametrization on this concept and open up for all subtypes of IfcElement
• [x] @Moult Check wording in these two above cases to be sure it's exemplary

Group Assignment

• The concept usage 'Group Assignment' for entity 'IfcGroup' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• I think this is a versioning thing. That simply Groups of groups was conceived after I did the import. I recall some discussion.
• But I'm not happy with the concept as it stands. The concept now is IfcGroup -> IfcRel -> IfcProduct. This is wrong in two ways (a) I think it should be reversed (b) the entity on the right now should not be IfcProduct (IfcGroup isn't an IfcProduct) but IfcObject probably.

Solution:

• ? ~reverse template~. I see this is the same for the other assignment concepts as well. Let's keep as is then. It violates the idea the applicable (parametrizable) entity is on the left, but oh well
• [x] @aothms change applicable enitty
• [x] @aothms add parametrization for IfcGroup

Material Constituent Set

• The concept usage 'Material Constituent Set' for entity 'IfcRailing' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• Not sure, probably versioning thing.

Solution:

• [ ] @aothms to add parametrization

Material Layer Set Usage

• The concept usage 'Material Layer Set Usage' for entity 'IfcCovering' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Material Layer Set Usage' for entity 'IfcPlateStandardCase' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Material Layer Set Usage' for entity 'IfcSlabStandardCase' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Material Layer Set Usage' for entity 'IfcStructuralSurfaceMember' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Material Layer Set Usage' for entity 'IfcWallStandardCase' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• Two types of information mixed in one concept.
  1. Nomination of material label names
  2. Geometric positioning based on representation items specific to certain element types
• Deprecated/deleted entities
• The wrong parametrization was chosen, choosing use case 1.
• Material Labels like that should be used consistently regardless of using Constituents Layers or Profiles

Solution:

• [x] @Moult Speculative Create a concept "Composite Material Association" (or any other name) where we nominate material layer/constituent/profile names for certain element types regardless of whether the element uses Constituents Layers or Profiles
• [x] @aothms To change parametrization type to unary
• [x] @aothms To move material suggestions to novel template
• [x] @Moult To move definition in Markdown upwards to non deprecated entities

Material Profile Set Usage

• The concept usage 'Material Profile Set Usage' for entity 'IfcBeamStandardCase' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Material Profile Set Usage' for entity 'IfcColumnStandardCase' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Material Profile Set Usage' for entity 'IfcCovering' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Material Profile Set Usage' for entity 'IfcFlowSegment' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Material Profile Set Usage' for entity 'IfcMemberStandardCase' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Material Profile Set Usage' for entity 'IfcStructuralCurveMember' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• Probably same as above. Inconsistent usage.

Solution:

• [x] @Moult Verify whether this is indeed similar to the issue above
• [x] @Moult Speculative Create a concept "Composite Material Association" (or any other name) where we nominate material layer/constituent/profile names for certain element types regardless of whether the element uses Constituents Layers or Profiles
• [x] @aothms To change parametrization type to unary
• [x] @aothms To move material suggestions to novel template

Object Nesting

• The concept usage 'Object Nesting' for entity 'IfcEvent' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Object Nesting' for entity 'IfcProcedure' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Object Nesting' for entity 'IfcTask' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Object Nesting' for entity 'IfcTaskType' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Object Nesting' for entity 'IfcWorkSchedule' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• Missing parametrization for these elements

Solution:

• [x] @Moult Provide for each of the missing rows, what that element can be nested with.
• [ ] @aothms To model @Moult's suggestions in UML

Object Typing

• The concept usage 'Object Typing' for entity 'IfcObject' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• Aparrently we don't have a top level association between IfcObject - IfcTypeObject in UML

Solution:

• [x] @aothms To review and provide IfcObject - IfcTypeObject associations for all intermediate abstract entities if missing

Note that this will also be reflected in the entity where rules that are derived from the ObjectTyping concept.

Port Nesting

• The concept usage 'Port Nesting' for entity 'IfcDistributionPort' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• Is this for real? Can a port be nested with another port?

Solution:

• [x] @Moult @TLiebich @CyrilWaechter Please advise

Product Local Placement

• The concept usage 'Product Local Placement' for entity 'IfcBridge' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Product Local Placement' for entity 'IfcBridgePart' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Product Local Placement' for entity 'IfcBuilding' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Product Local Placement' for entity 'IfcBuildingStorey' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Product Local Placement' for entity 'IfcDistributionPort' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Product Local Placement' for entity 'IfcFacility' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Product Local Placement' for entity 'IfcFacilityPart' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Product Local Placement' for entity 'IfcPositioningElement' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Product Local Placement' for entity 'IfcSite' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Product Local Placement' for entity 'IfcSpace' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• I don't know why we have only IfcElement associated in UML. Probably a versioning issue. Are there any elements that cannot have a local placement? @TLiebich @peterrdf?

Solution:

• [x] @aothms Unless somebody objects I'll remove the parametrization to just have everything below IfcProduct be applicable.

Product Placement

• The concept usage 'Product Placement' for entity 'IfcProduct' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• This is an unparametrized concept.

Solution:

• [x] @Moult to review if there is anything meaningful written there. If yes, the documentation can move to either the ObjectPlacement attribute description if short. Or the IfcObjectPlacement entity markdown if longer. Or any other way as desired.

Property Sets for Objects

• The concept usage 'Property Sets for Objects' for entity 'IfcObject' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• This is probably general documentation. Not the association of a pset to IfcObject

Solution:

• [x] @Moult to review if this is important documentation to keep and if so, move to e.g IfcPropertySet or IsDefinedBy.

Quantity Sets

• The concept usage 'Quantity Sets' for entity 'IfcDistributionElement' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• No idea why there is specific documentation for Qsets on this entity

Solution:

• [x] @Moult to review if this is important documentation to keep and if so, move somewhere else.

Spatial Composition

• The concept usage 'Spatial Composition' for entity 'IfcBridgePart' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Composition' for entity 'IfcBuildingStorey' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Composition' for entity 'IfcFacilityPart' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Composition' for entity 'IfcSpace' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• Missing parametrizations

Solution:

• [x] @Moult @TLiebich @peterrdf to supply missing entries. !!Also new rows need to be added for IfcMarinePart and what not!!

Spatial Container

• The concept usage 'Spatial Container' for entity 'IfcBridgePart' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Container' for entity 'IfcBuildingStorey' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Container' for entity 'IfcFacilityPart' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Container' for entity 'IfcSite' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Container' for entity 'IfcSpace' in MVD 'GeneralUsage' is not modeled in UML

Solution:

• [ ] @Moult @TLiebich @peterrdf same as above

Spatial Containment

• The concept usage 'Spatial Containment' for entity 'IfcBeam' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcBuildingElementProxy' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcChimney' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcColumn' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcCovering' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcDistributionElement' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcDoor' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcElementAssembly' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcFeatureElement' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcMember' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcPlate' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcRailing' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcRamp' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcRampFlight' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcShadingDevice' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcSlab' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcStair' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcStairFlight' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcTransportElement' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcWall' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Containment' for entity 'IfcWindow' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• No issue. Issue with validator.

Solution:

• [ ] @aothms Maybe fix validator, maybe not.

Alternative solution:

• [ ] This is the issue we talked about several months ago. I feel like this list is outdated (probably only 2x3'ish entities) and not always argumented clearly. E.g can a IfcDistributionElement not be part of the IfcSite as brought up by @NickNisbet? We can also just remove the parametrization if there is consensus that the current list is too outdated. That way the documentation entries would still show up based on the applicability of the concept.

Spatial Decomposition

• The concept usage 'Spatial Decomposition' for entity 'IfcBuildingStorey' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Decomposition' for entity 'IfcProject' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Decomposition' for entity 'IfcSite' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Spatial Decomposition' for entity 'IfcSpace' in MVD 'GeneralUsage' is not modeled in UML

Solution:

• [x] @Moult @TLiebich @peterrdf same as above

Type Body Geometry

• The concept usage 'Type Body Geometry' for entity 'IfcBeamType' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Type Body Geometry' for entity 'IfcColumnType' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Type Body Geometry' for entity 'IfcCoveringType' in MVD 'GeneralUsage' is not modeled in UML
• The concept usage 'Type Body Geometry' for entity 'IfcMemberType' in MVD 'GeneralUsage' is not modeled in UML

Issue:

• Inconsistent parametrization. Currently we just don't assoiciate it. Again, I feel like this list is too outdated/selective to be useful. Most if not all TypeObjects should be able to have body.

Solution:

• [x] @aothms to remove parametrization so that the concept is applicable to any TypeObject to retain the documentation in these four cases.

[Moult]

Proposal for classification association:

It sounds as though the only parameterisation is in IfcDistributionControlElement. The relationships are all about external references.

Edit: evidence is because in IFC2X3 the original usecase was an attribute known as ControlElementId with this description "The ControlElement Point Identification assigned to this control element by the Building Automation System"

There are three types of external references (I copy pasted key bits of existing doc descriptions):

• Classifications: ... arrangement ... into a class or category according to a common purpose / characteristics... taxonomy, or taxonomic scheme, arranged in a hierarchical structure. A category of objects relates to other categories in a generalization-specialization relationship. Therefore the classification items in an classification are organized in a tree structure. A classification system declared may be either formally published, or it may be a locally defined method of classifiying information.... and as per chapter 3: classification: categorization, the act of distributing things into classes or categories of the same type
• Documents: yeah, not a document.
• Library: An IfcLibraryInformation describes a library where a library is a structured store of information, normally organized in a manner which allows information lookup through an index or reference value.

I disagree with the current usage of classification. IP addresses, MAC addresses, BACnet Object Identifier in a Building Automation System etc is not a hierarchical tree that classifies information - it may be a tree that signifies network setup, but not the information you are referencing in the network. So the whole concept of "tokens" in a classification system which denote hierarchy is not meaningful. This statement is makes no sense in terms of information to a user: "oh this element is on 127.0.0.1 so the parent classification of similar elements must be 127.0.0".

The problem is that the alternatives aren't very good either. Documents are not correct. It's clearly a different concept.

By process of elimination we should use a library reference - in the original usecase, a Building Automation System would be the external data library, and you'd refer to a key within that system. But there are still problems:

• The concept for library information seems to only talk about a library as a revision control server. Its specifications are rather questionable and implementation is undoubtedly rare.
• The entity description for IfcLibraryInformation seems pretty good until this line "In a broder sense, IfcLibraryInformation includes the meta data for capture the revision information when checking in library and other data into a revision control system." which again talks about revision control.

That said, I still think it's good to keep classification of objects separate from what I call "How elements are linked to external systems". I'd propose introducing formal concepts for library references, and rewording the library descriptions so that a revision control system is just one example of the systems you can link to, but BACnet et all are good examples of other systems.

So the parameterisation would disappear, and be merged into the docs as guidelines in IfcLibraryReference or in the newly added Library Association concept.

I actually asked this to @jmirtsch in the past: "How would I associate an IFC element to say a Brickschema dataset"? After looking at the three external reference types, we came to the same conclusion.

Thoughts?

[aothms]

Issue reported by @Moult

Annotation 2D Geometry

Annotation_IfcGeometricCurveSet_Annotation2D

Any point or curve

https://github.com/buildingSMART/IFC4.3.x-development/pull/378/files#diff-55c5e6aff0ccef815c56e147c20f72dc60871f0fbe2b55659ac165535c09cd91R40

Issue:

• Not rendered in HTML. Reason is that the parametrization contradicts the definition of the template. So I skipped it.

  This is reported here https://github.com/buildingSMART/IFC4.3.x-development/issues/113

Solution:

• [ ] @Moult Move documentation for concept parametrization to IfcAnnotation or IfcShapeRepresentation.

[aothms]

Proposal for classification association:

Thanks for clearly outlining the issue.

The problem is that the alternatives aren't very good either

How about a property set? It seems as if that would be inline with how similar meta-data is expressed. I'd also consider an IP address maybe a (somewhat even potentially dynamic) property of an element. It certainly doesn't classify it.

And a tangent

IfcDistributionControlElement

If we make it a pset we should probably make it applicable also to things like:

IfcCommunicationsAppliance and IfcMobileTelecommunicationsAppliance

[Moult]

If it were a property set, it would have to be applied to a lot of stuff. It's definitely not restricted to distribution control elements. It would extend to spatial elements, and IfcProcess for sure (at least for systems like Brickschema).

[Moult]

Proposal for constraint association:

All the 4 out of 5 constraints make sense to me, and in fact in the process of implementing. One of them I think could be a duplicate but I need a closer look. But I'm not sure what your question is. Perhaps I can explain what they are to you (verbally if necessary) and you can make a call on what needs to be done.

In short, it describes scheduling constraints. For example, if I change the amount of work to be done in a task, there are two possibilities: either it takes longer to complete the task, or I need to employ more resources to achieve it in the same duration. These constraints describe exactly how to express it in IFC using IfcConstraint.

Admittedly there is an element which I noticed the other day (IfcReference) which has some outdated and just incorrect documentation. Maybe that is what is causing your validation to fail or other confusion? I will fix the incorrect docs, but let me know if a verbal explanation helps.

[Moult]

For control assignment:

I know about half of these in detail, and the other half I know the theory but never implemented. I'm not quite sure what the question is again sorry. I'm looking in the IFC4 docs and it seems as though there are two ways of presenting the information depending on whether the second column is filled in in your spreadsheet. I'm not sure which approach is preferred, or what the distinguishing factors are to choose parameterisation or non parameterisation.

[aothms]

IfcProcess for sure (at least for systems like Brickschema).

Groovy. I wouldn't see how a process can have an IP or BACnet id, but I guess it's a matter of how you map things. General pset is fine to me.

Constraint Association

But I'm not sure what your question is.

Twofold.

(a) When we document parametrizations like this the implicit or explicit meaning is also that other elements wouldn't use this concept as part of "General Usage" (whatever that may mean, there's different interpretations of that, but I would see it as the union of all MVDs, with certain areas less elaborated than a specific MVD). Are we saying that we don't foresee other elements to use constraints? If the rows in this association table are just examples, then I think it should be that, an example file or something else not too normative.

(b) The parametrization table doesn't make a lot of sense.

IfcConstructionResource

Parameters="DataValue=IfcPositiveRatioMeasure;Attribute1=Usage;Attribute2=ScheduleUsage;"
Parameters="DataValue=IfcDuration;Attribute1=Usage;Attribute2=ScheduleWork;"

IfcTask

Parameters="Constrained Attribute=TaskTime.ScheduleStart;"
Parameters="Constrained Attribute=TaskTime.ScheduleFinish;"

Inconsistent between the two entities. Attribute2 I can't find in the template. Constrained Attribute makes even less sense I think.

How about this proposal then:

Solution:

• [x] @aothms We remove parametrization from the spec so that Constraint Association is applicable to all IfcObjectDefinition entities.
• [x] @Moult The parameters we have now we convert into a Table in Markdown (so not 4th level headings) just markup that will be rendered.

[Moult]

After verbal discussion:

Classification: will convert to library.

• [x] @aothms: Parameterisation to be deleted.
• [x] @Moult: to restructure Markdown and create new issue on crazy REST API stuff.

Constraint:

• [x] @aothms: Parameterisation to be deleted.
• [x] @Moult: to restructure as docs.

Control:

• [x] @Moult: supply square table of values.
• [ ] @aothms to implement

Element Nesting:

• [x] @aothms: delete parameterisation and apply to IfcElement.
• [x] @Moult: to copy the description of Element Nesting.

[Moult]

@aothms are we missing a diagram for element connectivity? The reason I ask is because there is this quote on IfcWall's docs:

Walls with openings that have already been modeled within the enclosing geometry may use the relationship IfcRelConnectsElements to associate the wall with embedded elements such as doors and windows.

This sounds very suspiciously similar to Element Nesting. In fact, I would say that perhaps IfcRelConnectsElements is more descriptive than "nesting", and can work for signs on doors or whatever.

[aothms]

are we missing a diagram for element connectivity

Related https://github.com/buildingSMART/IFC4.3.x-development/issues/186

If there's time I indeed think It's a good way to unambiguously show the direction wrt Related/Relating ConnectedFrom/To

One potential complexity is that we have both inheritance on the level of template (well mostly table of content like subdivision) inheritance of the applicable entity and also inheritance of the relationship (IfcRelConnectsElements) have subtypes with their own related template. Potentially that could be a confusing mix, but I'm not sure if it has an actual impact on anything.

[Moult]

By the way, to solve the constraint one instead of writing documentation to cover it, I'll just convert them into diagrams since that explains it much clearer. Here's a snapshot from IFC2X3 when they actually did have diagrams (every other concept usage for these things have diagrams... except for the constraints, which were lost in the 2X3->4 transition) - maybe explains why in IFC4 there were invisible tables that had captions but no content, maybe a bug in IFC4.

Anyone for anyone's interest here is a good example of a constraint diagram - it will take me a little time to audit them and ensure they accurately portray the IFC4 constraint concept usages:

[Moult]

Here is the completed table for controls

RelatingControl	RelatedObject
IfcActionRequest	IfcActor
IfcControl	IfcObjectDefinition
IfcCostItem	IfcProduct
IfcCostItem	IfcProcess
IfcCostItem	IfcResource
IfcCostItem	IfcTypeProduct
IfcCostItem	IfcTypeProcess
IfcCostItem	IfcTypeResource
IfcCostSchedule	IfcCostItem
IfcCostSchedule	IfcActor
IfcEvent	This is wrong, should be the row below because IfcEvent is not the RelatingControl
IfcWorkCalendar	IfcEvent
IfcPerformanceHistory	IfcGroup
IfcPerformanceHistory	IfcProduct
IfcPerformanceHistory	IfcProcess
IfcPerformanceHistory	IfcResource
IfcPermit	IfcActor
IfcProcedure	This is wrong, should be the row below because IfcProcedure is not the RelatingControl
IfcWorkCalendar	IfcProcedure
IfcProjectOrder	IfcActor
IfcProjectOrder	IfcTask
IfcTask	This is wrong, since IfcTask is not the RelatingControl
IfcWorkCalendar	IfcWorkCalendar
IfcWorkCalendar	IfcTask
IfcWorkControl	IfcTask
IfcWorkSchedule	IfcTask
IfcWorkSchedule	IfcActor

[Moult]

Here's the table for Object Nesting:

RelatingObject	RelatedObjects
IfcActionRequest	IfcActionRequest
IfcAlignment	IfcReferent
IfcConstructionResource	IfcConstructionResource
IfcCostItem	IfcCostItem
IfcEvent	This is wrong, IfcEvent is not the RelatingObject – see row below
IfcTask	IfcEvent
IfcPermit	IfcPermit
IfcProcedure	IfcTask
IfcProjectOrder	IfcProjectOrder
IfcTask	IfcTask
IfcTask	IfcProcedure
IfcTaskType	IfcTask
IfcWorkSchedule	IfcWorkSchedule

Note that there are a few ones debatably missing from this table. For example, should an IfcTaskType also be able to nest IfcEvents and IfcProcedures? Potentially yes (it's not written in the docs, but I feel as though the intention is there). I haven't implemented that part yet so I can't say with 100% certainty, so keep in mind that this table may need some additions in the future.

[Moult]

Here's the review on Port Nesting:

IfcDistribution port has this description, I've annotated it inline:

The Port Nesting concept applies to this entity.

Sure. I personally reckon these sentences are superfluous and should be deleted.

Distribution ports are indicated on products and product types using the IfcRelNests relationship where RelatingObject refers to the enclosing IfcDistributionElement or IfcDistributionElementType respectively. The order of ports indicates logical ordering such within outlets, junction boxes, or communications equipment.

This sentence does not sound correct. This is not the Port Nesting concept. This is the Element Nesting concept. This sentence should be taken out of this concept usage, and put into the Element Nesting section.

Ports may be further nested into sub-ports, for indicating specific connections on components or pins.

Not an MEP person. Seems plausible. But I have no idea what the allows subport combinations would be.

[NickNisbet]

a. I don't believe sup-port nesting has ever been used. b. However, consider a UK small-power plug and a socket. These can be represented as a port-to-port connection. If necessary the each port, one on the plug and one on the socket could be dis-aggregated into three sub-ports, one for live, one for neutral, one for earth. c. Given the increased interest in off-site, modular construction of multiple service frames, it could make sense to have a port to control how the frames fit together and then sub-ports for the individual pipes, wire harnesses and ducts to ensure continuity. d. My suggestion would be to keep the possibility open.

[Moult]

Product Placement review:

The concept usage 'Product Placement' for entity 'IfcProduct' in MVD 'GeneralUsage' is not modeled in UML

Will just move docs to ObjectPlacement attribute. Makes more sense there.

[Moult]

Property sets for objects:

The concept usage 'Property Sets for Objects' for entity 'IfcObject' in MVD 'GeneralUsage' is not modeled in UML

Nothing meaningful. Already repeated in IfcPropertySet docs. Deleted.

[Moult]

Quantity sets:

The concept usage 'Quantity Sets' for entity 'IfcDistributionElement' in MVD 'GeneralUsage' is not modeled in UML

Nothing new. Deleted.

[aothms]

Ports may be further nested into sub-ports, for indicating specific connections on components or pins.

Not an MEP person. Seems plausible. But I have no idea what the allows subport combinations would be.

a. I don't believe sup-port nesting has ever been used.

I think the idea is also valid and maybe at that time when we really start using it should be a different (hierarchical) template. Is there any way we can just move this one statement on sub-ports to the documentation of IfcDistributionPort itself?

[Moult]

This table is for Spatial Decomposition, but if you read it right to left you get Spatial Composition :)

RelatingObject	RelatedObjects
IfcProject	IfcSite
IfcProject	IfcBuilding
IfcProject	IfcFacility
IfcProject	IfcBridge
IfcProject	IfcMarineFacility
IfcProject	IfcRailway
IfcProject	IfcRoad
IfcProject	IfcExternalSpatialElement
IfcProject	IfcSpace
IfcSite	IfcSite
IfcSite	IfcBuilding
IfcSite	IfcFacility
IfcSite	IfcBridge
IfcSite	IfcMarineFacility
IfcSite	IfcRailway
IfcSite	IfcRoad
IfcSite	IfcExternalSpatialElement
IfcSite	IfcSpace
IfcExternalSpatialElement	IfcExternalSpatialElement
IfcBuilding	IfcBuilding
IfcBuilding	IfcBuildingStorey
IfcBuilding	IfcSpace
IfcBuildingStorey	IfcBuildingStorey
IfcBuildingStorey	IfcSpace
IfcSpace	IfcSpace
IfcFacility	IfcFacility
IfcFacility	IfcFacilityPartCommon
IfcFacility	IfcSpace
IfcBridge	IfcBridge
IfcBridge	IfcBridgePart
IfcBridge	IfcSpace
IfcMarineFacility	IfcMarineFacility
IfcMarineFacility	IfcMarinePart
IfcMarineFacility	IfcSpace
IfcRailway	IfcRailway
IfcRailway	IfcRailwayPart
IfcRailway	IfcSpace
IfcRoad	IfcRoad
IfcRoad	IfcRoadPart
IfcRoad	IfcSpace
IfcFacilityPartCommon	IfcSpace
IfcBridgePart	IfcSpace
IfcMarinePart	IfcSpace
IfcRailwayPart	IfcSpace
IfcRoadPart	IfcSpace

[Moult]

Spatial Container & Spatial Containment:

My feel is that this should be the rule and not go into any further detail:

RelatingStructure	RelatedElements
IfcSpatialElement	IfcAnnotation
IfcSpatialElement	IfcElement
IfcSpatialElement	IfcLinearElement
IfcSpatialElement	IfcPositioningElement

[TLiebich]

just a note - the concept usage (or general usage) at least in IFC4.0 time frame was never done in a complete fashion, meaning that if a concept usage is not specified, it is illegal. Rather it has been used to enhance the documentation, meaning that here it shows a particular importance (or just, someone was interested in it).

I just note this, so there is no surprise that many of such general usages are missing. I also assume that this work to improve will take more time and can continue after the March deadline.

[Moult]

meaning that if a concept usage is not specified, it is illegal. Rather it has been used to enhance the documentation ...

Wait, it is illegal or it is not illegal? :)

[TLiebich]

sorry - "if a concept usage has not been specified, it does not mean, that it is illegal" (absence does not mean disallowed)

[Moult]

A note @aothms not sure if you've done it already but I updated the table in https://github.com/buildingSMART/IFC4.3.x-development/issues/403#issuecomment-1059089846

[aothms]

@TLiebich I'm fully agreeing on that statement. Do you have an idea on how we can put that into words? For example as a sentence above the "General Usage" table in the concept pages [0]. Ideally it should cover these three cases in the same statement:

• Comprehensive. For example psets. All standardized psets are in there. And it's really not recommended to assign a Pset_SlabCommon to an IfcWall.
• Indicative. Material Layer Set Usage will really work best on (Wall, Slab, ...). Don't assign it to an IfcVegetation. But you know, an IfcRoad, why not.
• Examples. Element Nesting. Yes, JunctionBox and SanitaryTerminal can be nested, but there's probably a ton of other valid cases.

[0] http://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Object_Association/Material_Association/Material_Constituent_Set/content.html#General-Usage

[Moult]

Here's an attempt:

Concepts may have particular importance to common or standardised industry practices and scenarios. The table below shows a recommended list of general usage patterns that users may adopt.

[aothms]

I think it's good. The question perhaps is whether it needs a bit more explanation, such as:

The concept diagram above provides a generic mechanism to fulfil such practices and scenarios. The rows in this table establish specific uses of these templates, which may be further documented on the individual pages referred to.

Ugh

Edit: meant to be combined with the above

[Moult]

Righto, here's an attempt to merge - with the intention to display like this:

X.X.X.X Concept Title Foo Bar

Blah blah blah description

The following diagram shows the generic classes and relationships used when applying this concept. In addition, concepts may have particular importance to common or standardised industry practices and scenarios. For these specific usage scenarios, the table below shows a recommended list of general usage patterns that users may adopt.

[diagram]

General usage

[table]

I tried to keep the language simple so I avoided terms like template.

[aothms]

Wonderful. Is it an idea to just write it in the template.html instead of appending to each and every markdown. Maybe with some intelligence to check if there is actually a diagram and a table? Well, you decide.