This issue depends on acceptance of the proposal BACM_5 to remove Annex B from the specification document. It seeks proposals to dispose of this content.

Defer to Revision Task Force

This Annex provided an example of the external model query facility. This facility was replaced with an adaptation of the SysML V2 external reference in order to gain approva of the OMG Architecture Board.
The annex was removed from the specification in a prior FTF vote.
The example in the annex uses XQuery to access information from the XML serialization of a BPMN process model.
It is a valuable work that is not incompatible with the external reference model as it could become a query part of a de-referenceable URL or it could also be the content of an HTTP POST operation. It can probably survive as an adjunct, non-normative document with some editing to show how to use it with the external reference facility.

Metamodel of Business Architecture Guild defines two relationships between Value Stream Stages and Value Item labeled as Entry Criteria and Exit Criteria. These relationships are missing in the BACM.

Defer to Revision Task Force

These relationships did not appear in any version of the submission and constitute a material change to the beta specification. Recommend that this issue be deferred. Entry and exit criteria can also be determined by analysis of the outcomes of capabilities supporting the value stream stages and selecting specified outcomes to serve as entry and exit criteria. An architect following the BIZBoK Guide(tm) would be able to perform this analysis based on information in a BACM model.

A prior vote of the FTF approved the removal of this content from the specification. The FTF must now decide what to do with this content.

Defer to Revision Task Force

The content of this part of the submission would need substantial revision and it is not material to the completion of the specification document and to the submission of MOF compliant XMI.

This diagram represents the capabilities that would be required to carry out a means or initiative. Often, these capabilities are not a part of the organization and must be added, e.g. by contract. The issue is that abstract process should be included because it represents a perspective that abstractly represents the operations of the business that is distinct from the capability perspective but at the same level of abstraction.

Defer to RTF

The changes to the specification are material. See Jim Rhyne comment on the issue, reproduced below:
Diagram 7.3.7.3 adds Means and Initiatives "require" AbstractCapability. This represents capabilities that may be needed to carry out the Means and/or Initiatives; these may not be a part of the steady state model of the business. The issue to be resolved is whether AbstractProcess can also be "required" by Means and/or Initiatives. This would represent processes and activities that would be needed to carry out the Means and/or Initiatives. It is unclear whether this new relationship is primary or can be derived from other relationships (e.g. via required capabilities).
It also adds "implements" from CapabilityImplementation to Initiative. CapabilityImplementation represents an abstract specification of resources and performers. The "implements" association should be a shortcut, as it is supported by role assignments of the Resources and Performers to the Roles of AbstractCapability which is "required" by Initiative.
CapabilityImplementation Resources and Performers can also be assigned to Roles of AbstractProcess. There is no shortcut association "implements" between CapabilityImplementation and AbstractProcess. This should be added to avoid having to specify the details of such assignment as individual Role assignments.
Once the "implements" shortcut association between CapabilityImplementation and AbstractProcess is added, the "implements" shortcut association can be added between AbstractProcess and Initiative.

This issue arises from the resolution of BACM-45 and BACM-43. Taken together these proposals create an interpretation of the BACM model elements that does not syntactically distinguish elements representing sets from elements representing individuals. Rather, it represents individuals by an OCL constraint that allows only a single model element to have a given metaclass. This solution works for the only case in the current BACM spec, but does not resolve the underlying issue of the inability to represent individuals and make assertions about them.

Resolution requires substantial change to the BACM metamodel

Implementing a domain of individuals and assertions (e.g. OWL 2) would require adding many more classes and associations to the metamodel with consequences unanalyzed at this time.

A participating stakeholder in a value stream is a Performer role in a Capability that produces an Outcome that is valued by a ValueItem produced by a ValueStreamStage. This relationship is missing from the metamodel

Add the participate association as a shortcut

Add the participate association as a shortcut. Define OCL 2 expression of the shortcut function. Create new diagram "Participant" to show the metamodel elements referenced in the OCL expression.

