Nested Properties: "Child" should be appended to the element name that are nested under parent properties.

[racheliurui]

Background and Solution
To align with updated 950002 and 950004, the defined relationship role names for the "Contains" and "Is made up of" nested association relationships in the Relationship Role Tables for many information models append "Child" to the target role element name nested under parent properties.
In B2MML, current child elements are not explicitly named to distinguish between parent verses child objects in implementations.
In B2MML with any nested structures like equipment hierarchy, there's an assumption that the nesting is from Parent to Child

			<p:HierarchyScope>
				<p:EquipmentID>CompanyA</p:EquipmentID>
				<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
				<p:HierarchyScope>
					<p:EquipmentID>SiteB</p:EquipmentID>
					<p:EquipmentLevel>Site</p:EquipmentLevel>
				</p:HierarchyScope>
			</p:HierarchyScope>

The issue is, in many cases, users would think the nested property is actually from Child to Parent. how can user tell what's wrong with below payload? (Nested from Child to Parent).

			<p:HierarchyScope>
				<p:EquipmentID>SiteB</p:EquipmentID>
				<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
				<p:HierarchyScope>
					<p:EquipmentID>CompanyA</p:EquipmentID>
					<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
				</p:HierarchyScope>
			</p:HierarchyScope>

By introducing Child to the tag naming, it becomes explicit the nested tag is referring a child of the current tag.

			<p:HierarchyScope>
				<p:EquipmentID>CompanyA</p:EquipmentID>
				<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
				<p:HierarchyScopeChild>
					<p:EquipmentID>SiteB</p:EquipmentID>
					<p:EquipmentLevel>Site</p:EquipmentLevel>
				</p:HierarchyScope>
			</p:HierarchyScope>

Impacted Types

As this proposed change impacts a lot of elements' name, the list of impacted types are not listed here but will be commented with the changelog.

[racheliurui]

After today's discussion session, I think I need to update my understanding of the intention to introduce Child with nested tag.
To make it clear to everyone who read this issue, I will update the top description only.

[racheliurui]

@CharlieG021163

I just think of another way for it to have better backward compatible, See the below payload example.
By introducing an optional element/property "NestedItemType", it can have minimal impact on existing implementation as well as containing the information to help understand if the nested item is Parent or Child.

Another point is, for example, Physical asset class

Table 49 – Physical asset class relationship roles

In ISA950002, both parent and child type are modeled. From the implementation point of view, this kind of model makes implementation very flexible.
The current B2MML only defined nested PhysicalAssetClass, but the recommended modification make it explicitly being PhysicalAssetClassChild. So, people use the standard will lose the flexibility if they want to use nested PhysicalAssetClass as a nested parent (Let's suppose message publisher and the consumer has an agreement to understand the nested type is parent or child).
So, my point is, make the tag to indicate it's child or parent is good, but the baseline is we can't lose the flexibility to choose to nest parent or child. Where in the above case, we need to define 2 optional tags inside the PhysicalAssetClass, one is PhysicalAssetClassChild another is PhysicalAssetClassParent.

Where below is another option I recommended, which is much more backward compatible and without losing the information to indicate the nested type is child or parent.

 <p:HierarchyScope>
	<p:EquipmentID>CompanyA</p:EquipmentID>
	<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
        <p:NestedItemType>Child</p:NestedItemType>
	<p:HierarchyScope>
		<p:EquipmentID>SiteB</p:EquipmentID>
		<p:EquipmentLevel>Site</p:EquipmentLevel>
	</p:HierarchyScope>
</p:HierarchyScope>

 <p:HierarchyScope>
	<p:EquipmentID>SiteB</p:EquipmentID>
	<p:EquipmentLevel>Site</p:EquipmentLevel>
        <p:NestedItemType>Parent</p:NestedItemType>
	<p:HierarchyScope>
		<p:EquipmentID>CompanyA</p:EquipmentID>
		<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
	</p:HierarchyScope>
</p:HierarchyScope>

 <p:HierarchyScope NestedItemType="Parent">
	<p:EquipmentID>SiteB</p:EquipmentID>
	<p:EquipmentLevel>Site</p:EquipmentLevel>
	<p:HierarchyScope>
		<p:EquipmentID>CompanyA</p:EquipmentID>
		<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
	</p:HierarchyScope>
</p:HierarchyScope>

[racheliurui]

One special scenario noticed with WorkMasterType, where ParentID and nested child both being modeled in the type.

[CharlieG021163]

Refer to #32 Based further research, the “has properties of” association hierarchy that has the role name of XXXParent in the all the relevant relationship table in Parts 2 and 4 should be change to XXXGroup or XXXCollection. This is what we should recommend since many implementations will use a property for a specialized group of XXXIDs.

[racheliurui]

"In applying assemblies to resource objects, the associated child objects shall be identified as the values of attributes under the parent resource object.
Assembly relationship applies to the following resource objects: material lot, material sublot, material definition, material class, material requirement, material actual, material segment specification, operations material bill item, and material capability."

• See above evidence provided by Charlie, which indicate that the ISA-95 has the design principle to nest child for types.

• I will support changing the name tag with Child for material lot, material sublot, material definition, material class, material requirement, material actual, material segment specification, operations material bill item, and material capability.

"in all aggregation relationships in each object relationship table is explicitly named “xxxchild” as to make it clear in all implementations."

• See above evidence provided by Charlie, which indicates XML standard using aggregate to specify nested Child (?)

• I will support changing the naming tag by appending "Child" for aggregated nested types, for example, hirarchyscope.

[Dennis-Brandl]

I am not sure that "Child" has the same connotation as "Contains" or "Is Made Up Of". None of the standard English definitions of "Child" matches the relationships.
The term "Contains" in the relationship name is used for a composition hierarchy.
The term "is made up of" in the relationship name is used for an aggregation hierarchy.
I suggest prepending "Contains" to the element name (e.g. ContainsEquipmentProperty) for the contains relationships.
I recommend prepending "MadeUpOf" to the element name (e.g. madeUpOfPhysicalAsset) for the 'is made up of' relationship.
This is more consistent with the ISA 95 standard.