1. VERSION 15 DoDAF Outreach Brainstorm 27 July 2009
8/6/ :35
DoDAF 2.0 Meta Model (DM2)
Overview
DoDAF Outreach Brainstorm
27 July 2009

2. DM2 Possible Topics of Interest to ELS
Role in DoD – JCIDS, PPBE, DAS, CPM, Ops Planning, SE
Replaces CADM
Established top-level “vocabulary” for DoDAF 2.0
Data exchange role as well
Work Group methodology – avoided religious jihads
Work Group rules – semantic research, source defs, aliases, aggregation rule, ..
Work Group open to just about anybody – military, Govt, vendors, contractors, academics, …
Interaction with other groups
Controlled vocabularies – BTA, …
Federated data exchange pilots
Formal ontology foundation – IDEAS Group
Set theory (of course)
4D mereotopology
Other “common” patterns
Must / should be mathematical

3. DoDAF 2 Goals Support the Department’s core processes:
Capabilities Integration and Development (JCIDS)
Planning, Programming, Budgeting, and Execution (PPBE)
Acquisition System (DAS)
Systems Engineering (SE)
Operations Planning
Capabilities Portfolio Management (CPM)
Establish guidance for architecture content as a function of purpose – “fit for purpose”
Increase utility and effectiveness of architectures via a rigorous data model – the DoDAF Meta Model (DM2) -- so the architectures can be integrated, analyzed, and evaluated to mathematical precision.

4. Benefits of Rigorously Structured EA Data
A spectrum of information sharing:
Databases are really just storage and retrieval with connections only for exactly matching pieces of information (e.g., "keys" or exactly matching strings). 
The nature and purposes of EA require more than just storage, retrieval, and exchange, e.g., integration, analysis, and assessment across datasets
IDEAS supports entailment and other sorts of mathematical understanding of the data with membership (~ set theory) and 4D mereotopology (parts and boundaries).
These are so fundamental in human reasoning that it's hard to see that computers don't have it at all
Needed if we want to use them for something more than just storage and retrieval. 
Has to be encoded it into them with formal methods like IDEAS
Free-text Structured document Database Mathematically structured
Human-interpretable only
Human-interpretable but with a predictable organized arrangement
For example, logical entailment:
Given, "I have a headache", entail, "I have pain",
requires a categorization of headache as a type of pain
Can’t get that from unstructured or semi-structured text, or database structure or SQL
"common sense" to us but computers have no common sense
EA entailment examples:
"F-16's can fly at least Mach y" ==> F-16C's can fly at least Mach y
"Ship's Self Defense System can parse and generate TADIL-J messages" and "SSDS is-part-of all CVNs" ==> CVN's can parse and generate TADIL-J messages
Without the "intelligence" to perform entailment, data integrations, queries, and analysis algorithms miss connections.
Normally little more semantic structure than structured text
Named records (or tables or classes) that are some sort of container for named fields (or attributes or columns). 
Associations and relationships, containers can point to information in other containers
Because of the labeling, you can tie the information together and query them.  A SQL query is just fundamentally a selection of the information. 
Referential integrity, data validation, cardinality rules, etc.
Matthew,
Regarding your request below, while certainly reasonable, it is a fair bit of work.  So let's start generally:  "unstructured data", e.g., free text, might be considered one end of spectrum and math (numeric or symbolic) another.
But even so-called unstructured free text can have structure, e.g., the OMG RFP template. 
Why do we do semi-structured text?  There's a step to your answer. 
Why do we do databases?  There's another step.
The shortcoming of databases is that they usually have little more semantic structure than structured text -- named records (or tables or classes if you wish) that are some sort of container for named fields (or attributes or columns).  Via associations and relationships, containers can point to information in other containers.  Because of the labeling, you can tie the information together and query them.  A SQL query is just fundamentally a selection of the information.  I don't think there's much going on besides that.  As for referential integrity, data validation, cardinality rules, etc., it's handy to go back to the semi-structured analogy and see that they just tell you what parts of the form or template have to be filled in, with what choices, what the rules are for cross-references, etc.
Math does a lot more.  Let's just talk about logical entailment in this .  Given, "I have a headache", how do you entail, "I have pain", unless you have a categorization of headache as a type of pain?  You won't get that from unstructured or semi-structured text, or database structure or SQL.  It's "common sense" to you but computers have no more common sense than a light switch (or even a few million light switches).
Let's make this more relevant to EA. 
"F-16C has a speed capability of Mach x" ==> some F-16's have a speed capability of Mach x
"F-16's can fly at least Mach y" ==> F-16C's can fly at least Mach y
"Ship's Self Defense System can parse and generate TADIL-J messages" and "SSDS is-part-of all CVNs" ==> CVN's can parse and generate TADIL-J messages
I could go on and on.  Without the "intelligence" to perform entailment, data integrations, queries, and analysis algorithms miss connections.  I cannot even remember all the EA data integration and analysis routines I've seen over the years that flopped for this reason -- it is a real problem.  I'd bet Ian has lotsa examples too.  The C4ISR community has problems with semantic imprecision too.
My basic point is that we computer scientists think we're doing a lot with computers when we use databases but it's really just storage and retrieval with connections only for exactly matching pieces of information (e.g., "keys" or exactly matching strings).  Reasoning requires a lot more and entailment is an important part.  IDEAS supports entailment and other sorts of mathematical understanding of the data with membership (~ set theory) and 4D mereotopology (parts and boundaries).  It only seems academic at first because it's so fundamental in human reasoning that it's hard to see that computers don't have it at all and that they need it if we want to use them for something more than just storage and retrieval.  We have to encode it into them with formal methods like IDEAS.
I would like to do more on this question.  It's a hard one because it's related to many questions that have been going on for a long time about AI, the "meaning of meaning", semantics vs syntax, types, set theory, categories, mereonomy, etc. I think now that we've got some of the "accidental" problems (e.g., when I had to write assembly language on green tablets or when we couldn't even run RDBMS' because they were too slow) behind us in computer science, we can start chipping away at some of these "essential" questions now. 
Perhaps we'll have a little time to work on the SAR example in London.
Regards/David McDaniel Silver Bullet Solutions, Inc. (703) x2# (DC) (619) (San Diego) (619) (mobile) Original Message----- From: "Hause, Matthew" Sent: Friday, July 24, :16pm To: "Dave McDaniel" Subject: RE: Background Reading: UPDM 2.0 RFP & Ontology/IDEAS (UNCLASSIFIED)
Dave,
Can I make a polite suggestion? Could you demonstrate using a reasonably complex example how all this stuff helps? From an academic point of view I can see how it helps, but most people will want an example of how this helps you over and above what was previously available. Otherwise it is just an interesting intellectual exercise. In other words, what new features/benefits/capabilities will this give me? Something along the lines of the SAR model from UPDM would be useful.
Thanks,
Matthew

