Combined Metamodel for UCM Contributed by Anthony B. Coates, Londata 17 February, 2008
17 Feb 2008slide #2Contributed by Londata Limited Models Two model proposals are to be combined Tree-based model Set-based model
17 Feb 2008slide #3Contributed by Londata Limited Tree-Based Model This is a generic, open-ended context- association model Most important association is “broader- narrower” Two important model diagrams – one for contexts, one for associations
17 Feb 2008slide #4Contributed by Londata Limited Tree-Based Model
17 Feb 2008slide #5Contributed by Londata Limited Tree-Based Model
17 Feb 2008slide #6Contributed by Londata Limited Tree-Based Model In the tree-based model, everything is a context This includes context categories, context sets, and individual context values Associations can exist between any pair of contexts, but the most common association is “broader-narrower”; another useful association may be “is identical to”.
17 Feb 2008slide #7Contributed by Londata Limited Set-Based Model The set-based model is less generic, relying on a pre-defined “types” of context (e.g. categories, sets, individual contexts) It shows explicitly how contexts are related to lists of codes and identifiers It shows how contexts are associated with artefacts like BIEs, processes, etc.
17 Feb 2008slide #8Contributed by Londata Limited Set-Based Model
17 Feb 2008slide #9Contributed by Londata Limited Set-Based Model The set-based model supports “broader- narrower” associations via the resursive relationship of “Context Category” to itself (but note, it has been discussed that the recursion needs to be changed to involve “Context Value” as well)
17 Feb 2008slide #10Contributed by Londata Limited Set-Based Model The set-based model allows a context to be assigned to an artefact, where that context can be derived as a union, intersection, or exclusion of other contexts Relies on the close association of context values to codes and identifiers to specify the contexts that are associated with an artefact
17 Feb 2008slide #11Contributed by Londata Limited Set-Based Model The set-based model does not provide a mechanism for storing pre-defined unions, intersections, and exclusions in the context model, for use and re-use by multiple artefacts The advantage of storing derived contexts in the model, and referring to them, is that the derivations can be updated in a single place as necessary
17 Feb 2008slide #12Contributed by Londata Limited Set-Based Model The advantage of being able to attach derivations of contexts directly to artefacts, without storing those derivations in the model, is that the model is not cluttered by derivations that are not re-used between artefacts
17 Feb 2008slide #13Contributed by Londata Limited Differences A key difference in the models, which makes them a little awkward to merge, is that the tree-based model uses a more generic, data-driven model The set-based model uses a more explicit model based on a pre-determined set of classes and associations
17 Feb 2008slide #14Contributed by Londata Limited Differences Generic models are always harder to read as models (you can't understand them full with out details of the data-driven usage), but are more flexible at run-time (fewer assumptions built into structure) Explicit models are easier to read as models, but are less flexible at run-time (more assumptions built into structure)
17 Feb 2008slide #15Contributed by Londata Limited Differences Note that the two proposed models are more similar than they may appear when you look at the models This is because of different choices not only in terminology, but in modelling style We'll try not to let such differences get in the way of merging the models
17 Feb 2008slide #16Contributed by Londata Limited Merging the Models Let's see how we can merge the models From the set-based model, we can immediately take the pieces that are not directly part of the context model itself, but which are important in relating the context model to artefacts, codes, and identifiers
17 Feb 2008slide #17Contributed by Londata Limited Merging the Models In a slight change from the original set- based model, an artefact may or may not have a (business context). If it is not assigned a context, then it has no known business context, and is effectively unusable a (business) context may be shared by multiple artefacts, or may be defined without being assigned to any artefacts
17 Feb 2008slide #18Contributed by Londata Limited Merging the Models We keep code lists and codes, identifier schemes and identifiers We don't need “Code Type” and “Identifier Type”, which are illustrative rather than a necessary part of a run- time model
17 Feb 2008slide #19Contributed by Londata Limited Merging the Models Code list and identifier scheme are special kinds of context union Code and identifier are special kinds of context
17 Feb 2008slide #20Contributed by Londata Limited Merging the Models The merged “context” concept needs to cover context categories, context value sets, and context values A context value set is just a union, so that is covered Context exclusions are essentially identical in both models, at least in terms of the result they produce
17 Feb 2008slide #21Contributed by Londata Limited Merging the Models A context union is broader than each of the individual contexts in the union A context intersection is narrower than each of the individual contexts in the intersection Recommended: A context exclusion is disjoint with any context that is the same or narrower than the excluded context
17 Feb 2008slide #22Contributed by Londata Limited Merging the Models A context value set is either a context union or a context with “narrower” sub- contexts A context union is a context value set for which “completeListIndicator” is implicitly true A context value with sub-contexts is a context value set for which “completeListIndicator” is implicitly false
17 Feb 2008slide #23Contributed by Londata Limited Merging the Models A context category is a special kind of context (i.e. derived from context) It's particular property is that context categories are mutually exclusive, i.e. if context A is in category A' (i.e. there is a direct or indirect “broader-narrower” relationship from A' to A), then context A cannot also be in another category B'
17 Feb 2008slide #24Contributed by Londata Limited Merging the Models Additionally, a category cannot be used as an artefact context, nor as part of a context derivation The sole purpose of a category is to group contexts that are orthogonal to the contexts in other (peer) categories
17 Feb 2008slide #25Contributed by Londata Limited Merging the Models Sub-categories are allowed, and must be orthogonal within their parent category A context category can only be narrower than another context category, not any other kind of context
17 Feb 2008slide #26Contributed by Londata Limited Merging the Models In order to associate artefacts with contexts, it needs to be possible to uniquely reference a context in the model So, to context is added an optional UID Any kind of unique identifier will do; could be XPath-style, or a GUID/UUID, or whatever is most appropriate and usable for the community of users
17 Feb 2008slide #27Contributed by Londata Limited Merging the Models To avoid filling the context model with single-use context derivations, we allow the following, which can't be shown in the model each artefact may have its own private context structure consisting of context unions, intersections, and/or exclusions which are not stored in the context model any other contexts used within these must reference the context model
17 Feb 2008slide #28Contributed by Londata Limited Merging the Models In writing “any other contexts used within these must reference the context model”, it's an open question whether the context model is actually multiple context models E.g. a context might refer to contexts in the CEFACT context model, and also to contexts in a local context model Should all work as long as the UIDs are unique across all context models in use
17 Feb 2008slide #29Contributed by Londata Limited Merging the Models Applying all of these things leads to the following merged model (in two slides):
17 Feb 2008slide #30Contributed by Londata Limited Merging the Models
17 Feb 2008slide #31Contributed by Londata Limited Merging the Models
17 Feb 2008slide #32Contributed by Londata Limited Merging the Models Hopefully, this merged model captures the important features of both proposed models However, your job as reviewers is to ask for further explanation if anything is not completely clear to flag any issues that you see from this particular merging of the models
17 Feb 2008slide #33Contributed by Londata Limited Caveats No internationalisation support is shown in the current model (e.g. names and/or descriptions in different languages), but some support will be necessary