There are two context methodology proposals that have been made to UCM. In historical order:
- Tree-based - this proposal has a tree-based approach to processing context information (e.g. for context-driven refinement of messages).
- Set-based - this proposal has a set-based approach to processing context information, where the context information is reduced to a list of "leaf" contexts before processing.
The following is an analysis of the differences and gaps of the two proposals, with comments from the original proposers (and possibly from others).
| Issue #
|| "Tree-based" Proposer Comments
|| "Set-based" Proposer Comments
|| Other Comments
|1|| Implementation status
|| "Set-based" proposal has an early prototype software implementation. "Tree-based" proposal does not have an implementation, but is designed to be implementable with open-source software for hierarchical data, e.g. XML/ebRIM/RDF/OWL.
As such, the "Set-based" proposal has undergone more testing than the "Tree-based" proposal, which has as only been tested on a limited set of example use cases.
| The prototype demonstrates a consistent approach of the "set-based" proposal, especially in conjunction with very complex libraries and a high number of users. The implemented technology is based on F-Logic, which can be compared with OWL. It demonstrates also, how the set-based instances can be directly generated into XML, RDF and OWL.
A prototype of the "tree-based" proposal is not known so far. It is aslo not clear how the "tree-based" proposal could work in conjunction with very complex libraries and a high number of members.
|2|| Taxonomy versus Classification
|| The "Tree-based" proposal is based on classification trees and tree comparisons. As such, it can work with classifications, i.e. context models where not all contexts are categorised by one of the leaf nodes of the classification tree. The initial "Set-based" proposal is based on taxonomies (classifications where only leaf nodes are used for classification), which is difficult to apply to cases where it is not possible to assign every context to a leaf (such classifications occur commonly enough in real life situations). "Set-based" believes that their proposal can be modified to operate using all classification nodes, not just the leaf nodes; this needs to be confirmed when "Set-based" have had time to test the impact of such a change.
|| The "set-based" proposal is using a fixed list of taxonomies of leaf nodes. Because it was recognized that the high complexity of the libraries in a repository requires a very complex and consistent theory itself, which is based on set-, graph-, and predicate theories. Especially this theory was much better solvable by usage of taxonomies. Furthermore, it was recognized that the proposed theory can be used for the most requirements in the daily B2B so far. But anyway, this taxonomy can be changed into unique identification system that refers to the nodes in a classification in a tree. By this mechanism nearby all context information could be represented.
It is not clear, how the "tree-based" solutation wants to solve the context classification and methodology in the area of very complex libraries and hierarchies that are build via associations.
|3|| Future-dated Changes
|| The "Tree-based" proposal includes the concept of validity dates for context information. These dates define when particular items of context information should start being used, or stop being used. This means that the context model can contain future-dated changes that be published and loaded into production systems in advance of the actual change. The "Set-based" proposal does not include validity dates, and relies instead on publishing each change to the context model as a separate version which requires a separate update of production systems.
Note that the majority of production systems are not expected to require access to the context model, but systems that want to do run-time context processing are likely to need access to the context model in some format.
| The "set-based" proposal is a very flexible solution, which is based on a very simple metamodel. Especially this metamodel allows a very flexible extension of further context categories. Such categories could be "Version", "Validity Dates", etc. Furthermore, an efficient implementation of the context driver principle requires further investments in production systems. Therefore, we should look, how can we define a very effective methodology that provides all requirements for an efficient context driver principle.
It is not clear, now does the "tree-based" proposal provide the validity dates in very complex library of contextualized ABIEs.
|4|| Code Lists (Context Values)
|| The "Set-based" proposal treats code list (context value) information differently to other context information, while the "Tree-based" proposal treats each code list as the union of a number of contexts, one for each item in the code list, just like any other context. In both proposals , there is an open question around how best to handle having multiple versions of the same code list in the context model, in particular how to associate particular contexts with a particular version of a code list, or perhaps the "latest" version of a code list. The "Tree-based" proposal currently lacks a specific mechanism for including code list metadata (publisher, etc.) along with code list values (context values).
||Agree with the "Tree-based" Proposer|
|5|| Context Logic/Processing
|| The "Set-based" proposal has a context logic (processing methodology) that is based on flattening the context classification tree into a flat list, and processing that list. The "Tree-based" proposal has a context logic which is based on comparison of tree structures. The two approaches appear to often produce the same results (as you would hope), but there hasn't been enough comparison to determine where they might differ in the results they produce.
|| The "set-based" proposal provides a complex context logic in conjunction with the use of an library with ABIEs, BBIEs, ASBIEs, BDTs, Supplementary Components, Identifier Schemas, and Code lists.
The "tree-based" proposal does not provide this kind of context logic so far.
|6|| BIE Qualifiers
|| The "Tree-based" proposal does not provide a mechanism to include BIE qualifiers as part of the context logic (processing). The "Set-based" proposal does (details?), and also recommends that context values should not be used as qualifiers.
This is the general question that UCM has to resolve of when/if context values are used as CCTS qualifiers, or whether (perhaps) context values should never be used as qualifiers.
| The "set-based" proposal recommends to put all information pieces into the context, which provides more flexibility for later use of the ABIE, BDT, and code list libraries. The experience has shown that especially names and qualifiers could differ in diverse contexts.
As the "Tree-based" Proposer said, the "tree-based" proposal does not provide a mechanism.
|7|| Context Serialisation
|| The "Set-based" proposal defines an XML format for context serialisation, based on the XML serialisation for CCTS. The "Tree-based" proposal does not specify an XML format, but the preferred format would be an XML serialisation which has a matching "GRDDL" XSLT stylesheet that can convert the XML into RDF for context processing.
|| The "set-based" proposal considers a syntax independent storage model, which allows a serizalization in many platform dependent syntax representations such as XML Schema, OWL/RDF, XMI, Java Classes, etc. It provides a XML schema serialization that is based on XMLNDR as an example. It does not say, how the syntax independent storage model should be solved. It only provides logic and methdology, which can be implemented in many different ways such as database solution or based on reasoning systems.
The "tree-based" proposal prefers a kind XML serialization with "GRDDL" XSLT stylesheets. But it is recommended, to provide a syntax independent solution as logic and methdology.
|8|| Identifying Contexts
|| The "Set-based" proposal identifies particular business contexts by specifying all of the "leaf" contexts, in each context category, which make up the context. The "Tree-based" proposal implicitly expects that contexts can be identified by context node identifiers; this concept has not been finalised, but the expectation is that a unique name or "path" would be used to identify specific contexts (e.g. so that a particular context can be associated with a BIE).
|9||Workflow||The "Set-based" proposal includes a discussion of workflow. The "Tree-based" proposal does not currently include any information on creation/maintenance workflows for context information, etc.||Agree|
|10|| Context Associations
|| The "Tree-based" proposal allows new kinds of associations (relationships) between contexts to be added to the model. Some of those contexts may be to aid machine processing, some may be purely for the benefit of human users. The "Set-based" proposal only supports the "broader-narrower" relationship .
||Agree, because the main issue of the handling of business context in conjunction with the ABIE, BDT library.|
|11||Add and delete business context at BIEs, BDTs|| The "set-based" proposal has a comprehensive mechansim of adding and deleting context values of ABIEs, BBIEs, ASBIEs, BDTs, Supplementary Components, Code Lists etc. It is based on set logic, cartesian product and graph theory. It allows a consistent context representation of BIE libraries in deep hierachies and provides an implicit consolidation of context sets by the cartesian product.
The "Tree-based" proposal does not provide any mechanisum of deletion and adding context values at BIE libraries.
Note: the issues in the table currently focus on differences between the two proposals, rather than on gaps shared by both proposals (as compared to the UCM requirements).
Question: do we need to be capturing the similarities between the proposals, not just the differences?