1. UCM 2009 Vision Scott R. Hinkelman

2. Architecture and Glossary Goal will be to have the Architecture document and Glossary essentially completed “in content” coming out of Waldorf Scott (and others) is late in providing words in specific areas and will forwarding info on this The Architecture document is high level and does not drill down enough into each dimension to show specifics This is not bad Given our scope, complexity, importance, and organic approach to spec building we need to consider staging the function to insure productivity increase. I am proposing my vision in the form of a Roadmap But not another established UCM document

3. Spec1 - Context Scheme Framework (CSF) We have good work on the table in modeling - but spanning several areas UCM will be robust according to the architecture and use cases so we need a staging mechanism to attack each piece UCM Roadmap does not change what we are working on – only stages it Context Scheme Framework (CSF) – this will be the spec for the profile work (note: I am suggesting to move way from ‘classification scheme’ terminology) In the form of a UML profile, it primarily it defines: basic admin information for any Context Scheme metamodel the type for Context Value (the code, ID, String discussion) an abstract Context Point representing a place for value relationships An abstract Thing (don’t know what to call it) that replaces ‘Classifiable’, which represents the Thing which can be ‘in context’ or ‘have context assigned to’. It does not define what the relationships (tree nodes, tables, etc) are between the values Any grammar or expressions – since these are specific to aligning schemes It permits Positioning for future consistency with other CEFACT UML Profiles Multiple Context Schemes, in the form of UML metamodels, to be defined with some level of consistency (to enable software frameworks to be defined) based on different context value relationships (Tree node, RDB tables, etc)

4. Spec2 – TreeSet Context Scheme (TCS) We currently have two metamodels on the table (Scott’s and Tony’s/Gunther’s) We need to strive to combine these together This is our primary work item - I suggest this be the second spec – for now lets call it TreeSet Context Scheme - TCS TCS is dependent on CSF In the form of a UML metamodel, it primarily defines: A recursive context scheme Ability to indicate relevancy within the recursion (pull from Scott’s model) (I don’t know where to put the temporal information – here or in the profile) It does not include any form of grammar, union, intersection, etc (scope reduction) It permits a widely accepted approach to organizing context values (It is import to note here that other folks may want to utilize CSF to build a different Context Scheme - perhaps a table-based approach) Nothing new in our modeling efforts beyond scope reduction for this spec

5. Spec3 – TreeSet Context Scheme Expression (TCSE) Obviously the next spec is grammar, union, etc To define such ‘Expressions, it seems it is dependent on the specific Context Scheme relationship design For TCS, the TCSE (TreeSet Context Scheme Expression) spec will: Define the grammar (BNF, union classifiers, whatever) appropriate for TCS

6. Moving Forward In order to insure we establish the UCM foundation with reachable deliverables in 2009 The Context Scheme Framework (CSF) and The TreeSet Context Scheme (TCS) are must haves for UCM 1.0 TreeSet Context Scheme Expression (TCSE) is a must have for UCM 2.0 Specifically, we will not focus on, and remove from our work, anything to do with expressions and move it to the TCSE spec. UCM dependencies and roadmap beginnings start to look like: CSF TCS TCSE 2009 2010 2009