On investigation and after Ballot #7, it was discovered that the issue was incorrectly stated. The source to destination of both assignTo associations are correct. However, the text label direction arrowhead for PerformerRole assignTo Performer is reversed.

Edit the EA model to reverse the text arrowhead direction

Edit the EA model to change the direction of the text label arrowhead.
Generate the SVG version of the diagram. Generate the replacement RTF for 7.3.4

Two generalization relations are missing from this diagram between Organization::Resource and Organization::Performer as less general and Strategy::AbstractOperatingModel as more general

Add the missing generalization relations to the 7.3.7.1 OperatingModel

Add the missing generalization relations to the 7.3.7.1 OperatingModel

CustomerJourney, CustomerJourneyStage and Touchpoint are missing from this diagram

Add the missing classes and the generalization relations

Add the missing classes and the generalization relations

The "owns" association denotes strict composition at the model instance level. Business architecture methodology disallows non-strict composition for capabilities and value stream stages and value streams, but makes no statement about other cases. Business architecture methodology also disallows specialization of capabilities, value stream stages and value streams. The metamodel needs a "does it make sense" review to determine if "owns", "agggregates" and "generalizes" are properly expressed in the model.

Revision to generally allow generalizes, owns and aggregates between BusinessElements

The EA metamodel is revised to allow generalizes, aggregates and owns associations between BusinessElement concrete subtypes, subject to the constraint that the participating instances must be of the same concrete type. This is enforced by a set of OCL 2 constraints associated with the BusinessElement.
In addition, OCL 2 constraints on Capability disallow generalizes and aggregates links between Capability instances.
In addition, OCL 2 constraints on ValueStream disallow generalizes, owns, or aggregates links between ValueStream instances.
In addition, OCL 2 constraints on ValueStreamStage disallow generalizes and aggregates links between ValueStreamStage instances.
In addition, OCL 2 constraints on CustomerJourney disallow generalizes, aggregates or owns links between instances of CustomerJourney.
In addition, OCL 2 constraints on CustomerJourneyStage disallow generalizes and aggregates links between instances of CustomerJourneyStage.

The beta specification states that SMOF is a requirement for implementors. However, SMOF lifts the MOF restriction that each instance have one and only one metaclass/meta-association. Consequently, the specification is ambiguous about what elements should be disjoint. Some meta-classes should be disjoint (e.g. business objects and capabilities).
This omission also affects the issues raised in BACM-83.

Clarify the SMOF requirement and provide additional diagrams

The changes affect all of section 7.3.1 which is to be replaced by the attached Word file. Prose changes clarify that SMOF allows multiple metaclasses and eliminates the MOF requirement of classifier disjointness. Consequently, additional diagrams are introduced to explicitly specify disjoint constraints. These disjoint constraints also appear in the MOF compliant XMI as OpaqueConstraints specified in the SMOF language. The consistency of the resulting model is tested by translating it into OWL and using a reasoner to determine any inconsistencies.

Conformance statements are incomplete and distributed through section 7. Provide an updated Conformance section that addresses conformance requirements, This issue resolution also resolves BACM-26, BACM-55 and partly resolves BACM-84 (with respect to conforming with the requirement to implement SMOF).

Section 2 of the document is replaced

Section 2 of the document is rewritten to establish conformance levels in four independent aspects: content completeness, SMOF capability, Shortcut capability, MOF extension [MEF] capability.

ProductOfferings can be aggregated by not contained or generalized. This appears to be an omission that would compromise the usefulness of the specification. It would be a minor change to the Product diagram.

Merge this issue with BACM-83

This issue is resolved by the proposal to resolve BACM-83

MEF replaced the categorization mechanism per request from the AB reviewers. The beta specification document does not define the compliance requirement for MEF.

This issue duplicates issue BACM-97

This issue duplicates BACM-97

Compliance statements for shortcuts and touchpoints, while these are optional compliance points, seem hard to evaluate.

This issue should be merged with BACM-97

This issue should be merged with issue BACM-97

