Design rule for elements for the source element of a unidirectional relationship

[CharlieG021163]

ERDi Decision: What is design rule for AMIRA / ERDi Protobuf and JSON implementions?

Background In updated 950002 and 950004 models, 95 Committee agreed that the standard's convention is show the logical direction of all UML model relationships. Most relationships in models are unidirectional from a source object to a target object where the UML and XML best practice is applied with only the naming of target role element in the relationship role table for each object.
The current B2MML 7.0 beta is very inconsistent by having both source and target elements for unidirectional relationships in many types and having no source element in many types.

Solution MESA Solution: Since updated 950002 relationship role naming convention only names the target element and not source element, the existing instances of source elements in B2MML shall not be deleted to align with the updated standard but shall change the element name to XXXSourceID to make the role explicit in the object and it B2MML type to be schematically correct, MESA B2MML implementation is inconsistent in it use of source elements across the schema.

ERDi Options: Recommend B2MML adopt a consistent design principle in its implementation of either:

1. Delete the source elements across the schema in the 95 unidirectional relationships.
2. Add the source elements across the schema in the 95 unidirectional relationships in schema to a naming convention of XXXSourceID from XXXXID. This change that has been incorporated throughout ERDi implementation on GitHub.

Example: EquipmentClassType, element name = "EquipmentID" type = "IdentifierType".
This the source in a unidirectional relationship in updated ISA-95 part 2 and B2MML represents it as a bidirectional relationship by having this element. This applies across all resource types. The following elements are the current B2MML source elements for various relationships that are changed to the Option 1 naming convention:

Impacted Types and Solutions

• TYPE
  • Updated ELEMENT
• OperationalLocationClassType
  • OperationalLocationSourceID
• PersonnelClassType
  • PersonSourceID
• EquipmentClassType
  • EquipmentSourceID
• PhysicalAssetClassType
  • PhysicalAssetSourceID
• MaterialClassType
  • MaterialDefinitionSourceID
• MaterialDefinitionType
  • MaterialLotSourceID
• ProcessSegmentType
  • WorkMasterSourceID
  • OperationsSegmentSourceID
  • SegmentRequirementSourceID
• OperationsEventClassType
  • OperationsEventDefinitionSourceID
• OperationsDefinitionType
  • WorkMasterSourceID
• OperationsSegmentType
  • WorkMasterSourceID
• ResourceNetworkConnectionTypeType
  • ResourceNetworkConnectionSourceID
• WorkMasterType
  • JobOrderSourceID
• WorkDirectiveType
  • JobOrderSourceID

[racheliurui]

@CharlieG021163 will provide examples.

[CharlieG021163]

Team Agrees

[Dennis-Brandl]

I don't believe that the name "SourceID" really works, These are the IDs of releated objects, such as OperationalLocationID is the ID of the Operational Location. When I read "OperationalSourceID", I don't think of this as an OperationalLocation ID, but as an ID of something called an OperationalLocationSource, and there is no such object. The convention was to use the

[gerardmoloneyetpartners]

Hi @Dennis-Brandl do you disagree with the change based only on 'source' or because you do not want to implement a change to align with ISA95 in regards to the unidirectional relationship for source and target elements?

If the first, we can review and come up with an alternative approach perhaps. If the latter, then I can remove this change proposal from the 'Final Review' milestone as closed for MESA.

[Dennis-Brandl]

I still disagree with the change based on the name of the element. I think it is misleading. To me "Source" means something like a source file, or source of the data, not a like to a parent. But we just need to get this out of ETPartners and into the MESA review, so I kept the change that was in the ETPartners version. This issue can be closed.