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

racheliurui commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

gerardmoloneyetpartners commented 5 years ago

I would be using the same language that is in the models for the "Relationship Roles" such as "IsMadeUpOf" instead of using 'child' or 'Nested Child".

FYI - aside from the language, I am not familiar with the impact on the B2MML.

CharlieG021163 commented 5 years ago

XXXChild is what is in the Relationship tables as the explicit role (Target) name. Per the OMG UML Standard, it is best practice to name the schema elements by the source and target role names using xxxParent and xxxChild.

I reviewed the old B2MML version notes and did not find a specific statement that the element/attribute for an aggregation hierarchy relationship in a complex type is specifically only a child name and named as the target role. However, it is stated in the Material Model’s “assembly hierarchy” in the B2MML and Part 2 Clause 5.7.9 Assemblies where an assembly is a list of children so it is implied that all other “is made up of” and and “contains” aggregation hierarchy relationships would not be different.
“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. In applying assemblies to resource objects, the assembly type and the assembly relationship attributes for the associated parent resource object shall apply to the parent object and its specified set of children resource objects at the time of the data exchange.”

Also, I searched the web to confirm the XML design principle. Attached is a paper that states this in section 5.6 and 5.6 but search for “child” for complete explanation. I found other sites stating similar. Also, Part 2 Clause 3.3.2 UML notation in information object models, Table 1 – UML notation used, explains that UML aggregation is a whole (parent) to a part (child). 3.3.4 Relationship types a) Aggregation: the view of the UML relationship is qualified by the target end of the relationship link; the terminology used is “aggregation part” for the sub object and “aggregation whole” for the parent object. An aggregation type can be refined with the following keywords: 1) Whole: the object is the whole object in the aggregation. 2) Part: the object is the part object in the aggregation. 3) Hierarchy: the object can be both a whole and part object. EXAMPLE 2 Equipment hierarchy. This infers that implementations can utilize parent and child prefixes or link tables if navigation of the hierarchy is required. In an aggregation hierarchy when a parent object is deleted, the relationships to other child objects are removed if specified in link tables but the child objects are not deleted. So the above is why the target role in all aggregation relationships in each object relationship table is explicitly named “xxxchild” as to make it clear in all implementations.

Issues:

So in B2MML, the current aggregation element/attribute cannot be used to reference a xxxParentID. If we want to have a parent ID for the source of an aggregation hierarchy, it has to be in a property object in B2MML or in custom attribute or a property in the ERDi implementation.
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 XXXParentProperties. This is what we should recommend since many implementations will use a property for an XXXParentID
Rachel’s NestItemType in Hierarchy scope proposal goes against the aggregation hierarchy design principal described above.

CharlieG021163 commented 5 years ago

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 commented 5 years ago

"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 commented 4 years ago

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.

ETPartners / b2mmlv7beta

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

Impacted Types