5. DoDAF Meta Model (DM2) Purposes:
The vocabulary for description and discourse about DoDAF models (formerly “products”) and core process usage
Specification for federated data exchange between:
architecture development and analysis tools
architecture databases
other authoritative data sources
Support discovery and understandability tenants of NCDS:
Discovery DM2 categories of information
Understandability thru precise semantics augmented with linguistic traceability
Form:
VOLUME I, DoDAF Conceptual Data Model (CDM)
VOLUME II, DoDAF Logical Data Model (LDM)
VOLUME III, DoDAF Physical Exchange Specification (PES)
“constrained vocabulary”

6. Coordination with many related activities
Cross group coordination:
Object Management Group (OMG) Unified Profile for DoDAF and MODAF (UPDM) & System Modeling Language (SysML) teams
Business Transformation Agency (BTA) Primitives and Lexicon
Enterprise Vocabulary based on DM2 (DoD CIO)
ASN RDA and JFCOM Modeling and Simulation
Joint Test and Evaluation Methodology (JTEM)
DoD Meta Data Working Group (MDWG)
MODAF and NAF (via IDEAS)
Pilots:
JFCOM JC2 Architecture and Capability Assessment Enterprise (JACAE) – MARCORSYSCOM MCAE – TRADOC Capabilities, Analysis, Development, and Integration Environment (CADIE) federated data exchange pilot
SPAWAR / ASN RDA Naval Architecture Elements Reference Guide (NAERG)
OPNAV N6 SoA “dashboard”
Enhanced Information Support Plan (EISP)
Cross group coordination:
Object Management Group (OMG) Unified Profile for DoDAF and MODAF (UPDM) & System Modeling Language (SysML) teams
DM2 Coordination with teams in mutual telecons, OMG meetings, DM2 Working Group,…
Future – UPDM 2 based on DoDAF 2.0
DM2 team coordination with UPDM and SysML:
DoDAF Plenary, Vendor’s Days, and weekly data model telecons
UPDM “architect” access to DM2 workgroup site with weekly updates
Comment acceptance into working group system
UPDM / SysML team coordination with DoDAF:
UPDM weekly telecons, OMG technical meetings, and UPDM “face-to-face” meetings
Regular distribution of UPDM “Domain Meta Model”
Their DoDAF baseline is 1.5 but they want the “heads-up” on 2.0 to better support the UPDM mod for DoDAF 2 when it is finalized
Business Transformation Agency (BTA) Primitives and Lexicon
Enterprise Vocabulary based on DM2 (DoD CIO)
ASN RDA and JFCOM Modeling and Simulation (ASN RDA tasked MITRE to map DM2 to Naval Simulation System (NSS) to see if DM2 architecture dataset could be imported into NSS for evaluation of the architecture alternative as part of AoA or as justifcation for POM – EAS&S team / DM2 WG to iterate with them. Similar with JFCOM and Dave Dryer.)
Joint Test and Evaluation Methodology (JTEM) (was Dave Dryer participate in DM2 WG, e.g., that Measure Types have Rules)
DoD Meta Data Working Group (MDWG) (meeting with Ken Fagen and Glenda Hayes, soon to brief DoDAF 2.)
MODAF and NAF (via IDEAS)
Pilots:
JFCOM JC2 Architecture and Capability Assessment Enterprise (JACAE) – MARCORSYSCOM MCAE – TRADOC Capabilities, Analysis, Development, and Integration Environment (CADIE) federated data exchange pilot. 1st pilot demo’d at EA Conference. Now evaluating candidate next pilots. Bill Piazza and Tony Oliver who work for Kim Frisby. 1st pilot mapped to DM2; plan is for 2nd pilot and henceforward will use PES. 1st pilot was done in parallel with PES. Coordination they made choices that will make easier to implement PES.
SPAWAR / ASN RDA Naval Architecture Elements Reference Guide (NAERG). Pat Roche and Kar Chan at SPAWAR doing work ASN RDA used DM2 as the underlying structure for System Functions, Op Acts, Systems, System nodes, and Op Nodes (CSFL, COAL, CSL, CSNL, and CONL.)
OPNAV N6 SoA “dashboard” – Rob Lewis using DM2 for data showing progress on SoA in Navy. SoA maturity.
Enhanced Information Support Plan (EISP) – incorporating PES as way to exchange ISP data.

7. Conceptual Data Model

8. Sources Used Models CADM 1.5 IDEAS UPDM BMM Hay/Zachman ASM CRIS
Conceptual CADM in DoDAF 1.0 / prototype CADM 2.0 M3
NAF Meta Model
DoI Meta Model
JC3IEDM
GML
UCORE 1.1
GEIA 927
AP233
SUMO and ISO (via IDEAS)
FEA Reference Models
JFCOM JACAE
Definitions
Models to the left
IEEE
ISO
W3C
OMG
EIA
DODD & DODI
JCS Pubs, especially CJCSI's
DoDAF
Other frameworks: Zachman, MODAF, TOGAF, NAF, ...
FEA
BMM
Wordnet
Wikipedia
English dictionaries
On the left are the model sources we considered to date; on the right, additional sources for definitions.
UCORE 2.0 was in development in parallel, released April Currently, mapping to UCORE 2.0 and then more later. Will address in later slide.

9. Modeling Principles
Model Core Process (PPBE, DAS, JCIDS, CPM, SE, Ops) business objects
Terms enter model through thorough semantic research:
Assignment to a researcher
Collection of authoritative definitions, documenting source
Assessment of redundant (alias) or composite terms
Formulation / selection of definition based on authoritative definitions
Examples
Outbrief to team
Recording of research and decision rationale
No need to distinguish / label concepts that differ only in level of aggregation – e.g., subfunction – function, system -- subsystem. Whole-part relationship covers the need without different names for different types of wholes and parts. When a user has need to label, the naming pattern accommodates.
Typed Relationships, e.g., using IDEAS
No commitment to an implementation type. Support RDBMS, XSD, Java, etc. from core model
Goal is a core that can be extended by user communities, not to try to cover all user detail. Extenders should be careful to not create redundant representations.
Model will enter a CM process

10. Definitions and Aliases Record Excerpt
Definition sources listed.
System def – includes operators. Doesn’t have an IT system. Doesn’t have to be a POR.
Facility – ended up with adaption of AT&L I&E definition to cover non-US facilities.
(all in the DM2_yymmdd.xls file)

