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.

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?

There is no consensus on the definition of an operating value stream

Nothing in the BACM prevents a modeler from creating a value stream that the modeler would judge to be an operating value stream. However, there is not a consensus on what relationship if any should be expressed or construed between an operating value stream and another value stream that might be considered to be a generalization. A frequently cited case would have a manufacturer of widgets, having a strategic value stream for widget production, decide to create an operating value stream for a specific widget type. The unresolved question is the rules of compliance between the strategic value stream and the operating value stream.

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.

See proposal BACM12-42 for issue BACM12-16

See proposal BACM12-42 for issue BACM12-16

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.

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

Lack of time and resources to create a proposal

This is a major task but other tasks with higher priority have delayed this one. It does not appear that there will be time or resources to submit a meaningful proposal.

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.

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?

Need to augment the path language

The conditions required by this issue are not expressible in the current path language. Assume targets_1 is a shortcut relation from ProductOffering to Customer. A potential shortcut path would be:
targets_1.Customer.customer.ValueCharacteristic.proposition.ValueProposition.aggregates_3.ValueItem.values.Outcome.^incorporates.ProductOffering.targets_1. However, this lacks the additional requirement that the Customer and the LegalEntity that is the acceptor of the ProductOffering be the same. It is not clear how to augment the path language to specify this constraint, which can be expressed in both OCL and in SPARQL.

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?

No consensus solution was reached

The current version of the BIZBOK describes the binding business object, but does not provide a way to identify it that can be expressed as a configuration of BACM metamodel elements. Consequently, the issue is deferred pending new guidance. The business architect who wishes to use this concept can annotate any business object as a binding business object of a value stream

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.

Lack of time and resources to create a proposal

Other issues were judged to be more important than this one. There does not appear to be either time or resources to create a meaningful proposal prior to the end of the RTF.