BPM+ Knowledge Package Model and Notation Avatar
  1. OMG Specification

BPM+ Knowledge Package Model and Notation — All Issues

  • Acronym: BKPMN
  • Issues Count: 32
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SDMN-127 XSD Chapter Outdated with incorrect text BKPMN 1.0b1 SDMN 1.0b2 Resolved closed
SDMN-123 Update Copyright section BKPMN 1.0b1 SDMN 1.0b2 Closed; No Change closed
BKPMN-32 The name BKPMN is too long BKPMN 1.0b1 open
BKPMN-23 Update SDMN to Reflect SCE's Moving from Vocabularies to KindSets BKPMN 1.0a1 open
BKPMN-16 Simplify SDMNDI based on SCEDI BKPMN 1.0a1 open
BKPMN-15 Simplify BKPMNDI based on SCEDI BKPMN 1.0a1 open
BKPMN-26 There are Editorial Issues in BKPMN Spec BKPMN 1.0b1 open
BKPMN-59 Acknowledgements for KPMN 1.0 contributors needed BKPMN 1.0b1 open
BKPMN-57 Copyright section needs update BKPMN 1.0b1 open
BKPMN-19 Missing Labels on BHMN Metamodel Relationships BKPMN 1.0a1 open
BKPMN-18 Missing Labels on BKPMN Metamodel Relationships BKPMN 1.0a1 open
BKPMN-13 Copy/Paste Errors in BKPMNShape Resolution Section BKPMN 1.0a1 open
BKPMN-14 Editing Error BKPMN 1.0a1 open
BKPMN-1 Fig 1 does not render properly in PDF BKPMN 1.0a1 open
BKPMN-21 BKPMN metamodel is not valid MOF BKPMN 1.0a1 open
BKPMN-31 Clarify constraints on BKPMN Import inherited from SCE Import BKPMN 1.0a1 open
BKPMN-30 Refactor BKPMN XSDs based updated method of translating from UML Metamodel Diagrams BKPMN 1.0b1 open
BKPMN-29 Fix OperationalDocumentRef properties mismatching issues BKPMN 1.0b1 open
BKPMN-25 Remove extraneous metadata elements and properties from BKPMN BKPMN 1.0b1 open
BKPMN-22 Update BKPMN to Reflect SCE's Moving from Vocabularies to KindSets BKPMN 1.0a1 open
BKPMN-20 Update the Spec to indicate a separation of the Parties Model from PPMN BKPMN 1.0b1 open
BKPMN-12 PackageElement over-specified? BKPMN 1.0a1 open
BKPMN-11 classes BKPMNPackageInputs and BKPMNPackageOutputs appropriate at BKPMN level? BKPMN 1.0a1 open
BKPMN-10 Class Applicability - various BKPMN 1.0a1 open
BKPMN-9 Better name for Measure class? BKPMN 1.0a1 open
BKPMN-8 Class ImpactKind appropriate at BKPMN package level? BKPMN 1.0a1 open
BKPMN-7 Effect semantics unclear BKPMN 1.0a1 open
BKPMN-6 KnowledgeElement subclassing approach fragile? BKPMN 1.0a1 open
BKPMN-5 BKPMNInstances semantics BKPMN 1.0a1 open
BKPMN-4 BKPMNModel attributes - various. BKPMN 1.0a1 open
BKPMN-3 BKPMNModelPackage attributes may be difficult to maintain and understand in data and software. BKPMN 1.0a1 open
BKPMN-2 Some BKPMN classes over-specified? BKPMN 1.0a1 open

Issues Descriptions

XSD Chapter Outdated with incorrect text

  • Key: SDMN-127
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    XSD Chapter Outdated with incorrect text that was copied from the DMN specification.

  • Reported: BKPMN 1.0b1 — Wed, 31 Jan 2024 23:54 GMT
  • Disposition: Resolved — SDMN 1.0b2
  • Disposition Summary:

    Fix text in XSD Chapter

    Update class names and element names and refer to QNames instead of href (as how BPMN and CMNN handles this).

  • Updated: Mon, 17 Jun 2024 13:39 GMT

Update Copyright section

  • Key: SDMN-123
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Update copyright section
    Update the years of contribution based on OMG-recognized contributors and taskforce membership.

  • Reported: BKPMN 1.0b1 — Sat, 27 Jan 2024 23:52 GMT
  • Disposition: Closed; No Change — SDMN 1.0b2
  • Disposition Summary:

    Close no change

    This issue was accidentally added to SDMN. So close no change.

  • Updated: Mon, 17 Jun 2024 13:39 GMT