11. Definitions and Aliases Record Excerpt
Role has been revisited many times, same conclusion that it is a composite.
(all in the DM2_yymmdd.xls file)

12. (see handout or briefing notes for relationship key descriptions)
Conceptual Data Model 1 2 3 4 5 6 7 8 9 10 11 12 13 14 20 16 17 18 19 21 22 26 15 23 27 24 25 28
The blue triangle-headed lines are read, “type-of” from bottom to top, e.g, “a System is a type-of Performer”
The associations between the concepts, are as follows, keyed to the footnote numbers from top to bottom and left to right:
Measurements are done in accordance with Rules, e.g., Rules that specify how test measurement equipment must be calibrated before a test
Certain types of Measures apply to an Activity, e.g., how long it takes. This feature was part of the IDEF0 specification.
A Project consists of several or many Activities (e.g., Tasks)
Measures can be categorized into Measure Types
There are Measures associated with a Project (e.g., time, cost)
Activities are performed in accordance with Rules (e.g., Controls in IDEF0)
A Project has Desired Effects (e.g., goals)
Desired Effects (e.g., goals) guide / drive Activities
Visions are realized by Desired Effects (e.g., objectives)
Desired Effects are Measureable; otherwise there would be no way to know they were achieved. This statement implies a measure can be constructed for all Desired Effects.
A Rule applies to an Activity under certain Conditions, e.g., Rules of Engagement may vary dependent on threat Conditions
An Activity is performable under certain Conditions, e.g., the Conditions applicable to Tasks in the UJTL
The performance of Activities under certain Conditions has Measures, e.g., the Measure Types applicable to Tasks (Activities) in the UJTL
Capabilities have Desired Effects, as so stated in the CJCSI 3170
A Capability entails performance of Activities (Tasks) , as so stated in the CJCSI 3170
The performance of Activities as part of a Capability is done under certain Conditions, , as so stated in the CJCSI 3170
The performance of those Activities as part of a Capability have Measures (metrics) for their performance, as so stated in the CJCSI 3170
A Condition has metrics (Measures)
An Activity is performed by a Performer under certain Conditions
Performers perform Activities. This characteristic distinguishes Performers from their superclass, Resources
The performance of Activities by Performers is subject to Rules. Even though Rules constrain Activities, there may be tailoring for the performance of those Activities by specific Performers
The performance of Activities by Performers is subject to Measures. Activities can have Measures in and of themselves; however there can be additional or tailored Measures associated with the performance of those Activities by specific Performers
An Activity consumes or produces Resources. Those Resources that flow can be Materiel, Information , Data, Geo-Political extents, or Performers. When the production and consumption is of Information or Data, the DoDAF 1.5 OV-3, OV-5, SV-4, SV-6, and others are partially represented.
The consumption or production of Resources by Activities is subject to Rules, e.g., the Information Assurance Rules that are part of the OV-3
The consumption and production of Resources by Activities is measureable, e.g., the Timeliness and Size measures that are part of the OV-3
Activities result in effects on Effect Objects (Resources), i.e., a cause-effect chain.
The effect on Effect Objects by Activities is measureable
A Capability is realized by one or more Performers (including configurations of Performer)
A Resource has Measures, e.g., mass, size.
Performers perform at Locations
The Skills of a Person Type are measureable, e.g., as in Skill level of a Person Type.
Person Types have Skills
Information describes some Thing
Information Pedigree is a type of Information that describes the production of Information (resources) by Activities, their Performers at Locations, and the Rules, Conditions, and Measures that apply to that information production
A Person Type can be part of a System, e.g., a radar operator or, more generally, in a cybernetic sense
A Service provides access to Performers. This results from the DoD definition of Service which is verbatim from OASIS
Materiel can be part of a System, the parts and equipment that are part of a System 29 31 30
(see handout or briefing notes for relationship key descriptions)
23 (+ 24 &25)
20 (+ 21 & 22) 30 34 33 32
Green lines are super-subtype. Read in direction of arrow, “is a type of”
Blue lines are associations. See notes for key descriptions and examples. Read key in direction of arrow.
Crows feet are associations between the association at the foot and the arrow, read according to the key. 36
Person Type 35 37

13. Interrogatives Relationship UCORE 2.0 Who, What, When, Where
WHY
HOW
In Zachman:
The Data Description — What (we generalize to other Resources besides just Data)
The Function Description — How (and also the Performer that performs the Function, Measures, Rules, and Conditions associated with)
The Network Description — Where (generalized)
The People Description — Who (we include Organizations)
The Time Description — When
The Motivation Description — Why (broadened to include Capability requirements)
WHAT
WHO
WHERE

14. Logical Data Model

15. Common Relationship Patterns Emerged -- Leveraged Ongoing IDEAS Foundation --
IDEAS is more than OWL:
Based on mathematics
Set theory & 4D mereology
Deals with issues of states, powertypes, measures, space -- what is truly knowable vs. what is assumed
Domain concepts are extensions to the formal foundation
Everything in the EA Domain inherits from the foundation
Rigorously worked-out common patterns are reused
Saved a lot of repetitive work – “ontologic free lunch”
Result is higher quality and consistency throughout
Examples:
System A1 (part) wholePart System A (whole)
Activity A (before) beforeAfter Activity B (after)
Capability Increment temporalWholePart of Capability
Organization typeInstance Organization Type
Location A overlap Location B
System (subtype) superSubType System (supertype)
As we started figuring out relationships, we realized we were doing the same relationships over and over again. Decided to look into leveraging work we had been doing for several years with the international community on a formal .ontology. IDEAS foundation concepts are inherited into all the DM2 concepts. Saved us a lot of work – ontologic free lunch -- and part of the reason why the model is so small to this day -- ~ 300 classes, attributes, and values as compared to CADM’s 16, 000 pieces.
Three types of Things: Types (which are like sets), Tuples (ordered relationships), and Individuals (not persons, but Things that have spatial and temporal extent – spatio-temporal extent.)
mereology is a collection of axiomatic first-order theories dealing with parts and their respective wholes. In contrast to set theory, which takes the set–member relationship as fundamental, the core notion of mereology is the part–whole relationship. Mereology is both an application of predicate logic and a branch of formal ontology.

16. Why Formal Ontology? Corresponds to the real world being modeled:
Physical objects that have parts, can be aggregated into larger wholes – both spatially and temporally
The parts don’t have to be contiguous, e.g., parts of a squadron
The objects have a lifetime (temporal extent) that can be broken into temporal states
Only one object can occupy the same spatio-temporal extent
Examples:
Things are categorized
Multiply
Categorization should follow the rules to set theory, e.g.,

