The 1.1b1 model no longer has theBusiness as an <<individual>> stereotyped class, and the <<individual>> stereotype has been removed. All classes now represent sets of individuals.

The BACM 1.1b1 document does not explicitly state that the semantics of all reified relations is aggregation, leading to a possible interpretation of these relationships as ownership or specialization. The BACM 1.1b1 document explicitly provides simple relations of specialization, composition and aggregation. All simple associations and all stereotyped associations should be interpreted as aggregations only.

The 1.1 documentation does not specify that semantics of specialization or ownership do not apply to reified relations. This can be resolved by altering the description of BACMRelation to state that the semantics prohibit a semantic interpretation of composition or a semantic interpretation of specialization.

In prototyping the Guild transportation reference model, it became apparent that the 1.1 metamodel does not support the notion of outcomes associated with the execution of value stream stages or abstract capabilities. For example, safety and comfort of the traveler are outcomes that have high value in the value proposition, They are continuously associated with the enroute stage of the value stream and are not appropriately characterized as exit-criteria, which are outcomes associated with the ending of the stage.
Such outcomes should be associated with capabilities such as conveyor operations to indicate that the outcome is in force throughout the exeuction of the capability.

See RegulatoryAgencies ontology in commons for examples.

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.

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.

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 software rule to translate this UML XMI datatype specification was omitted from the primitive types translation dict in BACMMOF2OWL.py

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.

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.

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.