Section 5 Symbols and Abbreviations is largely empty. There are, however, a number of acronyms used within the submission that should be specified there. The acronyms present in the listing of Normative References is fine as is, but “SPARQL”, “OWL” or “OWL 2” perhaps, and “RDF” (RDF* is listed in the normative references, but the citation does not spell out the acronym).

RDF, OWL, SPARQL and RDF are references, not symbols or abbreviations*

Change the places where these abbreviations are used to make it clear that they are references. Update the Non-normative references to be the current versions of each specification

The definition of shortcut does not match its expression in the MOF translation.

Changes to 7.2.1 and 8.1 to clarify the interpretation of <<shortcut>>

Changes to 7.2.1 adopted in BACM-44 and BACM-39 clarify that <<shortcut>> stereotypes are treated as <<class>> stereotypes with the addition of specializing BACMShortcut. No changes are proposed in this resolution.
Changes to 8.1.1 clarify how <<shortcut>> associations are represented in the MOF compliant XMI and how the OCL constraints representing the shortcut semantic are structurally specified and how they should be implemented by a modeling tool.

There are duplicate association names in the EA model. Because nearly all of these associations are stereotyped with <<class>> or <<shortcut>>, they are transformed into a class association pattern in MOF and duplicate names for classes are not allowed. The transformation program de-duplicates these names, but coherence is lost between the UML model of the specification (and the specification document generated from the UML model) and the generated MOF XMI.

Rename duplicate named association in the UML model

Rename the duplicate named associations by suffixing them with an underscore and a number. Add prose to section 7.2 of the document to describe the effective interpretation.

Section 7.2 identifies a case where same named associations with identical src end types are to be treated as a single association with dst end types that are a union of the end types of the designated associations. This can be eliminated by substituting an abstract class that is a superclass of the class to be unioned and having the dst type be this superclass. This change simplifies the transformation program and eliminates possible misunderstanding of the specification.

Add abstract superclass and terminate single association in superclass

UML does not provide a way to specify multiple types for association ownedEnds or a semantic that would interpret this case as a union. Change the UML model to add an abstract superclass in the three cases where this occurs in the model and terminate a single association at this superclass. Add generalization arrows from the classes to be unioned to this superclass. Then delete 7.2.6 from the specification document. The new superclasses are JSTP in the ValueFit diagram, APCICB in the OutsourcedServiceOfferingDiagram and VSVSS in the Process diagram.

IRI is not a primitive type in UML. In the beta document, a class with the name IRI was used to represent an IRI type. But, the IRI type is better represented in UML as a DataType.

Replace class named IRI with datatpe named IRI

Delete the class named IRI. Create a datatype named IRI. Change the type of the resourceIdentifier ownedAttribute to refer to the datatype named IRI. Change the pkgele.py module to handle uml:DataType elements.
Change the BACMMOF2OWL.py program to recognize the IRI datatype and map to xsd:anyURI.

The "recordedAs" and "stateOf" associations between Outcome and AbstractBusinessObject overlap.

Edit model to separate affected associations

Edit model to separate affected associations and republish

Following vote #3, the specification document was not completely updated as the result of an editing mistake. Consequently, some elements that were deleted in the BACM_Model package are referenced in the diagrams and prose of other packages.

This issue is about the process of producing the specification and not its content

N/A

The quantification patterns for the special associations (owns, generalizes, aggregates) are inconsistent in the specification and the MOF XMI file.

This issue is covered by BACM-83 that is resolved by BACM-90

The resolution of BACM-83 by BACM-90 was adopted by the FTF in Ballot #8

Metamodel of Business Architecture Guild defines two relationships between Value Stream Stages and Value Item labeled as Entry Criteria and Exit Criteria. These relationship are missing in the BACM.

This duplicates BACM-38

This duplicates BACM-38 which has been approved