17. Why Formal Ontology (cont’d)
Why is this better? “is-a” example:
Not mathematically rigorous:
More precise:
Examples with “Has” – the basis of fields and attributes – can be cited too
Does this really matter – all the time – fouls queries, analysis algorithms, and interoperability
Why did this happen? Database design had in origins in form automation, not mathematical analysis – good for storing stuff to be processed by humans – terrible for automated processing as in data fusion

18. Diagram Conventions and Use of UML
<<Individual>> An instance of an Individual - something with spatio-temporal extent [Grey(80%) R40G40B40]
<<Type>> The specification of a Type [Pale Blue R153 G204 B255]
<<IndividualType>> The specification of a Type whose members are Individuals [Light Orange R255 G173 B91]
<<TupleType>> The specification of a Type whose members are tuples [Light Green R204 G255 B204]
<<Powertype>> The specification of a Type that is the set of all subsets of a given Type [Lavender R204 G153 B255]
<<Name>> The specification of a name, with the examplar text provided as a tagged value [Tan R255 G254 B153]
<<NamingScheme>> The specification of a Type whose members are names [Yellow R255 G255 B0]
The IDEAS Model is represented in UML. The UML language is not ideally suited to ontology specification in its native form. The UML language can be extended through the use of profiles. The IDEAS Model has been developed using a UML Profile - any UML elements that are not stereotyped by one of the IDEAS foundation elements will not be considered part of an IDEAS ontology. The IDEAS Foundation specifies the fundamental types that define the profile stereotypes. The super-subtype structure in IDEAS is quite comprehensive, and showing the super-type relationships on some diagrams can result in a number of crossed lines. In these cases, supertypes of a given type will be listed in italic text in the top-right-hand corner of the UML element box.
The stereotype of an element in an IDEAS UML model is a shorthand for the element being an instance of the type referred to by the Stereotype, though the type must be one that has been defined in the root package of the foundation. Hence, if the stereotype is <<Individual>> then the element is an instance of an Individual. The following stereotyped classes, with their color-coding are used in the model:
<<Individual>> An instance of an Individual - something with spatio-temporal extent [Grey(80%) R40G40B40]
<<Type>> The specification of a Type [Pale Blue R153 G204 B255]
<<IndividualType>> The specification of a Type whose members are Individuals [Light Orange R255 G173 B91]
<<TupleType>> The specification of a Type whose members are tuples [Light Green R204 G255 B204]
<<Powertype>> The specification of a Type that is the set of all subsets of a given Type [Lavender R204 G153 B255]
<<Name>> The specification of a name, with the examplar text provided as a tagged value [Tan R255 G254 B153]
<<NamingScheme>> The specification of a Type whose members are names [Yellow R255 G255 B0]
The following stereotyped relationships are used in the model:
<<typeInstance>> a relationship between a type and one of its instances (UML:Dependency) [Red R255 G0 B0]
<<powertypeInstance>> a relationship between a type and its powerset (UML:Dependency) [Red R255 G0 B0]
<<nameTypeInstance>> a relationship between a name and its NameType (UML:Dependency) [Red R255 G0 B0]
<<superSubtype>> a relationship between a type and one of its subtypes (UML:Generalisation) [Blue R0 G0 B255]
<<wholePart>> a relationship between an individual and one of its parts (UML:Aggregation) [Green R0 G147 B0]
<<namedBy>> a relationship between a name and the thing it names [Black R0 G0 B0]
<<tuple>>/<<couple> a relationship between a things (UML:n-ary relationship diamond) [Grey(80%) R40G40B40]
(see handout or briefing notes for complete set of stereotypes)

19. Super/Sub Type, e.g.,
F-15 is type of Fighter
Whole Part, e.g.,
AEGIS radar is part-of the AEGIS ship
Overlaps, particularly Interface Type, e.g.,
Asset data collection activities produce data for audit reporting
Before-After, e.g.,
The collection task takes place before the posting and exploitation tasks

20. DoDAF Domain Concepts are Specializations
Thing
Type
Individual
Individual Type
So you take all the DM2 domain concepts and classify them into the IDEAS foundation classes.
So they inherit associations (can occupy association place positions)
(zoom-in to read or see handout)

21. All Associations are Typed
Before-after
Whole-part for Types
Overlap for Types
Before-after for Types
Description and naming
Instance-of-type
Instance-of-powertype
Similarly, we type the associations by classifying them under their IDEAS foundation class.
So their mathematical meaning is formally modeled – a first in DoDAF meta models
(zoom-in to read or see handout)

22. Naming and Description Pattern
Multiple names for same thing (aliases) – must tell Naming Scheme
Information (formerly Information Element) linked to the Things it describes

23. Information Pedigree – workflow model ~ Open Provenance Model (link together)
Information Production Activity
Resources Used, e.g., other Information
Who
Rules followed in the production
Requirement in the DoD Net-Centric Data Strategy (NCDS)
Similar to Open Provenance Model
Describes the workflow that led to the production of the information
Pedigree is the immediate link – provenance further back in the production chain
Activities, Performers, Performer states, resources used, rules abided by, measures conformed to
Measures in the production, e.g., QoS, uncertainties
Where done

24. Physical Exchange Specification (PES) XSD General Structure
Wrapper, describing that the document is
Independent entities with naming and aliases
Associations
Constraints
Similar to UCORE
The payload part (entities and associations) is very much like the way done in UCORE 2.0 Digest. Very flat.

25. Work with OMG / UPDM Team
XMI / MOF Conversant (e.g., UPDM / SysML)
Analysis Software
DM2 PES
XSD
neutral
implementation
EA / ITA Tools
Authoritative Data
Sources
EA Domain Concepts
Common
Patterns
4D Mereology
Set Theory
Naming
Pedigree
M&S
Tools EA
DBMS’
Ontic Foundation
Why don’t we just do UPDM and XMI? Because our community is broader than that – we need to exchange across many boundaires.
Reporting Tools and Formats
Federal, Coalition, and other EA exchanges

26. Where to learn more and participate in DM2 evolution
Join the Data TWG
Access to Share site
Weekly message with invitation to participate in DCO telecon
Stay in touch with ongoing evolution, pilots, and Configuration Management activities

27. DM2 Workgroup Weekly Sessions on DCO Collaboration Site:
Current DM2 walkthru briefing
Baseline DM2 CDM, LDM, and PES
Developmental DM2
IDEAS Foundation
Reference and Research folders
Now the DM2 Configuration Management (CM) body
To join, send to
DM2 WG reports to the ARG reports to the TSEARG reports to the ERB