The name BKPMN is too long


Update SDMN to Reflect SCE's Moving from Vocabularies to KindSets

  • Key: BKPMN-23
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    SCE is replacing the SCEVocabulary element with the SCEKindSet element (and related elements).
    SDMN uses the vocabulary mechanism and thus will need to be updated appropriately.

  • Reported: BKPMN 1.0a1 — Tue, 11 Oct 2022 16:59 GMT
  • Updated: Thu, 11 Apr 2024 12:54 GMT

Simplify SDMNDI based on SCEDI

  • Key: BKPMN-16
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Update the spec, metamodels, and xsds.

  • Reported: BKPMN 1.0a1 — Tue, 3 May 2022 20:32 GMT
  • Updated: Thu, 11 Apr 2024 12:54 GMT

Simplify BKPMNDI based on SCEDI

  • Key: BKPMN-15
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Update the spec, metamodels, and xsds.

  • Reported: BKPMN 1.0a1 — Tue, 3 May 2022 20:27 GMT
  • Updated: Mon, 29 Jan 2024 15:11 GMT

There are Editorial Issues in BKPMN Spec

  • Key: BKPMN-26
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    This issue will collect all the typos and resolve them in one issue for Ballot 1.

  • Reported: BKPMN 1.0b1 — Tue, 15 Nov 2022 23:25 GMT
  • Updated: Sun, 28 Jan 2024 00:19 GMT

Acknowledgements for KPMN 1.0 contributors needed

  • Key: BKPMN-59
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The acknowledgement section contains information from the RFP, but not the FTF

  • Reported: BKPMN 1.0b1 — Sun, 28 Jan 2024 00:06 GMT
  • Updated: Sun, 28 Jan 2024 00:06 GMT

Copyright section needs update

  • Key: BKPMN-57
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Update copyright section
    Update the years of contribution based on OMG-recognized contributors and taskforce membership.

  • Reported: BKPMN 1.0b1 — Sat, 27 Jan 2024 23:56 GMT
  • Updated: Sat, 27 Jan 2024 23:56 GMT

Missing Labels on BHMN Metamodel Relationships

  • Key: BKPMN-19
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    to be MOF compliant

  • Reported: BKPMN 1.0a1 — Mon, 18 Jul 2022 19:48 GMT
  • Updated: Sat, 27 Jan 2024 23:25 GMT

Missing Labels on BKPMN Metamodel Relationships

  • Key: BKPMN-18
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    to be MOF Compliant

  • Reported: BKPMN 1.0a1 — Mon, 18 Jul 2022 19:48 GMT
  • Updated: Sat, 27 Jan 2024 23:24 GMT

Copy/Paste Errors in BKPMNShape Resolution Section

  • Key: BKPMN-13
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The first sentence in the section lists the SCE Diagram shapes, not the BKPMN Diagram shapes.
    The sentence above Table 67 and the header for Table 67 use the term "Data Items" (from SDMN), but should say "BKPMN Diagram Elements"

  • Reported: BKPMN 1.0a1 — Tue, 26 Apr 2022 17:14 GMT
  • Updated: Wed, 17 Jan 2024 18:20 GMT

Editing Error

  • Key: BKPMN-14
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Text in the description doesn't match the contents of the section. There are too many items referenced.
    The text "BKPMNEdge can be used to represent an Ownership Connector, Parent-Child Connector, Relationship Connector, or a Data Association." includes elements not in the section. Only the Relationship Connector is in the section.

  • Reported: BKPMN 1.0a1 — Mon, 2 May 2022 17:12 GMT
  • Updated: Wed, 17 Jan 2024 18:16 GMT

Fig 1 does not render properly in PDF

  • Key: BKPMN-1
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Both background and some arrows (e.g. BPMN -> DMN) are black or near black.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:27 GMT
  • Updated: Wed, 17 Jan 2024 18:16 GMT

BKPMN metamodel is not valid MOF

  • Key: BKPMN-21
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It has unnamed Associations and Properties which are not permitted

  • Reported: BKPMN 1.0a1 — Mon, 22 Aug 2022 03:48 GMT
  • Updated: Wed, 17 Jan 2024 18:10 GMT