The BACM specification, diagrams and text, specifies the BACM model using stereotypes that are not consistent with MOF. Consequently, the XML of the specified model is translated to a MOF-compliant XML as required by the RFP and interoperability of implementations. Both XML models are unnecessarily complex since there is no need to use stereotypes. MOF associations are sufficient, and the model would be more straightforward. The implementation Intent can be adequately specified in text with constraints, if necessary. The intent appears to be an effort to over-specify the expected method for development of an application of the model.

No changes are made to the specification

As noted in the comment of 2/16/2023, the submitters decided to resolve the conflict between visual and descriptive complexity in the specification document by using stereotypes in a UML model that is transformed into a MOF model. The issue author feels that the specification document should actually use the MOF model and not the UML model. It is not an OMG requirement to do this and other specifications have taken this path prior to BACM. Addressing this issue would require months of work in creating a new document that would be very different from that approved by the AB and the DTC and would likely require re-approval. It is not clear that this degree of change would comply with the P&P policies for FTFs. Consequently, this proposal recommends rejection of the issue.

The issue refers to the metamodel schema for instancing n-ary associations that are represented in the metamodel by an association stereotyped class and a single association named "related". The specification text states that when an instance is created, the legs of the instance instantiate the "related" meta-association but may be assigned distinct (role) names. The UML specification uses a similar device to allow n-ary associations from its MOF metamodel. In BACM, such n-ary associations are typically restricted to instances of a specific meta-class (e.g. AbstractBusinessObject). NOTE: this issue was accidentally combined with BACM-34 and is separated with this issue.

Changing of names is allowed in instancing

When an instance is created of an association, the instance becomes a member of the association type. When instances can be named, there are no restrictions on the names that can be used. When an association instance is created, the link ends become instances of the owned ends and member ends of the association and must satisfy the semantics of those owned ends and member ends with respect to instance types and quantification. These instances are reinterpreted as MOF associations, creating a new MOF model that is consistent with the MOF metamodel.

The beta document describes ValueStreamStage produces ValueItem as a shortcut association and also describes Capability supports ValueStreamStage as a shortcut association, creating an unresolvable mutual dependency. In addition, the prose describes ValueStream produces ValueProposition as a shortcut association, but this is missing from the EA model

Change EA model and regenerate diagrams and prose

Change the stereotype of ValueStream produces ValueProposition to <<shortcut>> and add PathSpecifications tagged value to the produces association to implement the constraint that this association is consistent with the ValueProposition aggregating some ValueItems produced by ValueStreamStages owned by the ValueStream..
Change the stereotype of ValueStreamStage produces ValueItem to <<shortcut>> and add PathSpecifications tagged value to the produces association to implement the constraint that this association is consistent with the ValueItem valuing some Outcomes produced by Capabilities that support the ValueStreamStage.
Change the stereotype of Capability supports ValueStreamStage to <<class>> and delete the PathSpecifications tagged value.

The specification displays classes with SMM:: namespace designations, but the model does not explicitly import SMM and it does not explicitly specialize the corresponding SMM metaclasses. By formally importing SMM, the BACM metamodel would be coupled with a particular version of SMM and would have to be revised to accommodate integration with other versions of SMM. On the other hand, the current normative text may not be sufficiently precise to allow an implementer to create a conforming implementation of this integration.

The beta specification is clear and unambiguous about inclusion of SMM

The beta specification defines specializations of SMM classes and associations in the SMM subpackage. Adding an import of the SMM metamodel to the BACM metamodel, along with the specializations explained in the BACM specification would not add any new information to the specification.

This issue was originally raised in BACM-17 which was proposed to be closed by BACM-54. However, the specification still references meta-classes no longer in the model (e.g. ValueCategory in 7.2.3.1). These references should be replaced.

Makes changes to document shell docx and the EA model to eliminate the terms and concept

Change the document shell docx to eliminate mentions of ValueCategory and categorizes. Regenerate the text documentation from the model and replace the affected sections of the document (Capability and Customer) with the new sections.

The specification has this as an aggregates association but the quantification suggests ownership. Resolve whether owns or aggregates and change owned end quantification to match.