28. Questions?

29. Briefing Outline Background Why an EA meta model?
History and Lessons Learned
So – DM2 Methodology
Walkthroughs:
Conceptual Data Model
Logical Data Model
Physical Exchange Specification
How to get engaged

30. Background

31. Volume II is Organized Around the DM2
for each data group:
DM2 Data Groups
Performer
Resource Flow
Information & Data
Activity
Training / Skill / Education
Capability
Services
Project
Goals
Rules
Measures
Location
x.y.1 Data – what are the concepts and how are they related
Diagram and definitions from DM2
Discussion
x.y.2 Method
Data collection and model construction methods -- how is such information collected and assemble
x.y.3 Use -- how is such information used in
JCIDS
PPBE
DAS SE
Operations Planning
CPM
Vol II
Perspectives
Metamodel Data Groups
Views

32. Conceptual Data Model Development Process
12/3
Strawman – list of important or recurring “core” words/terms/concepts with source definition(s)
3/3
CDM version 0.1
Concepts (defined)
Relationships (some typing, e.g., super/sub, cardinality)
1/3
Partial Draft –
proposed definitions, some harmonization (e.g., via super/subtyping, determining aliases)
2/3
Interim Draft – Initial relationships (e.g., "performs", "part-of", ...)
1. Overviews of Models
2. Collect the terms
3. Make a pass on the “Core” Terms
4. Gather authoritative definitions for “Core” terms
1 = Core, critical to process or very common in architectures
2 = Derived or less common
3 = TBD
4 = TBD
5 = TBD 5 4 3 2 1
6. Proposed definitions (+rationale, examples, and aliases)
7. Relationships
8. Relationship Types
5. Group related terms
Started out just looking at terms in various models and requirements collections.
We gathered overviews of many relevant models, listed on the next slide
We pulled the key terms into a spreadsheet, keeping track of the source
We noticed certain repeating ones, and ones that seemed “core” We ranked their core-ness / priority / key-ness. We ended up with key / core terms, which seemed about manageable
We gathered “authoritative” definitions for those 50-60, from the models plus the definition sources shown on the next slide
We noticed some terms referred to related concepts, perhaps, so we grouped them
We’ve been coming up with a proposed definition, following some group guidance. We also record the rationale and are working on examples for each definition.
We’ve started working on relationships between the concepts the terms refer to
We are starting to think about formalizing a few key relationships, e.g., super/subtype, whole-part, produce/consume (input/output), performs/supports/…,
This work is all done by various members of the SWG.
Not shown here, is that SWG members researched many thorny semantic issues and reported back to the WG their findings.

33. (see handout or briefing notes for definitions)
Key Concepts
Activity
Agreement
Architecture Description
Capability
Condition
Constraint
Data
Desired Effect
Guidance
Information
Location
Materiel
Measure
Measure Type
Organization
Performer
Person Type
Port
Project
Resource
Rule
Service
Skill
Standard
System
Vision
Activity Work, not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources) or changes their state.
Agreement A consent among parties regarding the terms and conditions of activities that said parties participate in.
Architecture Description Information describing an architecture such as an OV-5 Activity Model document.
Capability The ability to achieve a Desired Effect under specified [performance] standards and conditions through combinations of ways and means [activities and resources] to perform a set of activities.
Condition The state of an environment or situation in which a Performer performs.
Constraint The range of permissible states for an object.
Data Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Examples could be whole models, packages, entities, attributes, classes, domain values, enumeration values, records, tables, rows, columns, and fields.
Desired Effect The result, outcome, or consequence of an action [activity].
Guidance An authoritative statement intended to lead or steer the execution of actions.
Information Information is the state of a something of interest that is materialized -- in any medium or form -- and communicated or received.
Location A point or extent in space that may be referred to physically or logically.
Materiel Equipment, apparatus or supplies that are of interest, without distinction as to its application for administrative or combat purposes.
Measure The magnitude of some attribute of an individual.
Measure Type A category of Measures
Organization A specific real-world assemblage of people and other resources organized for an on-going purpose.
Performer Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability.
PersonType A category of persons defined by the role or roles they share that are relevant to an architecture.
Port An interface (logical or physical) provided by a System.
Project A temporary endeavor undertaken to create Resources or Desired Effects.
Resource Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed.
Rule A principle or condition that governs behavior; a prescribed guide for conduct or action
Service A mechanism to enable access to a set of one or more capabilities , where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer. The "capabilities" accessed are Resources -- Information, Data, Materiel, Performers, and Geo-political Extents.
Skill The ability, coming from one's knowledge, practice, aptitude, etc., to do something well.
Standard A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel.
System A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements.
Vision An end that describes the future state of the enterprise, without regard to how it is to be achieved; a mental image of what the future will or could be like
(see handout or briefing notes for definitions)

34. BORO book is downloadable from DM2 site

35. Performer The first thing to note about Performer is that it can be:
A Personnel Type such as described by Military Occupational Specialties (MOS). MOS describe Skills and their measurement (not shown in this diagram).
An Organization (type or actual Individual Organization) meaning a mission chartered organization, not limited to just collections of people or locations, e.g., the FBI has a chartered mission and it chooses the locations, people, etc. to accomplish such.
A System in the general sense of an assemblage of components – machine, human – that accomplish a function, i.e., anything from small pieces of equipment to FoS and SoS. Note that Systems are made up of Materiel (e.g., equipment, aircraft, and vessels), Personnel Types, and organizational elements.
A Service, from a software service to a business service such as “Search and Rescue”
Any combination of the above
The performance of an Activity by a Performer occurs in physical space and time. That is, at some place and time, the Activity is conducted. This is referred to as a spatial-temporal “overlap”, simply meaning that the Activity and Performer overlap in space and time. There are two ways in which a Performer spatial-temporally “overlaps” an Activity:
In the act of performing the Activity. This relationship is sometimes called “assigned to” for the purposes of traceability.
The other way is as part of a larger process (aggregated Activity). This is sometimes called “allocated to” and form the initial stages of system or process decomposition. Allocated Performer elements (parts of Performers) are assigned Activities (or processes, tasks) in the initial stages of Performer definition.
A standard (Rule) constrains an Activity in general. Some of those constraints might also apply to the performance of the Activity by a Performer.
A Performer may have Measures associated with the performance of an Activity (e.g., target tracking accuracy.) It may also have Measures associated with the Performer overall (e.g., operational condition.)
Performers perform at Locations that can be specific positions or areas, regions, or installations, sites, or facilities. Location type requirements/capabilities of a Performer are represented by the Activities that are performed under certain Conditions (e.g., must be able to perform Maneuver under Desert Conditions.)