Clarify constraints on BKPMN Import inherited from SCE Import

  • Key: BKPMN-31
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The spec doesn't clearly specify the constraints on the types of items that can be imported for a BKPMN model.

  • Reported: BKPMN 1.0a1 — Sat, 28 Jan 2023 00:02 GMT
  • Updated: Sat, 28 Jan 2023 00:02 GMT

Refactor BKPMN XSDs based updated method of translating from UML Metamodel Diagrams

  • Key: BKPMN-30
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The current BKPMN XSDs were developed with a faulty translation of UML class relationships to the XSD elements.
    To resolve this issue we need to specify the XSD patterns that correspond to the UML class relationships and then update the XSDs.

  • Reported: BKPMN 1.0b1 — Tue, 17 Jan 2023 22:58 GMT
  • Updated: Tue, 17 Jan 2023 22:58 GMT

Fix OperationalDocumentRef properties mismatching issues

  • Key: BKPMN-29
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    OperationalDocumentRef properties are mismatched between the metamodel diagrams, the descriptive table, and the XSD

  • Reported: BKPMN 1.0b1 — Tue, 15 Nov 2022 23:46 GMT
  • Updated: Tue, 15 Nov 2022 23:46 GMT

Remove extraneous metadata elements and properties from BKPMN

  • Key: BKPMN-25
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    BKPMN has a lot of metadata intended to provide information about the contents of the package (i.e., the label on the box). All the metadata elements should be reviewed with the goal of simplifying the V1.0 version of the spec and to include only the essential metadata.

  • Reported: BKPMN 1.0b1 — Wed, 9 Nov 2022 16:34 GMT
  • Updated: Thu, 10 Nov 2022 18:50 GMT

Update BKPMN to Reflect SCE's Moving from Vocabularies to KindSets

  • Key: BKPMN-22
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    SCE is replacing the SCEVocabulary element with the SCEKindSet element (and related elements).
    BKPMN uses the vocabulary mechanism and thus will need to be updated appropriately.

  • Reported: BKPMN 1.0a1 — Tue, 11 Oct 2022 16:59 GMT
  • Updated: Tue, 11 Oct 2022 16:59 GMT

Update the Spec to indicate a separation of the Parties Model from PPMN

  • Key: BKPMN-20
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    And to make clear that Parties is a component of the knowledge package.

  • Reported: BKPMN 1.0b1 — Tue, 9 Aug 2022 23:22 GMT
  • Updated: Wed, 10 Aug 2022 09:16 GMT

PackageElement over-specified?


classes BKPMNPackageInputs and BKPMNPackageOutputs appropriate at BKPMN level?

  • Key: BKPMN-11
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    I would expect to see formal models of these classes at the BPMN/CMMN levels, and / or SDMN, and for BKPMN possibly to just have the ability to extract a total set of data items from the constituent plans.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 16:04 GMT
  • Updated: Mon, 25 Apr 2022 13:34 GMT

Class Applicability - various

  • Key: BKPMN-10
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    The section header is 'Determining Applicability' - is this correct?

    According to the documentation, Applicability appears to be a computational model of entry or pre-conditions to be matched when determining applicable plans at runtime. Such conditions would normally be defined on the plans themselves. I would expect just a documentary description of applicability at the BKPKMN package level.

    I would expect to see a process like that shown in Figure 18 (Process for Determining the Applicability of a BKPMN Package) to be defined in BPMN and CMMN, not BKPMN.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 16:02 GMT
  • Updated: Mon, 25 Apr 2022 13:34 GMT

Better name for Measure class?

  • Key: BKPMN-9
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Based on the documentation, 'Metric' would be a more obvious name for this class. The word 'Measure' is usually associated with units of measure.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 16:01 GMT
  • Updated: Mon, 25 Apr 2022 13:34 GMT

Class ImpactKind appropriate at BKPMN package level?

  • Key: BKPMN-8
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Similar comment as for Effect - is this really relevant at the BKPMN package level, rather than at the level of constituent plans?

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:59 GMT
  • Updated: Mon, 25 Apr 2022 13:33 GMT