Merge this issue with BACM-83

The proposal to resolve BACM-83 is able to address this issue. A convincing argument to restrict the associations between ValuePropositions to being only that of owning was not found. The default model will allow generalizes, owns and aggregates at the discretion of the business architecture modeler.

Section 0.5 - It would be nice to have the OWL 2 ontology provided as a machine readable file, even if only informative. Did the generation use MOF2RDF?

The OWL 2 Turtle draft ontology made available as informative adjunct

On approval, an OMG document number will be obtained for the attached OWL2 Turtle file (or its revision).

Section 0.6 has a very useful description that would be better in the body of the spec - section 0 will get stripped off after adoption.

Duplicated by issue BACM-21

BACM-21 requests the addition of an OWL 2 ontology as an informative document. There is a proposal to provide this document. When that proposal is approved, this issue should be resolved as a duplicate of BACM-21.

There seems no attempt to meet requirement 6.5.2.4 “Submitters shall identify shared terms and clarify any differences in definitions in UPDM/UAF, VDML, ArchiMate™, TOGAF Content Metamodel, BPMN, DMN, and CMMN.“

This issue should be merged with BACM-6

BACM-7 (a proposal to resolve BACM-6) which has been adopted by vote, proposes to remove Section 9 from the specification. Another issue has been recorded to publish the Section 9 content and other material as informative guidance. There are no proposals at this time to resolve this issue.

SIMF does have a RFP, though that does not seem to be proceeding.

Remove the reference to SIMF

Delete the following prose from page 2 of the specification.
"[SIMF] Semantic Information Modeling for Federation (SIMF) http://www.omgwiki.org/architecture-ecosystem/doku.php?id=semantic_information_modeling_for_federation_rfp"

It’s not clear who “the user” is at the end of para 4 and elsewhere. Can other property names in this specification be “modified”?

Replace ambiguous uses of "user" in section 7 with "business architecture modeler'

Replace 6 occurrences of "user" in 7.2.1 with the term "business architecture modeler".
Replace 2 occurrences of "user" in 8.1.2 with the term "business architecture modeler".

It’s odd that some references are version-specific, others are not - was that intentional?

Revise the reference section

Replace all version specific URLs with the generics.
Move references to the non-normative subsection.
Delete RDF-star and OpenCypher references

Element notes fields for BACMEntity, BACMRelation, BACMPlainEntity and BACMShortcut have Usage Notes: instead of Usage:. This causes the glossary generation tool to operate incorrectly.
IRI notes lack the Definition: bold prefix

Fix the notes in EA then regenerate the document.

N/A

As a condition of acceptance by the Architecture Board, the FTF is required to produce a MOF compliant XMI file. MOF does not allow profiles or association classes. To allow a faithful translation of the EA model, some new classes were introduced that translate stereotyped associations into a pattern of a class and two associations. To facilitate this, some new classes were added to the BusinessElement diagram and some redundant classes and generalizations were removed. Prose explanations should be added following the new BusinessElement diagram

Replace 7.3.1.1

This proposal incorporates model changes to support the generation of MOF-compliant XMI by transforming the XMI generated from the source model according to the normative specifications in section 7.2. It also incorporates editing changes that were made in the BACM_Model package to remedy a failure to update the text associated with changes to the diagrams published in BACM 1.0b1 (dtc-22-06-01).
Because the diagrams and text of section 7.3 are generated from the UML model, the number of editing changes would be very large. Consequently this proposal replaces 7.3.1.1 in its entirety. These changes do not effect the remainder of the specification.

During the AB approval process, the BACM_Model package diagram was changed to eliminate imports of the other packages. The submitters failed to include these changes in the final document that was sent to the OMG publications team for re-publication as dtc-22-06-01.

Close this issue as it duplicates an issue already in ballot

Duplicate of ballot #1 Issue #1