36. Activity
Because of the inheritance from the foundation of whole-part (so some Activities are parts of others), temporal whole-part, and before-after (some some Activities happen before others), there is no longer a need to try to use different words (e.g., “Task”, “Process”, “Function”) to distinguish larger Activities or sequences of Activites.
The performance of an Activity has been deconstructed from the concept of Activity so there is no need to use different words for Activities performed by Systems (e.g., “System Functions”) from those whose performer is unspecified (e.g., “Operational Activities”).

37. Resource Flow
Whereas prior versions of DoDAF modeled only information and data exchanges and flows, this version also allows modeling of other flows, such as:
Materiel flows such as ammunition, fuel, etc. important for modeling the fire rate, logistics, etc. aspects of a Capability solution so it can be compared with other alternative solutions
Personnel Types such as Military Occupational Specialty (MOS) that allow representation of the Training and Education “pipeline” aspects of DOTMLPF.
Performer such as Services, Systems, or Organizations that might be the “output” or result of a Project’s design and production process (activities). This allows modeling of, for instance, an acquisition project.
Another difference from prior versions of DoDAF is that all exchanges and flows are by virtue of a producing or consuming Activity. That is, a Performer can only provide or consume by conducting an activity of production or consumption. For instance, publication and subscription are modeled as an interaction between the publishing Activity, the subscribing Activity, and the information or data Resource. Note that publication is typically not at the same time as subscription but the subscriber does have to go to the publication place to retrieve the Resource. For example, data might be published at 2:00 GMT on server located at some URL and the subscriber may not “overlap” until 10:00 GMT. Also note in the diagram the “overlap” is a triple – the producing Activity, the Consuming Activity, and the Resource.
The exchange or flow triple may have standards (Rules) associated with it such as IA/Security rules or, for data publication or subscription, data COI and web services standards.
The exchange or flow triple may have Measures associated with it such as timeliness, throughput, reliability, or QoS.

38. Oriented towards Desired Effects (measurable)
Manifested by Performers (including Performer configurations – remember whole-part)
Activities, Rules, Conditions, …

39. Services OASIS definition adopted by DoD
Capabilities and Services are related in two ways. One, the realization or implementation of a Capability by a Performer (configuration, including Location) may be by a Service (or collection of Services). Conversely, the realization or implementation of a Capability by a Performer (configuration, including Location) may be the means by which a Service (or collection of Services) is accomplished.
Unlike DoDAF 1.5, Services in DoDAF 2 include business services, such as Search and Rescue. This is important to keep in mind because much of the SOA literature is IT-oriented.
Although, in principal, anything has a description, the importance of self-description for discovery and use of Services merits its call-out as a class. Further, because only a public-facing side is described, the Service description needs to represent that it describes the Service Port, not the entire Service. A Service Port is a special type of Port that is self-describing and visible. The Service Description of the Service Port is of all aspects necessary to utilize the Service and no more. As such, it may include visible functionality, QoS, interface descriptions, data descriptions, references to Standards or other Rules (Service Policy), etc. The inner workings of the Service are not described in a Service Description.
Since Service inherits whole-part, temporal whole-part (and with it before-after), Service may refer to an orchestrated or choreographed Service, as well as individual Service components.
Since Service Ports are types of Ports and Ports are types of Performers, they inherit all of Performer’s properties, including Measures associated with the Performer, performance of Activities (Service Functions) with associated Measures, and provision of objects (Materiel, Data, Information, Performers, Geopolitical Extents).
Any Performer that consumes a Service may have a Service Port that is described in the service request. This description indicates how the Service provider should provide or respond back to the Service consumer. That is, Service Ports are parts of Performers that may or may not be Services themselves.
Service users interact with the accessed Performers via the Service Port. The Service Port is a special type of Port that is the part of a Performer that provides access to the Performer capabilities. Note that the Performer capabilities provided access to can be an aggregate, e.g,. an orchestration, of Performer components. The Service Port is the service consumer facing part of the Service and so has a Service Description, a type of Information. This Thing described by this type of Information is the Service Port.
Rules (service policies, contracts)
Measures (QoS)

40. Information and Data
The key concept in this model is that Information describes some Thing – material, temporal, or even abstract, such as a relationship (Tuple) or set (Type).
Since Information is a Thing, Information can describe other Information, e.g., metadata.
A Name is a type of Information in that it describes a Thing. A Name may be short or long – there is no restriction. So a textual description can be thought of a just a long Name. Information is more general than text strings and could be structured, formalized, or include other manners of description such as diagrams or images.
Information, as a Resource Type, inherits whole-part, super-subtype, and before-after relationships.
If Information is processsable by humans or machines in a repeatable way, it is called “proceduralized.” Not all proceduralized information is necessarily computerized; forms are examples of data proceduralized for human repeatable processing.
Data to be proceduralized has associations such as parts and types as well as other application specific associations. So for an Entity-Relationship model, Attributes are “has” associations with Entities and Entities are related according to “verb phrases” and cardinalities. In the physical schema, the fields are associated to datatypes.
The representation for Data is not intended to cover all the details of, for instance, a relational DBMS’ underlying Meta-model, but just those aspects necessary to support the decision making of the core processes.
Architecture Description describes architectures. An Activity Model is an example of an Architecture Description. Two subtypes of Architecture Description are called out – the AV-1 and the Manifest – because of their importance in discovery and exchange, respectively. Note that the AV-1 information can also be provided in a structured manner, using the Project data group to describe the architecture project’s goals, timeline, activities, resources, productions, rules, measures, etc.

41. Project Presentation TWG recommended – based on NAF
Like all concepts in the DM2, Project has whole-part, temporal whole-part, and super-subtype relationships so that major Projects can have minor Projects within them, Projects can have time phases, and Projects can be categorized.
Because a Project involves execution of a plan composed of Activities (Tasks), there is a flow of resources into the project’s activities and a flow of products out of them, as described by the Resource Flow data group. So this model can describe a Project that results in a System, a Service, Personnel Types (i.e., Training), Organizations (i.e., organizational development), Materiel, or Locations (e.g., Facilities, Installations).
Because technology is part of the Project, this group models the analog of the DoDAF v 1.x SV-9 (System and Services Technology Forecast) and SV-8 (System and Services Evolution Description).
Many kinds of measures may be associated with a Project – needs, satisfaction, performance, interoperability, organizational, and cost.Can be any kind of project, not just acquisition
Can be used as architecture metadata to describe the architecture project, i.e., structured AV-1

