Added by Anthony B. Coates, last edited by Anthony B. Coates on Sep 20, 2007

Labels

 

Objectives (from the project proposal)

Purpose

Context, as a key driver to precisely determine business meaning and intent of information definition and exchange, requires a formal structure and methodology. Although context has been identified as a key component of the UN/CEFACT standard, a formal mechanism for defining and using context has not been in place. With an increasing maturity of a number of standards (CCTS, CCMA, UMM, etc.) that all have strong needs to define and use context, now is the time to form a project to tackle this problem.

The purpose of this project is to develop a methodology and technical specification for developing, registering, and using context drivers as part and for the application of a number of UN/CEFACT standard artefacts, such as Business Data Type, Business Information Entity, Business Message, Business Area, Business Process Models etc. This project will start from the current context mechanism described in the Core Components Technical Specification (CCTS).

This project will be a joint effort between TMG, TBG, and ICG. It will be, however, led and managed by TMG with participation from TBG and ICG members, as context methodology will impact a number of standards artifacts being developed under UN/CEFACT.

Scope

The specification will provide a methodology for assigning context to business information using a number of defined context drivers by advancing the context driver mechanism of the CCTS. The specification will take into account the ongoing work within TMG (UMM collaboration models), ICG (Registry Implementation Specification) and within TBG (Common Business Process Catalogue). The methodology will also include a recommendation for the code lists that can be used to represent context drivers and a proposal of how to maintain these code lists.

The proposed steps to develop the draft specification are as follows:

  1. Review and evaluate current UN/CEFACT standards that are related to and potentially impacted by the context methodology;
  2. Develop a context framework meta-model and a context methodology for the implementation of the meta-model;
  3. For each area (category) of the context meta-model, develop a taxonomy that can be used to populate the eventual context driver value instance. Existing taxonomies it shall be used;
  4. Collaborate with TBG in developing business process related context model and examples;
  5. Collaborate with ICG in registry meta-model and implementation;
  6. Develop first complete draft for review.

Requirements List