Effect semantics unclear

  • Key: BKPMN-7
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    It is not clear why a BKPMN package would need 'Effect' elements - are they meant to document post-conditions of the execution of a BPMN plan? If so, they should be built into the plan definition, not into the containing package. A containing package could have more than one plan...

    Description says: An Effect is some change to the environment or data that may occur when the behaviors of BPM+ Knowledge Package is performed. The bold part implies that a change in pretty much anything can be an 'effect'. Possibly something like 'change to a state variable within the case (entity or system) on which a workflow is executing' might be better.

    Attributes like eventRef, impactKindRef etc would seem to be replicating what are likely to be goals or post-conditions stated within BPMN or CMMN plans contained within a BKPMN package. Is this the intention? If multiple plans are grouped together in one BKPMN package, is the set of events/milestones, impacts etc obtained by summing all such elements from the constituent plans?

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:58 GMT
  • Updated: Mon, 25 Apr 2022 13:33 GMT

KnowledgeElement subclassing approach fragile?

  • Key: BKPMN-6
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    The approach to defining kinds of knowledge element using subclassing seems likely to be fragile in the longer term - each time a new subtype is needed, the standard has to be re-issued. I don't see any obvious logic or theoretical basis for the collections of types Applicability, Effect, LifecycleEvent, Measure, RiskFactor, and Recommendation.

    It seems to me that Applicability, Effect, Impact, etc should just be kinds of documentation rather than structurally modelled items. And they probably should not be fixed either - different BPMN / CMMN plans will have different ways of documeting things.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:56 GMT
  • Updated: Mon, 25 Apr 2022 13:33 GMT

BKPMNInstances semantics

  • Key: BKPMN-5
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    It is not clear from the description of this class what the purpose of 'instances' in a BKPMN package is. If the model were a BPM+ workflow + DMN logic, are the instances example (or real) runs?

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:55 GMT
  • Updated: Mon, 25 Apr 2022 13:33 GMT

BKPMNModel attributes - various.

  • Key: BKPMN-4
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Class BKPMNModel attributes:

    purpose: has its own type Purpose. Couldn't the purpose be included in inherited documentation? I would have expected that there could have been an attribute SCEElement.purpose: Documentation might have been just as good, and one less class.
    manifest: is the manifest not generatable from the structure? Maintaining a separate documentary manifest is likely to duplicate and become inconsistent w.r.t. the Model structure.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:36 GMT
  • Updated: Mon, 25 Apr 2022 13:32 GMT

BKPMNModelPackage attributes may be difficult to maintain and understand in data and software.

  • Key: BKPMN-3
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Class BKPMNModelPackage has 6 attributes in addition to those inherited from SCEModelPackage. Is it clear that these attributes are not more generally applicable, and could be included at the SCE level?

    Attributes:

    completed: might not be easy to maintain; the approach we use is semver.org, and sub-v1.0.0 versions for drafts, and for later major versions, v2.0.0-rc17 versoin strings.
    published: attribute likely to be difficult to maintain. The rules for maintaining this attribute value in sync with the version and versionDate attributes are somewhat arcane.
    jursidiction: This attribute defines the countries or other areas (such as states) where the BKPMNModelPackage is in effect.
    likely to be problematic to keep up to date. Attributes to do with use of models should not normally be in said models
    effectivePeriodStard, effectivePeriodEnd: for similar reasons, likely to be difficult to establish values and difficult to maintain over time.

    It would appear from the documentation that the completed, published, version and versionDate attributes are really trying to express phases of an artefact lifecycle, but in a complex way. It would be much better to create a lifecycleState attribute and define its state machine. A model for doing this can be found at https://specifications.openehr.org/releases/AM/latest/Identification.html#_lifecycle_model (openEHR Archetype Identification specification).

    With respect to the effectivePeriodxx attributes, what does 'in effect' mean? For whom? Org A may stop using a particular package, while Org B uses it for another 2 years. Or is the idea that the dates are set centrally? By whom?

    Generally speaking, an approach that explicitly models lifecycleState, and incorporates release management (i.e. the idea of target publishable versions), plus a disciplined version naming scheme based on semver.org will probably work better than trying to maintain the above attributes within instance data.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:34 GMT
  • Updated: Mon, 25 Apr 2022 13:32 GMT

Some BKPMN classes over-specified?

  • Key: BKPMN-2
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Fig 5 UML - classes like OrderSetHandlerRef, QuestionnaireHandlerRef, DevelopmentMethod seem very specific and possibly project / context specific. Is the BKPMN model reaching a bit too far in its early stages?

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:30 GMT
  • Updated: Mon, 25 Apr 2022 13:32 GMT