43. Goals
Although the language sounds different, the meaning of a desired effect (a change in state of some object) is the same as the meaning of goal.
A desired change in the state of some object leads to activities constrained by Rules that are performed by Performers. Some Activities are considered Events because they are of near-zero duration with respect to the frame of discernment of the Vision, Performers, etc.

44. Rules
A Rule constrains Activities. For example, a speed limit rule constrains driving activity. Some seemingly static rules have the effect of limiting possible activities. For example, a rule that security fences must be 10 feet high constrains the activity of building security fences. This constraint may apply or vary under certain conditions. For example, speed limits can be lower in poor weather conditions.
Security classification, security marking, releasability, etc. are types of Guidance. Similarly, a Rule is a stronger form of Guidance.
An important Constraint type is a Service Policy that constrains access to capability Performers.
Doctrine, by definition, constrains military action.

45. Measure All kinds of measures and metrics
The key elements of the Measure Data group are Measure and Measure Type. Measure refers to the actual measure value and units. It relates to a Measure Type that describes what is being measured.
Measure Measure Type
1 year Timeliness
Mach 3 Rate
99 percent Reliability
56K BAUD
3 meters Target Location Error (TLE) Accuracy
1,000 liters Capacity
$1M Cost
Level 3 CMMI Organizational Level
Formally, a Measure defines membership criteria for a set or class; e.g., the set of all things that has 2 kg mass. The relationship between Measure and Measure Type is that any particular Measure is an instance of all the possible sets that could be taken for a Measure Type.
The lower part depicts the upper tiers of a Measure Type taxonomy or classification scheme. It is expected that architects would add more detailed types (make the taxonomy more specialized), as needed, within their federate. Note that Service Level has multiple inheritances because a Service QoS or SLA could address User Needs, User Satisfaction, Interoperability, or Performance.
All Measure Types have a Rule that prescribes how the Measure is accomplished; e.g., units, calibration, or procedure. Spatial measures’ Rules include coordinate system rules. For example, latitude and longitude are understandable only by reference to a Geodetic coordinate system around the Earth.
The upper part depicts how Measures apply to architecture elements. Note that they apply to relationships between objects; e.g., the Measure applies to a Performer performing an Activity. The Activity has a relationship to Measure Type that says what Measure Types apply to an Activity. This represents UJTL tasks and their applicable Measure Types, including Conditions, that is, Condition is quantified by a Measure Type. (The whole-part relationship feature of Condition allows it to be singular.) This is accomplished by Condition’s typeInstance association, saying an elementary Condition is a member (instance) of a Measure Type class.

46. Location Not trying to re-create GML
Addresses such as Universal Resource Locator (URLs), URNs, postal addresses, datalink addresses, etc. are considered Names for Locations. Addresses are ways to get to physical locations, e.g., a URL gets you to a server, a postal address gets you to a mailbox. There NameTypes for Address names, e.g., “postal”, “URL”, “TADIL link address”, etc.
The naming pattern works by identifying the following: (1) the name string, (2) the object being named, and (3) the type of name (e.g., “postal address”). “Name” here is used in the broadest sense, such that a description is considered a long name.
The lower left of the diagram is a model of types of Location objects. These can be alternatively named using the naming pattern in the upper left and delineated using the Extent pattern in the lower right.
Minimal parts of the Spatial Extent (Point, Line, Surface, and Solid Volume) are detailed because of the varying requirements within a federate. That is, member of the federate may need to specialize the Spatial Extents. Some common and simple classes are modeled, such as a Line described by two Points and a Planar Surface defined by a Line and Point.
Facilities are types of Locations. In prior versions of DoDAF it was not clear if a Facility could be thought of as a “system” or just a Location. This is now clarified. To describe the functionality of a Facility, the Activities performed by the Performers located at the Facility are described.
Installation, Site, and Facility follow Army guidance from the Real Property Inventory Requirements (RIPR). Similarly, a Facility can be a “linear structure,” such as a road or pipeline.
Geofeatures (called FEATURE in JC3IEDM) cover man-made “control features,” as well as geophysical features (including meteorologic and oceanographic phenomena).

47. Top-Down / Bottom-Up Development
DoDAF 2.0:
Conceptual Data Model (Vol I)
Logical Data Model (Vol II)
Physical Exchange Model (Vol III)
Existing / Emerging Schema, Models, and Databases
Data Model Development
COI1
COIn
COI Coordination
PPBE Process Information Requirements
JCIDS Process Information Requirements
Ops Planning Process Information Requirements
SE Process Information Requirements
DoD Core Process Information Requirements Collection
UCORE
DAS Process Information Requirements
CPfm Process Information Requirements

48. What you are looking at: some screen scrapes from the graphical schema view in XML Spy. =‘s and –’s open and close like Window’s Explorer; the dashes are optional
Two of the most popular data structures
Upper left – DM2 extends off the complex types.
Always have attributes: ID, foundation category (in order to be able to go back to the highest IDEAS foundation category: Type, Tuple, Individual, and lower)
Name – ID, text, namingScheme, IC-ISM
In lower one (couple), same but with place1 and place2, the two elements of a couple.
Optional tag part of Dublin Core for comments
IDEAS Foundation

49. Example Use Case ROE Conduct fires Firing Battery Take fire Coordinate
assault
Conduct
fires
Fires
Fire orders
Coordinate
assault
Provide
ammo
Ammo
Rounds complete
Firing
Battery
Blue boxes are activities, the little gray ones inside are the consuming and producing parts of them.
ROE is a rule that constrains the conduct Fires activity; Firring battery is the performer that performs the Conduct Fires activity
Notice that Conduct Fires produces more than just information (Rounds complete report); it also produces Fires that are consumed by the Take Fire activity performed by an enemy
Activity 1=Conduct fires
Activity 2=Coordinate assault
Resource=Fire orders
Performer=Firing Battery
Rules=ROE

50. associations Again, very simple.
You can see the Conduct Fires, Coordinate Assault activities, the Fire Order Resource, the Firing Battery Performer, the Rules of Engagement Rule, and then the associations that tie them all together.
associations

51. DM2 Foundation
DM2 foundation = additional repeatable data structures currently = info pedigree
One that is opened in this screen scrape shows where the information was produced if it were produced at a specific point.

52. Activity Decomposition Tree Elements
activityWholeConsumingPartOfActivity
activityWholeProducingPartOfActivity
ConsumingPartOfActivity
ProducingPartOfActivity