The prose of this section is difficult to understand. It needs to explain how an instance of a class can be a class and how individuals are represented as singleton sets. It is unclear that the singleton set interpretation can be imposed in the MOF model without a change to the metamodel to add an Individual abstract metaclass that is specialized by the MOF classes resulting from the translation of <<individual>> stereotyped EA classes.

Section 7.2.2 is replaced and Section 7.2.3 is deleted

The attached Word document replaces section 7.2.2.
Section 7.2.3 is to be deleted in entirety and the following parts of 7.2 are to be renumbered accordingly.

The categorization mechanism was removed from the specification draft and replaced by requiring MEF, which effectively allows the specification of stereotypes in a conforming tool. As in UML, these stereotypes may carry properties not present in the model instances. Mentions of category and categorization remain present in the beta specification document.

This issue was resolved prior to publication of the beta specification

The categorization mechanism was replaced prior to AB approval of the beta specification. The issue was recorded to preserve the history of changes. The beta specification requires MEF, which can be used to create profiles allowing for the categorization of BACM model elements by the definition of stereotypes and application of these stereotypes to model elements.
An issue has been created to address compliance requirements for MEF

Section 9 consisted of responses to RFP requirements to address alignment with other OMG specifications. This information should probably have been placed in Section 0 of the submission and be deleted prior to publication as a beta specification. Moreover, the information in this section is informative and is expected to evolve rapidly as the BACM specification is used by architects. Consequently, the recommended action is to delete Section 9 and republish it as an informative adjunct to the normative specification.

Remove Section 9 from the specification document

Section 9 consisted of non-normative responses to non-mandatory requirements in the RFP about alignment of BACM with other OMG specifications and with IT architectures. This material is provided as guidance to architects and organizations wishing to use BACM in conjunction with other OMG and non-OMG specifications. The material is expected to change rapidly. The proposal is to remove Section 9 from the specification and publish it as an informative adjunct document.

The use of “parent” to mean not a superclass but the class of an instance is unconventional and likely to confuse.

Replace "parent" with more specific terms

Replace use of the term "parent" with more precise terms such as "meta-class", "aggregator", "owner", "generalizing"

The notion of Touchpoint as defined in the RFP does not IMO require the open-ended query capability included here. Which is completely under-specified. On the other hand it does not seem to provide the Though it does say (in 8.2) “2) the modeling tool can integrate the BACM model with another model using a supplementary metamodel to join the concepts in the BACM metamodel to the concepts in the other model;” it does not provide that metamodel or any more details. It seems to me that this is what the RFP was looking for.specific links between classes in different metamodels that the RFP seemed to have in mind. Rather than allowing modelers to link specific elements from different models, it requires them to formulate some sort of query.

The issue is moot as the query mechanism is not present in the beta specification

This issue was addressed prior to the release of the beta specification as the query mechanism in the submission was replaced by the external reference mechanism adopted from SysML V2. This change was approved by the AB.
However, an example was presented in Annex B of the beta specification, and this example has been removed in Ballot #1 of this FTF. So there is no longer any substance to this issue.

There is extensive use of “M1” which is terminology that is no longer part of MOF (it was dropped at MOF 2.0). “M1” should therefore be explained/included in the Terms.

Define M1 in section 4 of the specification

The document uses the term "M1" to designate models that are derived from the BACM metamodel. The OMG has dropped this terminology, so its continued use in the specification must be supported by a definition. This proposal provides such a definition in section 4 of the specification.

The text definition of the AssignTo association between Resource and ResourceRole clearly states that the Resource is AssignedTo the ResourceRole, defining the direction of the association as being from Resource to ResourceRole. However, in the diagram and the generated test, the direction of this association is reversed.

Edit the diagram in the EA model to reverse the direction of the association

Edit the EA model to change the association direction.

Likewise “The user may also indicate that one instance generalizes another, but the implementation is not obligated to determine that the instance model is consistent.“ - what does generalization even mean between instances and won’t it depend on the metaclass? E.g. what would it mean to be a generalization of LegalEntity IBM Corp?

Rewrite and consolidate prose description of instancing

