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)

Many ontology programs rely on or optionally support "rdf:label" for the display label in lieu of using the actual URI. This is recommended practice.

The BACM allows definition of an Outcome that is needed by a Capability and/or is an entryCriteria for a ValueStreamStage. Such an outcome can often be identified with a causation agent that is external to the organization. A modeler could resolve this by inventing a Capability (e.g. responsible for having a Customer create an order for a Product) that is in the external stakeholder environment and not in the enterprise environment. Alternatively, a new association could be created allowing such Outcomes to be associated with a Performer and indicating causation.

For versioning analysis, it is useful to have stable UUIDs for each element in the metamodel. These appear in the XMI and are used to link together elements of the metamodel. They are also in the EA UML model, but are not typically shown to the modeler. The properties of an element may change in editing, but the UUID does not, allowing change analysis to be performed on different versions of the metamodel. The OWL generation did not include the element UUIDs.

In the OWL, namespaces were translated as IRI segments. Object properties and datatype properties were considered to be in the namespace created by their owning class (class stereotyped associations are reified in the translation to XMI and OWL). This made the use of qnames infeasible as the name part of the qname cannot contain multiple segments. Yet simple names cannot be used in the XMI or OWL because of name conflicts that are resolved by including the owning class namespace.

When the association names were suffixed to avoid duplicate names, some of the shortcut PathSpecification tag values were not updated. The program that generates the MOF XMI file was not reporting the validation failures because of a programming error.

ValueStreamStages are commonly ordered in display.
There is a question about whether this implies an operational ordering that disallows temporal overlap and what semantics this ordering might be based on. This issue also relates to BACM11-3 concerning entry and exit criteria for ValueStreamStages.
There is also a technical issue. UML allows for ordered associations. In practice these involve tagging links with an ordering value that is used to control the order in which links are iterated. This is also permitted in MOF. However, the actual ordering cannot be specified for the meta-model elements, only for their instances (which are the model classes).
One solution would be to add a property to the ValueStreamStage whose value controls the ordering. However, MOF properties are typically translated to OWL as DatatypeProperties and have semantic consequences for individuals. A better solution for OWL would be to define an AnnotationProperty that either orders ValueStreamStages directly or defines an ordering value. This implies a UML/MOF Comment attached to each ValueStreamStage, whose body contains a predefined keyword and an ordering value. Alternatively, a Comment could link to two ValueStreamStage instances and specify the ordering relation between them.

Some organizations have developed what they call operating value streams. Sometimes these arise from application of "Lean" methdology. But, they may also arise from a desire to model the creation of value associated with particular product lines and analyze those representations of value with respect to the generic models of value creation provided by value streams.
Specialization of value streams and stages is disallowed by the BIZBOK (to avoid the common methodological mistake of conflating value streams and processes). Is there a need for operating value streams? Is there a way to represent this that does not violate the BIZBOK?

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.

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

The addition of entryCriteria linking Outcome to ValueStreamStage appears to eliminate the need for the triggers association, since triggering is one of the functions subsumed by the entryCriteria relation and would imply the existence of an identical entryCriteria relation.

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.

A frequently used matrix showing relations between product value items and capabilities can be created by query on the model. Adding a shortcut to the metamodel would allow the architect to specify intent that such a relationship exists in advance of actually creating the details in the model.

See summary

Shortcut constraints appear to be duplicated. This is not the case in the UML model, so the problem appears to be in the program that converts the EA XMI export to MOF XMI.

In MOF metamodeling, OCL and other constraints apply to instances. In the BACM, these instances are also classes and inherit from their meta-classes (same for associations). In the translation to OWL, there is no instance/metaclass association and no mechanism (other than punning) that is useful. The instance model in OWL is created by specializing the BACM base model. E.g. VS is a specialization of ValueStream and VSS is a specialization of ValueStreamStage. But [VS owns VSS] must be stated for VSS to exist and [VS1 owns VSS] may not be stated for VS1 not equivalent to VS. This is a requirement on the ontology maintainer, not a requirement on the individuals that can be addressed by an OWL reasoner.

The BACM uses Outcomes to connect AbstractCapabilities, AbstractProcesses and (with BACM11-22) ValueStreamStages. These Outcomes may imply ordering relationships between these activity meta-concepts. In addition, architects often want to define high level processes and workflows to associate with ValueStreams. Should the BACM define an ordering semantic and provide guidance on how to use it? What would the ordering semantic look like.

Having this axiom explicit means that these classes can never be made subordinate to an ontology that is reusing the BACM ontology (e.g. such as an integrating or bridging ontology).

The turtle file currently uses the old, insecure http protocol and per SMSC policy must use https.

The resolution to this issue mainly impacts the machine-readable turtle file and should not impact the specification document aside from any place where the URI for the turtle file is mentioned.

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

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.

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.

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

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.

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.

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.

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.

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

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

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

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).

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.