Adding this specialization would open a lot of other connections to Capabilities (e.g. that produce Offerings)

The abstract syntax of this allows for value fit between value item and customer segment to be rolled up into an overall value fit between the value proposition and the customer, but it permits a lot of nonsense constructions as well. Consider splitting ValueCharacteristic into two parts: one between ValueProposition and Customer, and the other between ValueItem and CustomerSegment and have the latter owned by the former.

Consider whether/how to implement this concept which is defined in the BIZBOK and the Guild Metamodel whitepaper.

The target of isAbout is currently restricted to BusinessObject but should be broadened to any concept in the AbstractOperatingModel or AbstractValueModel (except abstract constructs such as ValueStreams and Capabilities as those are documented in the business architecture model)

Consider Capability supports ValueStreamStage as the shortcut, justified by Capability producing Outcome valued by ValueItem produced by ValueStreamStage. This avoids a shortcut whose definition falls outside of the Customer package and would put it in the Capability/ValueStream crossmap package (per BACM11-9).

JSON is an increasingly popular serialization format. JSON-LD provides some key additional capabilities.

Current name can be confused with "provider" association that links Outcome with LegalEntity. This association links LegalEntity with Offering. Affects all product diagrams.

The justification for namespaces is to permit parts of the model to be used independently. The current packaging is close, but crossmaps between value stream and capability are defined in Capability and crossmaps between ValueItem and Outcome are defined in Customer. Customer mixes together Journeys and Value Streams. Consider repackaging to eliminate crossmaps from the core packages and add new packages with just the crossmaps. This would also benefit use of the OWL as a group of ontologies instead of one large one.

BACM has this as an association prototype with semantics of inheritance between instances (that are also classes) to conform to MOF. RDFS already has the subClassOf and subPropertyOf predicates and generalizes_0 should be translated into one of these predicates.

The MOF XMI owns_0 association is translated to an owl:ObjectProperty that is used with appropriate cardinalities in object property restriction axioms. But there is nothing that indicates that the association and its object property restrictions should have the cascading delete semantics. In the MOF2RDF specification, this is indicated by marking the object property as a subproperty of a "well-known" object property named "hasPart". The OWL version of BACM should follow this pattern.

Policy is a common business concept. It is specified in the BIZBOK. Policy is also defined in the BMM.

This association between Outcome and AbstractBusinessObject is undocumented. The association documentation is in generated material and several sections will be regenerated.

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.

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.

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.

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.

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.