53. Activity Decomposition Tree XSD Root

54. Activity Model Elements
activityPartOfCapabilityTypeInstanceOfMeasure
activityPerformableUnderCondition
activityPerformableUnderConditionTypeInstanceOfMeasure
activityPerformedByPerformer
activityPerformedByPerformerTypeInstanceOfMeasure
activityPerformedByPerformerTypeInstanceOfRule
activityResourceOverlap
activityResourceOverlapTypeInstanceOfMeasure
activityResourceOverlapTypeInstanceOfRule
activityTypeInstanceOfMeasureType
activityWholeConsumingPartOfActivity
activityWholeProducingPartOfActivity
AdaptabilityMeasure
Condition
conditionTypeInstanceOfMeasure
Constraint
ConsumingPartOfActivity
Country
desiredEffectTypeTypeInstanceOfMeasure
DomainInformation
EffectsMeasure
FunctionalStandard
individualDesiredEffectTypeInstanceOfMeasure
InformationType
MaintainabilityMeasure
Measure
measurePowertypeInstanceOfMeasureType
MeasureType
NeedsSatisfactionMeasure
Organization
OrganizationalMeasure
OrganizationType
PerformanceMeasure
Performer
PhysicalMeasure
ProducingPartOfActivity
Resource
ResourceType
resourceTypeInstanceOfMeasure
Rule
ruleConstrainsActivity
rulePartOfMeasureType
ServiceLevel
skillPartOfPersonTypeTypeInstanceOfMeasure
SpatialMeasure
TemporalMeasure
wholePartTypeInstanceOfMeasure

55. Activity Model Root
Again, very flat.

56. Activity Model Details
Security attributes at envelope and tag level (like cover and portion markings in a document)
First time we see the DM2 optoinal information pedigree tag for every element of the payload.

57. Sample XMI Neutral format for UML file
Should allow for use of a UML model by any other UML tool
Oriented toward full re-creation of the native model:
Graphics
Layout
All UML features
NOT a neutral format for non-UML tools

58. Requirements Capture in DM2 Zachman’s “Reification Transforms”
describes
describes
describes
Thing
describes
describes
Pedigree
(requirements)
Pedigree
(requirements)
Pedigree
(requirements)
Pedigree
(requirements)
Architecture Description
Pedigree
(requirements)
Architecture Description
Architecture Description
Architecture Description
Architecture Description
Rules
Rules
Rules
constrain
Rules
constrain
Rules
constrain
constrain
constrain
Worker
Technician
Engineer
Architect
Executive
Strategic
JCD
IOC
time

59. Activity Model in DM2 Terminology
Measures and metrics
Performer A
Performer B
Activity 1A
Activity 1B
Resources
a, b, c
Resources
x, y, z
Activity 11A
Activity 11B
Performers to which applicable
Performer performing Activity 1A that has a sub-activity producing Resources (Materiel, Info, Data, etc. Geopolitcal, Performers)
Conditions in which applicable
Rules, constraints, standards, …

60. DoDAF 1.5 IER “Matrix” in DM2 Terminology

61. Mapping of Models Basis for XSDs
DoDAF models (52)
DM2 elements (~ 300)
(see DoDAF Vol II to read entire matrix)
Legend:
“n” = Necessary data for this DoDAF model
“o” = Optional
“f” = Foundational
Blank = cannot be included in this DoDAF model
Governance dictates DoDAF models; matrix then dictates what data those models must or can contain

62. DM2 (including PES), IDEAS Foundation V1.0, and UPDM 2.0 Vision
DM2 PES XML document1 Þ UPDM XMI file format translator
DM2 PES XML Document
UML XMI XML Document
UPDM XMI file format2 Þ UPDM tool specific format conditioner
DoDAF Meta-model (DM2)
with IDEAS Foundation
Do not exist yet
UPDM XMI file format2 Þ DM21 translator
UPDM XMI file format2 Þ UPDM tool specific format conditioner
The IDEAS foundation is in included in DM2 for the ontological concepts of architecture. The use of the IDEAS foundation will enable the sharing of architecture data with our multi-national partners.
Tools, aligning with the DM2, will exchange architecture information with each other through the creation of XML documents that are based on the DM2 Physical Exchange Specification.
When UPDM 2.0 is created (based on DoDAF V2.0 and DM2), UML tools using XMI will be able to exchange architecture information. When a UML tool needs to exchange architecture information with a non-UML tool, the exchange files will need to be XML following the DM2 PES.
One format per 52 DoDAF models + any custom “fit for purpose” models
One per UPDM tool

63. “Capability Configuration”
Capability – dispositional ability to perform activities and achieve desired effect
Phase 0
Phase 1
Phase 2
“Capability Configuration”
Performer 0
Performer 1
Performer 2
Required
Achieve
Current

64. Dispositional Property
A Property whose members are Individuals that have a property of being capable to manifest a CategoricalProperty under certain conditions other things being equal. It is critical when describing the disposition to specify the conditions both for the dispositional and the categorical property that is capable of being manifested. These can range from quite stringent conditions, the DispositionalProperty of 'being capable of flying at Mach 2, at a moment's notice' to the more lax, the property of 'being capable of flying at Mach 2, once suitably configured'. Note that these have the same manifestation - the categorical property of 'flying at Mach 2'. Similarly, it is often critical to describe in detail the conditions that apply to the CategoricalProperty that can be manifested, so, for example, 'flying at Mach 2, in good weather'.
Example:
Ability to fly (activity) at Mach 2
Ability to strike a target (activity) 10km away (desired effect)
Ability to dissolve in water
Target struck state
Strike the target 10 km away
tnow
tfuture

65. Bounding box means these are spatio-temporal parts
Conditions * *
Capability
Bounding box means these are spatio-temporal parts
Activity *
Activity
Activity
produce
Activity (ways)
Effects
Effects
consume *
Effects *
Effects
Desired Effects
Resource
Resource
Resource * *
Resource (means) * * *
Measures (standards of performance)
Measures (standards of performance)
Measures (standards of performance)
Measures (standards of performance)
Measures (standards of performance)

66. Aka capability configuration
Capability B
Capability A
Act 3
Act 1
Act 4
Act 2
manifests
Aka capability configuration
Performer y
Performer x
Act 3
Act 1
Act 4
Act 2

67. Rules are spatio-temporal
Rule applies across this whole
Description of the rule

68. Conditions

69. Resource states, something with start time and end time
Whole-life of Taliban
Neutralized (civilized world desired effect)
Current day
Rule the world (barbarian world desired effect)
time
Resource states, something with start time and end time