The translation of MOF XMI to TTL incorrectly assigns ownership of the owns_4 association to ValueCharacteristic as ValueCharacteristic.owns_4. The translation program uses a heuristic - if an association is sourced at a class that is a subclass of BACMRelation, it is treated as a leg of that class and given a name that is <class_name>.<association_name>. Associations named "owns", "aggregates" or "generalizes" should be excluded from this heuristic as they have fixed semantics (composition, aggregation, specialization) that are not conditioned by the relationship class semantics. Thus has appeared in the TTL as "ValueCharacteristic.owns_4", which should be named "owns_4".
This change does not affect the specification document, the EA model or the MOF XMI.

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?

The BIZBOK introduces the notion that value streams include the concept of a binding business object(s) whose state, together with entry and exit criteria controls the sequencing of value stream stages. How should BACM represent this concept? Is it explicit in the metamodel, or is it the result of analysis or some combination of these?

In MOF, the instance association represents the relation between a meta-entity and its model instances. BACM allows model instances to be classes and associations, effectively making an instance a specialization of the meta-entity. BACM also allows the modeler to create specialization relations between model elements.
To support the metamodeling notion in OWL-based tools, it is necessary to be able to distinguish specialization created by the modeler from meta-entity specialization that is created by the tool, e.g. when creating a model instance of the meta-class "Capability". The instancing process in a tool can be complex. For example, instancing a BACMBinDirRelation such as "expects_o" requires the creation of a subclass of "expects_0" (and noting that it is a meta-class relation), and creating two ObjectProperties that are sub-ObjectProperties of "expects_0.to_expects_0" and "expects_0.from_expects_0". The tool should prevent the modeler from changing any of the these specialization relations or to deleting any of the created elements. The tool should only allow the modeler to delete the entire instance or to add axioms and assertions that do not change the semantics of the instance with respect to its meta-entity. Consequently, the tool must be aware of these specializations.

Abstract elements are not allowed to be instantiated. The MOF metamodel for BACM marks such elements as "abstract" but this information is not carried over to the Owl ontology, leading users to think that it is proper to "instance" (specialize) elements that should not be specialized directly; instead one of the concrete subclasses of the element should be used.

LegalEntity has an ownedComment in the XMI that should have resulted in annotation axioms in the RDF Turtle, but the annotation axioms are not in the generated .ttl file.

See RegulatoryAgencies ontology in commons for examples.

The following classes should specialize BACMPlainEntity but do not:
'bacm_cap:AbstractBusinessObject',
'bacm_cust:Customer',
'bacm_cust:ValueItem',
'bacm_org:OrgUnit',
'bacm_cust:JSTP',
'bacm_org:LegalEntity',
'bacm_cust:ValueProposition',
'bacm_cust:CustomerSegment',
'bacm_org:Performer',
'bacm_prod:APCICB',
'bacm_model:AbstractThing',
'bacm_proc:VSVSS',
'bacm_org:System'

The translation of the MOF model to OWL is generating owl:onClass statements when the restriction quantification assertion does not require them, Some ontology editors and classifiers will ignore these statements, but not all.

The translation of the MOF metamodel into OWL is generating owl:onDataRange statements when the restriction type is not qualified. Many tools will ignore this error, but some will not.

The current draft provides OutcomeRelation as a template for the model level definition of relations between outcomes. Recent work on entry and exit criteria for value streams as well as capability and process flows has informally used logical relationships that instance/specialie OutcomeRelation and effectively define an Outcome that is the logical union or other Outcomes. The issue is whether the metamodel should define a set of specifically logical relations. For example include, exclude, include complement could be used to create an Outcome by conjunctive composition where the semantics of the Outcome is the union of all facts from included Outcomes, no facts from excluded Outcomes (i.e.not known whether these are true or false), complement facts from included complement Outcomes. This is just an example; specific proposal to be worked out.

The ability to associate products with customers is important. In the current metamodel, this connection can only be made by joining a customer targeted by a value proposition with a product offering where the value proposition is of the product offering. Should the metamodel include a direct relationship between product offering and customer? Should this relationship be a shortcut?

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

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.