This proposal is mostly resolved by the proposal attached to BACM_44 (to resolve issue BACM-43) and a proposal (BACM-67) to resolve issue BACM-45.
The remaining part of this issue, that the BACM metamodel does not have a distinct domain of individuals (viz. the domain of classes and object properties as distinct from the domain of individuals and assertions) is unresolved. This proposal creates a separate issue (BACM-68) with a proposal to defer.

The treatment of n-ary associations as a set of distinct tuples seems unnecessary and logically suspect.

Substance of the issue is unclear

As noted in the comments, the use of tuples to define semantics of n-ary associations is well-defined in the literature and is neither unclear nor "logically suspect".
The use of "tuples" occurs in 7.2.1, which is rewritten in proposal BACM-44 (to resolve issue BACM-43).
It also occurs in 7.2.5. This section was reviewed and found to be both clear and logically sound.

The RFP says “This RFP defines scope in terms of a collection of perspectives”, however the submission only seems to be addressing 6 of the 10 perspectives in the RFP (Policy, Information, Initiatives, Value seem to be missing) in addition to the declared omission of an IT alignment.

The RFP only requires a Capability perspective

The RFP only requires a Capability perspective. The submission includes that and other perspectives deemed as very desirable in the RFP.

There is no Glossary in the perspectives as required in 6.5.2.2 of the RFP: only a combined glossary of camelcased metaclass names.

The Glossary in Annex A is deemed sufficient

It is possible to read the RFP as requiring a glossary for each domain of the metamodel. However, this was not the understanding of the RFP writers and no issue was raised during the RFP issuance. The specification provides a required glossary in Annex A.

This important Scope section should describe the spec in its own right and not reference the RFP. Nor, indeed, what other OMG models may or may not exist.

The issue appears inapplicable to the beta specification

This issue appears to address a prior submission, not the specification as approved by the AB and issued as dtc-22-06-01.

The term “class association” is used in several places - it should be “association class”.

Both class association and association classed are used in OMG specifications

A review of OMG documents and Policies and Procedures was unable to determine that this was an improper use.