Number Category Name Description Comment Contributor Approved?
1 CCTS UCM shall define context for CCTS UCM shall define context concepts as they apply to CCTS. Coates - based on submission of Joe Zhou. [~joe.zhou] Yes
2 CCTS UCM shall define CCTS context methodology UCM shall define a methodology for applying contextual refinements (customizations, extensions, restrictions, etc.) to core components and business information entities. Coates - based on submission of Joe Zhou. [~joe.zhou] Yes
3 Documentation UCM TS shall include extra information for users UCM technical specification document shall include sections covering goals, (sample) use cases, dictionary of terms, implementation recommendations and guidelines etc. in addition to a typical standard specification document. REJECTED - will be deleted. The UCM group will decide, on an on-going basis, on what is the appropriate documentation for UCM. [~joe.zhou] No
4 Model UCM shall include a meta-model UCM shall include a meta-model showing the context concepts. May include appropriate associations, properties, enumerations, and cardinalities. This is to reduce ambiguity and promote common understanding of the context model. [~joe.zhou] Yes
5 Scope UCM shall define scope of related standards UCM shall define the scope of the CCTS related standards that can be contextually refined (e.g. BIE, ACC, BP, etc.) based on assessment of use cases. Coates - based on submission of Joe Zhou.
REJECTED - will be deleted. UCM provides a context mechanism, it does not define scope for standards which use UCM.
[~joe.zhou] No
6 Schedule UCM shall be devloped in phases UCM shall be developed in phases, where phase one will focus on context to CCTS; phase two on context to message assembly, and phase three and beyond on context to business transactions and business process models etc. Coates - based on submission of Joe Zhou.
REJECTED - will be deleted. The UCM group will decide, on an on-going basis, what is the appropriate development scheduling for UCM.
[~joe.zhou] No
7 Migration UCM shall not preclude migration of CCTS contexts UCM shall not preclude migration of existing CCTS contexts to UCM. Coates - based on submission of Joe Zhou. [~joe.zhou] Yes
8 Migration UCM shall specify migration guidelines UCM shall specify migration guidelines from the previous CCTS context driver approach (section 6.2 of CCTS 2.01). Coates - based on submission of Joe Zhou. [~joe.zhou] Yes
9 CCMA UCM shall support assembly of XML Schemas UCM shall support assembly of XML schemas using elements from multiple contexts. Coates - based on submission of Joe Zhou.
REJECTED - will be deleted. XML Schema assembly is an ATG2 function. UCM supports CCMA, not ATG2 directly; CCMA will be the liason point.
[~joe.zhou] No
10 CCMA UCM shall help define how to use context for assembly of artefacts UCM shall work with CCMA to define specifically how to use context for the assembly of artefacts. This requirement is submitted to help refine the scope of UCM, based on whether this requirement is accepted or not.
REJECTED - will be deleted. Subsumed by requirement #22.
Anthony B. Coates No
11 CCMA UCM shall define how to use context for assembly of XML Schemas UCM shall define specifically how to use context for the assembly of XML Schemas. This requirement is submitted to help refine the scope of UCM, based on whether this requirement is accepted or not.
REJECTED - will be deleted. Subsumed by requirement #22.
Anthony B. Coates No
12 Model UCM shall be able to classify contexts UCM shall be able to organize or classify contexts into categories. E.g. geopolitical region, industry. Could be done through taxonomy, ontology, folksonomy (tagging), or other means.
This is to (for example) promote and facilitate reuse of components, and to enable context-driven message assembly.
[~joe.zhou] Yes
13 CCMA UCM shall support context-driven assembly of BIEs UCM shall support context-driven assembly of business information entities using context. Context values from multiple categories and mixed levels of the hierarchies shall be allowed to form a composite context for a given assembly of business information entities. Coates - based on submission of Joe Zhou.
REJECTED - will be deleted. Subsumed by requirement #22.
[~joe.zhou] No
14 Processing UCM shall provide a design-time context mechanism UCM shall provide a mechanism for specifying and applying contextual refinements to supported artifacts at design-time. Coates - based on submission of Joe Zhou. [~joe.zhou] Yes
15 Processing UCM shall provide a run-time context mechanism UCM shall provide an embeddable format for identifying/expressing business context. The format shall be usable for annotating messages with business context information. This could be used to facilitate and/or simplify validation at run time. [~joe.zhou] Yes
16 Model UCM shall define an extension and maintenance method for the context model UCM shall define an extension and maintenance method for the context model. [~joe.zhou] Yes
17 Model UCM shall facilitate governance of context model UCM shall allow and facilitate governance and harmonization of contexts and related artifacts. Coates - based on submission of Joe Zhou.
REJECTED - will be deleted. Subsumed by requirement #19.
[~joe.zhou] No
18 Model UCM shall define how changes to the context model are controlled UCM shall define how changes to the context model are controlled, based on an (externally defined) authority model and process. Coates - based on submission of Joe Zhou.
REJECTED - will be deleted. Management processes are specified by TBG, not by TMG.
[~joe.zhou] No
19 Model UCM shall allow full lifecycle management of the context model UCM shall allow full lifecycle management of the context model. For example, determination of dependencies, facilitation of model merges.
Coates - based on submission of Joe Zhou.
[~joe.zhou] Yes
20 Model UCM shall provide a registry of context models (??) UCM shall provide a registry of context models and relative (??) to other UN/CEFACT standards Coates - based on submission of Joe Zhou.
REJECTED - will be deleted. Registries are the responsibility of ICG, not TMG.
[~joe.zhou] No
21 Dependencies UCM shall minimize dependencies UCM shall structure the methodology and specifications to minimize dependencies on specific implementation technologies and other specifications. Coates - based on submission of Joe Zhou. [~joe.zhou] Yes
22 Integration UCM shall be cohesive with CCTS, CCMA, and BPSS UCM shall have a cohesive approach with CCTS, CCMA, and BPSS, but should be as loosely coupled as possible. Coates - based on submission of Joe Zhou. [~joe.zhou] Yes
23 Documentation UCM shall provide minimal implementation guidance UCM shall provide minimal implementation guidance in order to further understanding, not to prescribe a solution. For example, use of namespaces, packages, and similar mechanisms, if appropriate.
Coates - based on submission of Joe Zhou.
REJECTED - will be deleted. The UCM group will decide, on an on-going basis, on what is the appropriate documentation for UCM.
[~joe.zhou] No
24 Documentation UCM shall specify methodology but not implementation UCM shall define a context methodology, but shall not define how that methodology should be implemented. [~joe.zhou] Yes
25 BPSS UCM shall support context-driven assembly of business transactions UCM shall support context-driven assembly of business transactions to create business collaborations using context, by choosing between contexts that specify refinements to included elements in each applicable category. That is, context drivers, possibly using categories or other organization mechanism.
REJECTED - will be deleted. Subsumed by requirement #22.
[~joe.zhou] No
26 Code Lists UCM shall include a recommendation for code lists UCM shall include a recommendation for specific code lists that can be used to represent context drivers. This requirement is taken from the scope document.
REJECTED - will be deleted. Selection of specific code lists is the responsibility of TBG; it is outside of the methodology scope of TMG.
[~dsh@gs1.dk] No
27 Documentation UCM context mechanism design must follow a well know source of definition for "context" The UCM context mechanism design must follow a well known source of definition for "context", and this definition must be published within the specification(s). UCM or UN/CEFACT can be the source of the definition, as appropriate. [~srh@us.ibm.com] Yes
28 Model UCM context mechanism should not preclude usage with an OMG CCTS MOF Profile The UCM context mechanism should not preclude usage with an OMG MOF Profile defined for CCTS. REJECTED - will be deleted. This was withdrawn; it was agreed that there is no strong current requirement for a MOF profile. [~srh@us.ibm.com] No
29 SBDH Context should be part of SBDH Context should be part of SBDH in order to convey the context of the message to the partner. REJECTED - will be deleted. Subsumed by requirement #15. [~gunther.stuhec] No
30 SBDH UCM shall define context in the SBDH UCM shall define specifically how to specify context in the SBDH. This requirement is submitted to help refine the scope of UCM, based on whether this requirement is accepted or not.
REJECTED - will be deleted. Subsumed by requirement #15.
Anthony B. Coates No
31 Internationalisation UCM should prescribe language for categories/constraints UCM shall prescribe in which language categories/constraints should be defined. This should be done in conjunction with the EBAWG to align with what is done in other UN/CEFACT specifications. In particular, the approach should be aligned with the approach of CCTS. [~gunther.stuhec] Yes
32 Model UCM shall support "broader/narrower" contexts UCM should be able to define which contexts have a "broader" or "narrower" relationship with other contexts. [~gunther.stuhec] Yes
33 Scope Implementation verification shall include serialisation Implementation verification shall include at least one serialisation syntax for the UCM context model. [~gunther.stuhec] Yes
34 Model UCM shall not limit the number of context categories UCM shall not limit the number of possible or allowed context categories (or whatever is the equivalent concept in the UCM context model). [~gunther.stuhec] Yes
35 Code Lists UCM shall define how code lists are used in the UCM context model UCM shall define how code list information is represented and used in the UCM context model. [~gunther.stuhec] Yes
36 Model UCM context model shall support multi-parent hierarchies UCM shall allow for multiple-parent context hierarchies. It may be worth considering how this context model might integrate with relevant external taxonomy/ontology models.group. [~gunther.stuhec] Yes
37 Code Lists UCM shall support multiple code lists for context categories UCM shall support multiple possible code lists for each context category (or whatever is the equivalent concept in the UCM context model). UCM shall specify a mechanism for encoding the active choice(s) of code lists. URIs might be used to specify particular code lists. [~gunther.stuhec] Yes
38 Model UCM shall be able to represent all aspects which make up a particular specific business context UCM shall include a kind of logic that allows the explicit setting of sets of business context categories and valid business context values in order to formally describe the context of a specific artifact' s context. The context logic must allow for specifying exceptions. Example: a specific entity is valid in BP "Purchase Ordering" for all countries without "Germany". The same entity is also valid in BP "Invoicing" if the country is "Germany".
Agreement that need for mathematical/ formal logic approach.
[~gunther.stuhec] Yes
39 Processing UCM shall support selection of artefacts based on business context UCM shall define a context processing model which supports business process role (context role) specific selection and customisation of relevant artefacts, taking into account the specific context aspects of the roles of each participant in a business process. The context processing behavior may consider the qualifiers of ISO 11179 based artifact names. [~gunther.stuhec] Yes
40 Identification UCM shall provide a mechanism for creating namespace URIs based on contexts UCM shall define a method for creating unique namespace URIs based on particular business contexts. This should be done in conjunction with ATG. These namespace URIs can be used for contextually identifying individual sections of XML messages. [~gunther.stuhec] Yes
41 Identification UCM shall define an embeddable format for context representation/identification UCM shall define a format for representing or identifying particular business contexts within messages. This includes the ability to represent the individual context components of a compound (intersection) context. Coates - reworded submission of Gunther Stuhec.
REJECTED - will be deleted. Subsumed by requirement #15.
[~gunther.stuhec] No