Part composition follow ups

[aothms]

          Really happy to see this kind of involvement, I'd propose one addition though:

If we read the definition of IfcFacilityPartCommon:

A part that is not clearly part of one domain but is a hybrid and has shared responsibilities in multiple domains.

Source: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcFacilityPartCommon.htm

Given that I'd recommend:

1. that IfcFacilityPartCommon can be part of all Parts (excl IfcBuildingStorey).
2. we double check the entry: IfcFacilityPartCommon - IfcFacility. Is that supposed to include inheritance (and is it implemented like that).

Originally posted by @aothms in #176 (comment)

[evandroAlfieri]

Acting as witness, when IfcFacilityPartCommon was created the idea was to handle parts that are "common" to multiple facilities, and cannot be strictly made as part of (only) the bridge, or the road, or the railway etc.

So, indeed IfcFacilityPartCommon is missing from the usage table, but as part of other facilities. Another missing entity in such table is IfcSpatialZone

To summarise, the missing rows in the decomposition table, without adding scenarios but just making sure to cover what the documentation already says, in my view are:

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