7.2.1 states the following “UML visual modeling is used in this specification as a visual notation for an underlying graphical predicate model. The underlying model can be given a concrete form in RDF* (https://arxiv.org/pdf/1406.3399.pdf) or a property graph language (e.g. Cypher openCypher_V9). Most of the semantics of the metamodel (except for shortcuts and co-occurrence constraints) can be specified in OWL 2.” Which is not really true since those forms are not actually provided and what is specified is a MOF metamodel, which has different semantics than UML. Though the ODM specification does provide an interpretation and a profile for use of UML for RDF, this has not been referenced in this specification.

Duplicates BACM-44 a proposal to resolve BACM_43

This issue duplicates part of BACM-43 and is resolved by the revision of 7.2.1 proposed in BACM-44.

The first part of Annex B (B1) is irrelevant given the changes made to the implementation of the <<shortcut>> stereotype in both the model and the MOF-compliant XMI. These changes were approved by the Architecture Board and accepted by the DTC. But the required changes to the specification were not made prior to publication.
The second part of Annex B (B2) while technically correct, does not match the model shown in the diagrams. It is planned that this part will be rewritten and submitted as an informative document associated with the specification.
The recommendation is to remove Annex B in its entirety

Remove Annex B from the specification document

Remove Annex B from the specification document. An issue is created to determine the disposition of the Annex B content.

It’s not clear why the “leg” construct is introduced when association classes already exist in UML and have properties instead of legs. As do n-ary associations. Though neither are part of MOF officially, I don’t see the justification of the “leg” terminology.

The term leg is defined in BACM-44 the proposal to resolve BACM-43

The term "leg" is justified because this section of the specification is defining the translation from the UML-based diagrams in the specification to MOF-compliant XMI. Since n-ary associations and association classes are not part of MOF, these forms are translated (reified) into classes and generated associations. The term "leg" designates the generated associations to distinguish them from other associations.
If BACM-44 is approved, this issue should also be resolved

The paragraph state:
For an implementation of the metamodel, the normative XMI that is part of this specification is intended to be an unambiguous and precise way to create an implementation that is equivalent to the underlying graphical predicate model. The non-normative XMI that is provided with the specification must be interpreted according to a set of rules to create a conforming implementation that is not based on MOF.
This paragraph is unclear and refers to a non-normative XMI that is NOT part of the specification.

Replace the second paragraph of 7.2 in its entirety

Replace the second paragraph of 7.2 -
"For an implementation of the metamodel, the normative XMI that is part of this specification is intended to be an unambiguous and precise way to create an implementation that is equivalent to the underlying graphical predicate model. The non-normative XMI that is provided with the specification must be interpreted according to a set of rules to create a conforming implementation that is not based on MOF."
with
"An implementation of the specification must conform to the metamodel expressed in the normative XMI file that is part of the specification. The diagrams in this document make use of stereotypes to eliminate detail that is present in the normative XMI file and make the diagrams more readable. The following paragraphs and subsections in this document explain how to interpret these stereotypes and how they are translated in the MOF-compliant, normative XMI file. In any case where the diagram and the interpretation rules appear to disagree with the normative XMI, the normative XMI is the authoritative source."

This paragraph states:
"In general, metamodel classes in the diagrams in this document will become meta-classes (class prototypes or templates) in an implementation. However, classes stereotyped as “association” will become associationclasses. These entities are binary or n-ary associations that can be specialized (from other meta-associationclasses), have features, and participate in other associations. UML binary associations with a <<class>> stereotype should be implemented as binary meta-associationclasses."
This description is unclear. It mentions association classes that are not part of MOF. It does not adequately describe how to interpret the stereotypes <<class>>, <<association>>, <<shortcut>> and <<individual>>

Attached file replaces 7.2.1 para3 et seq

The description of the translation to MOF is completely rewritten and all paragraphs of section 7.2.1 starting with paragraph 3 are replaced by the attached Word document content.

The last para says “In this case, instances may be created with an arity specified by the user and with instance leg names specified by the user.” but no indication as to how this might be done (such dynamic meta-level property renaming or multiplicity changing is not even part of SMOF).

Add a reference to revised section 7.2.2 in the paragraph of 7.2.4.2

A revision to section 7.2.3 is proposed in BACM-44. This revision explain that some model elements that are instances of metaclasses represent collections of things with identical or similar characteristics (i.e. they are sets defined by the structural properties of the model element). This association allows the modeler to create semantic hierarchies of such model elements.

The XMI file exported from the EA model is not MOF compliant. It includes class-associations and a profile with stereotypes that effectively define cass associations. Additionally, the semantics of "shortcut" stereotypes on associations must be expressed in OCL.

A MOF-compliant XMI file is produced by a transformation program

A Python 3 program was written to input the exported EA XMI file, perform the transformations defined in section 7.2 of the beta specification, and output a MOF-compliant XMI file. This file has been subjected to automated and hand checks for correctness. It has also been analyzed by the OMG XMI compliance tester, producing some minor errors.

It gets further confusing in “the target end of a leg” when early it says that a leg itself can be a “target” (or source).

This issue is resolved by proposal BACM-44 to issue BACM-43

The revisions proposed in BACM-44 explain the "leg" as designating associations generated in the transformation to MOF-compliant XMI that reifies n-ary associations and association classes. The term "leg target" refers to a model element that is at the opposite end of a "leg" association from the metaclass that is generated to represent the n-ary association or class association. A "leg target" may be a generated class resulting from this transformation process. The abstract syntax for this is in Diagram 7.3.1.6 and the transformation description in the proposal BACM-44

· Section 7.2.1 Interpreting… “src” and “tgt” are introduced, but not defined. Relatively trivial as they are not referenced again, but specifying what they stand for in the first instance is a best practice.

Issue duplicated by BACM-43

This issue duplicates the issue in BACM-43 that is resolved by an existing proposal BACM-44.