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.

Duplicates BACM12-36

Duplicates BACM12-36

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.

Add statecharts-like metamodel elements

The proposal creates a new subtype of Outcome, named Region, that is associated to AbstractCapability, AbstractProcess, or ValueStreamStage by a reified relation named "during". Region aggregates AbstractCapabilities, AbstractProcesses, ValueStreamStages and Outcomes. An implementing tool must also aggregate needs/produces, inputs/outputs, or entry/exit criteria that relate the aggregated elements. The result should create in each Region, a network that describes behaviors in terms of Outcomes linked by AbstractCapabilities, AbstractProcesses or ValueStreamStages. For completeness, the Outcomes needed and produced by the AbstractCapability, AbstractProcess, or ValueStreamStage, whose behavior is being described by "during" related Regions, should also be part of the network in some of these Regions. Regions may be decomposed and the child Regions are presumed to behave independently unless they create Outcomes that are consumed in another region; such a creation/cunsumption relation implies a point of synchronization between the Regions.
The effect of these changes is to allow a lightweight statecharts model to be used to describe behaviors.

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.

Changes to prose in 7.2.1.6 and 7.2.3

Delete 7.2.1.6.
Make changes to 7.2.3 as revised

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.

Change 7.2 to clarify aggregational semantics of reified and non-reified relations

Change text in sections 7.2.1.2, 7.2.1.3 and 7.2.1.4 to explain that these relations have the semantics of aggregation and should not be interpreted as composition or specialization.

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.

Add bacm_model:abstract owl:AnnotationProperty

Change BACMMOF2OWL.py make_class to determine if the isAbstract element is present with a value true. If so, generate an annotation property assertion in the class of bacm_model:abstract true . otherwise generate bacm_model:abstract false.

See RegulatoryAgencies ontology in commons for examples.

Make changes to the software that generates the TTL file

Add code to the software that generates the TTL file to generate equivalent TTL sentence for the BACM 1.2 metamodel.

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.

Define an annotation property to link an element to its meta-element

Specifically, define http://www.omg.org/spec/BACM/20230501/BACM_Model/meta as an owl:AnnotationProperty in the default definitions for the metamodel. Tool makers are advised to make the IRI definition available by generating an import BACM statement in any model using the BACM as a metamodel. Tool makers are also advised to generate both this annotation property and a subclass/subproperty statement when creating a model element from a metamodel element.

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'

Change BACM_Entities diagram and correct other diagrams

In ValueModel:
Rename AbstractValueModel to AVM
Add new class named AbstractValueModel
Move the notes from AVM to AbstractValueModel
Add the following note to AVM:
Definition: AVM is an abstract superclass whose purpose is to complete the specialization hierarchy and to simplify the BACM_Entities diagram.
AbstractValueModel generalizes AVM
Change ValueCharacteristic generalization from AVM to AbstractValueModel
Change ValueCharacteristic_1 generalization from AVM to AbstractValueModel

In Strategy:
Add AbstractValueModel to diagram
Change baseline_1 association from AVM to AbstractValueModel
Change baseline_3 assocation from AVM to AbstractValueModel
Delete AVM from the diagram
Make AbstractValueModel abstract

In BACM_Entities:
Add AVM generalized by BACMPlainEntity
Add JSTP generalized by BACMPlainEntity
Add VSVSS generalized by BACMPlainEntity
Remove BACMPlainEntity generalizes BusinessObject
Add AbstractBusinessObject, generalized by BACMPlainEntity
Remove BACMPlainEntity generalizes InformationItem
Remove InformationItem

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.

Corrent BACMMOF2OWL.py to generate proper statements

The code in BACMMOF2OWL.py to generate OPRs and DPRs did not distinguish when a class restriction was present and generate the proper predicates for the quantification statement. The program logic should be changed to distinguish when a class restriction is present and use the appropriate quanitification predicates.
Changes made and tested

The software rule to translate this UML XMI datatype specification was omitted from the primitive types translation dict in BACMMOF2OWL.py

Add a trule to translate this UML type

Add a rule to translate 'http://www.omg.org/spec/UML/20131001/PrimitiveTypes.xmi#Integer' to 'xsd:integer'.

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.

Add a test in make_qname to correct this

Add test to make_qname to not prefix the source class name to an association of the name of the unstereotyped association contains 'owns'. The owns_4 association is a unique case because the association is represented in the UML as an association stereotyped class, and the source qualification rules would apply, except that owns is a special association used in the UML to indicate that the existence of the target is dependent on the existence of the source.

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.

Merged with BACM12-8

This proposal is merged with BACM12-8 which also fixes the issue fixed by this proposal.

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.

Fix bug in BACMMOF2OWL.py parse_comment function

A logic mistake in the parse_comment function was failing to generate the skos:definition statement except when a usage note was also present in the ownedComment body.