1. Integrator / Data Analyst / Developer Walkthrough (Ontology and XSDs)
VERSION 15
6/13/ :03
DoDAF 2.0 Meta Model (DM2)
Integrator / Data Analyst / Developer Walkthrough (Ontology and XSDs)
TBS
dd mmm yyyy
Mx. Tbsfirst tbslast
Enterprise Architecture & Standards
Office of the DoD Deputy Chief Information Officer

2. Briefing Outline IDEAS Ontologic Foundation Description Usage DM2 XSDs
Profile Chosen
Exchange Use Cases
Expectation for tool and database use
Examples

3. Map of DM2 Description Documents and Briefings
You are here

4. Leveraged IDEAS Foundation (International Defence Enterprise Architecture Specification)
Developed by an international group of computer scientists, engineers, mathematicians, and philosophers under defense sponsorship
None of these foundation properties are unusual; they are all used in reasoning everyday:

5. Basic Concepts: three types of Things
Individuals, Things that exist in 3D space and time, i.e., have 4D spatial-temporal extent.
Types, similar to sets of Things.
Tuples, ordered relations between Things, e.g., ordered pairs in 2D analytic geometry, rows in relational database tables, and subject-verb-object triples in Resource Description Framework.
Individuals, things that exist in 3D space and time, i.e., have spatial-temporal extent.
Types, sets of things.
Tuples, ordered relations between things, e.g., ordered pairs in 2D analytic geometry, rows in relational database tables, and subject-verb-object triples in Resource Description Framework.

6. Basic Concepts: relationship types formalize important properties of the real world being modeled
Set theoretic:
Super-subtype (categorization of Things); e.g., a type of system or service, capability, materiel, organization, or condition.
Type-instance, similar to “element of” in set theory
Spatio-temporal parts and wholes (4D mereology):
Whole-part; e.g., components of a service or system, parts of the data, materiel parts, subdivisions of an activity, and elements of a measure.
Temporal whole-part (temporal states); e.g., the states or phases of a performer, the increments of a capability or projects, the sequence of a process (activity).
Spatio-temporal boundaries and overlaps (4D mereotopology:
Overlap
Before-after (sequences)
Things can be in many categories
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

7. The IDEAS Foundation is:
Formal, higher-order, 4D, based on four dimensionalism
Extensional (see Extension [metaphysics])
Using physical existence as its criterion for identity
Deals with issues of states, powertypes, measures, space -- what is truly knowable vs. what is assumed
signs and representations are separated from referents
The advantage of this methodology is that names are separated from things and so there is no possibility of confusion about what is being discussed.
Well suited to managing change-over time
Identifies elements with a degree of precision that is not possible using names alone
Comparing two Individuals, if they occupy precisely the same space at the same time, they are the same.
For two Types to be the same, they must have the same members
If those members are Individuals, their physical extents can be compared.
If the members are Types, then the analysis continues until Individuals are reached, then they can be compared.

8. Why Formal Ontology?
Mathematical rigor needed for precision Architectural Descriptions that can be analyzed and used in detailed processes such as Systems Engineering and Operations Planning.
Better ability to integrate and analyze EA data for EA purposes.
DM2 domain concepts are extensions to the formal foundation
Rigorously worked-out common patterns are reused: Super-subtype, whole-part, temporal whole-part, type-instance, before-after, overlap
Saved a lot of repetitive work – “ontologic free lunch”
Model compactness through inheritance of superclass properties and common patterns.
Economizes implementations
Result is higher quality and consistency throughout
Improved interoperation with Unified Profile for DoDAF and MODAF (UPDM)-SysML tools which are following IDEAS concepts.
Improved opportunities for Coalition and NATO data exchange since MODAF is following IDEAS and NAF is interested in following IDEAS.
Agreed-upon analysis principles that provide a principled basis for issue analysis

9. Benefits of adopting the IDEAS formal foundation and common patterns
Model compactness through inheritance of superclass properties and rigorously worked-out common patterns.
Saved a lot of repetitive work – “ontologic free lunch”
Economizes implementations
Concentration of effort on a few common patterns results in higher quality and consistency throughout
Agreed-upon analysis principles that provide a principled basis for issue analysis
Improved ability to integrate and analyze multiple heterogeneous EA datasets to fulfill EA purposes
Depends on near-universal mathematics and science that all learn very similarly
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 –
IDEAS:
Mathematics
type (~set) theory
4D mereotopology
Deals with issues of states, powertypes, measures, space -- what is truly knowable vs. what is assumed
Separates signs and representations from referents
DM2 domain concepts are extensions to the formal foundation
Rigorously worked-out common patterns are reused:
Super-subtype, whole-part, temporal whole-part, type-instance, before-after, overlap
Saved a lot of repetitive work – “ontologic free lunch”
Result is higher quality and consistency throughout
Then domain concepts inherit several important properties.

10. Formal Ontology Mathematics
Set theory
4-D (xyzt) mereology (and mereotopology)
Whole-part
Spatial
Temporal
Before-after
Overlap
Predicate Calculus
Set theoretic, geometric, and topologic mathematic “laws” and theorems, e.g.,
Commutivity and anti-commutivity, e.g.,
Symmetry and anti-symetry
Reflexivity and irreflexivity
Associativity
Transitivity
Many others
These types of logics, calculii, theorems, etc. can be applied against datasets founded on formal ontologies such as the IDEAS Foundation
Making a distinction between things and the ways in which they are represented (e.g. their names, identifiers, etc.). This may seem like an obvious distinction, but most software systems do not do this - i.e. they conflate the object and its name.
By separating representation from extent, this allows any given Thing to have more than one representation. For example, the set of all tables might be called "Table" and also called "Tisch". A given car could be identified both by its VIN number and its manufacturer serial number (note that the vehicle registration number only identifies a state of the vehicle from when it is manufactured to when it is unregistered).
This allows great precision about the extent of things whilst still allowing a great deal of flexibility in representation.
Set theory – categories of things
Meronymy – spatial relationships between things
Tuples – ordered relationships between things
Logic – deductive, monotonic, non-monotonic, …
Inference – probabilistic, evidential, …
Lexical semantics, mathematical linguistics, …
Mereology 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.
Like all complex systems, made up of many pieces
The pieces interact through data
Originally, piece makers (engineers, programmers) worked pair-wise (e.g., at design meetings, telephone, test sites) to figure out the interaction – involved much human interaction
With network “bus” architectures, easier to make interaction possible because the data is available
But understandable only by much human interaction1
The number of pieces continues to grow2
The number that need to interact continues to grow3
The scope of data they would like to use continues to grow4
XML provides documentation with the data, but humans still have to read and understand it.
e.g., Smart Ship, Integrated Bridge System, BMD
Continuing C4I – Combat System integration, Joint systems, OA and CANES SoA componentization
e.g., reference data such as ECDIS-N charts and GCCS-I3 use in Combat System
Provides for Relationships that aid Higher Level Command and Control Fusion Functions (ID, activity, intent, mission-related groups, etc.) with ISR context information
Uses taxonomies to allow detailed but interoperable extensions for sub-domains
Taxonomies again, to allow detailed but interoperable extensions
Allows aggregation of any object sets
Supports multiple hypotheses about any particular belief
Can represent uncertainty for ANYTHING – hostiles, neutrals, and even friendlies.
Parametrically (e.g., kinematic covariance matrices) and some discretely (e.g., ID “confusion matrices”)
Multiple hypotheses about any particular belief
Represents “pedigree” – what was used and how in coming up with some belief, including Context in which the belief was formulated (environmental and mission)-Beyond “Track History and Special Indicators”
Models true meaning (e.g., not just “indicators”), cause-effects (e.g., observation / measurement caused-by some object)

11. Why math? a spectrum of information sharing
Human-interpretable only
Human-interpretable but with a predictable organized arrangement
Applicable mathematics:
Set or type theory
Mereology
Mereotopology
4 dimensionalism
Predicate calculus
Logics: modal, Kripke, …
Rules, operators:
Commutative, reflexive, transitive, …
Member-of, subset-of, part-of, …
Databases are semantically weaker than commonly understood, e.g., the fundamental concepts of Entity-Relationship and Class Models:
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 understanding what we’re doing. 
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.
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.
Built-in’s:
predicate “has”
Plural, singular notions (cardinality)
Sufficiency and completeness notions (e.g., no-nulls)
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.
It's a hard question 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. 
predicate
subject
object
i.e., structured sentences => language-based

12. Compare DM2’s Predesessor, a classic E-R model
CADM had 687 entities, 3,914 attributes, 11,911 domain values, and 1,249 associations = 17,762 data elements
DM2 has 217 foundation and domain data elements, 37 IC-ISM's, and 4 metadata for a total of 258 data elements
CADM had 687 entities, 3,914 attributes, 11,911 domain values, and 1,249 associations = 17,762 data elements
DM2 has 217 foundation and domain data elements, 37 IC-ISM's, and 4 metadata for a total of 258 data elements

13. Benefits of Rigorously Structured EA Data
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
For example, the logical entailment of an EA dataset or collection of related EA datasets might reveal inconsistencies.
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.
DM2’s ontologic foundation 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
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 understanding what we’re doing. 
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.
It's a hard question 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. 

14. Some points about the foundation:
Types include sets of Tuples and sets of sets.
Tuples can have other Tuples in their tuple places.
There are three subtypes of Type: 1) Individual Type, sets whose members are Individuals (Things with spatio-temporal extent); Power Types, sets whose members are generated from a powerset on some other set; and 3) Tuples, sets of ordered relations between Things.
The participants in a super-subtype relationship can be from the same class, e.g., the supertype can be an instance of Measure Type as well as the subtype. This allows for representation of as much of a super-subtype taxonomy as is needed.

15. Powertypes
Power Type members are generated from some Type by taking all the possible subsets of the members of the Type. For example consider the Type whose members are a, b, c. The powerset would be:
Some of these subsets are not used by anyone, e.g., the full set, the null set, or just some random subset.

16. Interesting Instances of Powertypes
Take the Individual Type AIRCRAFT, whose members include all the aircraft of the world. The powerset generated from this set would have:
The first two are not very interesting
The second one, which might be name F-15 Type, is quite useful.
The last example is not useful to most unless you are interested in the first (assuming the subscript 1 means first) of any particular aircraft type, e.g., if you were doing a study of first-off-the-line aircraft production lessons-learned.
The usefulness of Power Types
they allow for multiple categorization schemes with traceability back to the common elements so that the relationships between multiple categorization schemes are known
multiple categorization schemes or taxonomies in EA because across a large enterprise it is not possible to employ a single categorization scheme, rather schemes vary depending on function.
For example, a weaponeer’s classifies ordnance is naturally different from a logistician’s, the former concerned with delivery means, lethality, etc. and the latter with weight, size, and other transportation issues.
Note also that a powerset can then be taken of the powerset

17. 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

18. IDEAS Foundation Concepts

19. IDEAS Foundation Associations

20. IDEAS Foundation Associations

21. BORO book is downloadable from DM2 site

22. Initial work on mathematics of data modeling
Set theory
4-D (xyzt) mereology (and mereotopology)
Whole-part
Spatial
Temporal
Before-after
Overlap
Predicate Calculus
Making a distinction between things and the ways in which they are represented (e.g. their names, identifiers, etc.). This may seem like an obvious distinction, but most software systems do not do this - i.e. they conflate the object and its name.
By separating representation from extent, this allows any given Thing to have more than one representation. For example, the set of all tables might be called "Table" and also called "Tisch". A given car could be identified both by its VIN number and its manufacturer serial number (note that the vehicle registration number only identifies a state of the vehicle from when it is manufactured to when it is unregistered).
This allows great precision about the extent of things whilst still allowing a great deal of flexibility in representation.
Set theory – categories of things
Meronymy – spatial relationships between things
Tuples – ordered relationships between things
Logic – deductive, monotonic, non-monotonic, …
Inference – probabilistic, evidential, …
Lexical semantics, mathematical linguistics, …
Mereology 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.
Like all complex systems, made up of many pieces
The pieces interact through data
Originally, piece makers (engineers, programmers) worked pair-wise (e.g., at design meetings, telephone, test sites) to figure out the interaction – involved much human interaction
With network “bus” architectures, easier to make interaction possible because the data is available
But understandable only by much human interaction1
The number of pieces continues to grow2
The number that need to interact continues to grow3
The scope of data they would like to use continues to grow4
XML provides documentation with the data, but humans still have to read and understand it.
e.g., Smart Ship, Integrated Bridge System, BMD
Continuing C4I – Combat System integration, Joint systems, OA and CANES SoA componentization
e.g., reference data such as ECDIS-N charts and GCCS-I3 use in Combat System
Provides for Relationships that aid Higher Level Command and Control Fusion Functions (ID, activity, intent, mission-related groups, etc.) with ISR context information
Uses taxonomies to allow detailed but interoperable extensions for sub-domains
Taxonomies again, to allow detailed but interoperable extensions
Allows aggregation of any object sets
Supports multiple hypotheses about any particular belief
Can represent uncertainty for ANYTHING – hostiles, neutrals, and even friendlies.
Parametrically (e.g., kinematic covariance matrices) and some discretely (e.g., ID “confusion matrices”)
Multiple hypotheses about any particular belief
Represents “pedigree” – what was used and how in coming up with some belief, including Context in which the belief was formulated (environmental and mission)-Beyond “Track History and Special Indicators”
Models true meaning (e.g., not just “indicators”), cause-effects (e.g., observation / measurement caused-by some object)
Depends on near-universal mathematics and science that all learn very similarly

23. Examples of some set theoretic formalisms

24. Elements, Subsets, and Powersets
“is-a” example:
Using mathematical constructs:
Powersets
Appears to D

25. Examples of some mereotopologic formalisms
Overlaps, spatial relationships (mereotopology)
Behaviors -- Sequences, before-after (4D mereotopology)

26. Properties
Properties and attributes of classes D

27. Diagram Conventions and Use of UML
Individual -- An instance of an Individual - something with spatio-temporal extent
Type -- The specification of a Type
IndividualType -- The specification of a Type whose members are Individuals
TupleType -- The specification of a Type whose members are tuples
Powertype -- The specification of a Type that is the set of all subsets of a given Type
Name -- The specification of a name, with the examplar text provided as a tagged value
NamingScheme -- The specification of a Type whose members are names
Note: tuples have place positions, just like FK’s in ER models
A&D
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]

28. DoDAF Domain Concepts are Specializations
Thing
Type
Individual
Individual Type
A&D
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)

29. 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
A&D
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)

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

31. DM2 Methodology

32. 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

33. 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.

34. 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
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.

35. 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)

36. 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)

37. 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 using formal ontology foundation
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 has entered a CM process

38. DM2 TWG
Open to just about anybody – Military, Govt, vendors, contractors, academics, …
Weekly Sessions on DCO
Collaboration Site:
Current DM2 walkthru briefing
Baseline DM2 CDM, LDM, and PES
Developmental DM2
IDEAS Foundation
Reference and Research folders
To join, send to
DM2 WG reports to the ARG reports to the TSEARG reports to the ERB

39. Physical Exchange Specification (PES)D

40. Use Cases Identification / Requirements Why do I exchange EA data?
JCIDS
JCD / ICD / CPD / CDD / FNA / FSA / FNA / AoA / TDS Evaluator – overlap and best value comparison
ISP / TISP Evaluator – interoperability comparison
Tester – “derive” / trace TEMP to
Preparer -- reuse
DAS
Milestone Reviews
Gate reviews
Functional Control Boards (FCB)
PPBE
Investment Review Boards (IRB)
OMB 300
Determine & defend FYDP
CPM / CPIC
Functional alignment of portfolio
PPBE support
Systems Engineering
Spec development
Ops Planning
Plans development
Interoperability Assurance
Ability to share architectures across enterprise
Discover the right architecture
False hits are costly – must be minimized
Must successively refine discovery/search
Search must:
be Federated across the DoD repositories
Include registry categories and taxonomies
Sample/snapshot data is required
Access the architecture
WSDL (web services discovery language)
Pass authentication credentials – single sign-on
Register the architecture
Type / quantity of data, by DM2 concept
By model (product)
By JCA (subject area)
By AV-1 (purpose, scope, format, dates, POCs, tools, TBD)
By taxonomies
Understand the accessed architecture
DM2
Taxonomies
Must meet DoD Legal/regulatory requirements
Must meet federal and DoD information sharing
DARS Functional Requirements
(Based on DoD CIO, JCS and OMB guidance – see refs)
Draft
Required Functions
Implement all major tenets of the Net-centric Data Strategy for architecture data [Make Data Visible and Accessible, Institutionalize Data Management, Enable Understandability and Trust, and Support Interoperability].
Make Data Visible
Expose data via query and navigation, subject to policy-based visibility controls
Implement DoD standards for visibility
Implement the DoD Discovery Metadata Specification (DDMS)
Implement federated search conforming to DoD standards
Make Data Accessible
Expose data in a publically accessible web site
Make data available in commonly useable formats
Provide data access services with controls appropriate to security, privacy and need-to-know constraints
Implement and Assess Data Management Best Practices
Implement data management best practice processes
Implement data editing controls
Implement data configuration management processes
Validate data quality in architectures
Validate use of “approved” vocabularies, taxonomies
Validate use of data federation standards
Validate content conformance with policy and guidance
Provide metrics on data quality
Enable Understandability
Identify vocabularies and schemas used
Identify content via content metadata exposure
Identify formats via metadata exposure
Support Trust in Data
Identify the source and authority of data
Identify data access controls
Identify the validation and approval status of data
Identify the validity time frame of data
Identify the currency of data (creation date and refresh cycle time)
Identify the intended use of data (purpose and scope)
Implement controls to ensure the integrity of metadata
Support Interoperability
Implement DoD, Federal and commercial standards for data exchange
Implement DoD standards for content metadata
Implement standards for data federation
Identify data formats and schemas used for data exchange
Support Compliance with the DoD IEA
Identify implementation of Data and Services Deployment practices in architectures
Identify implementation of Secured Availability practices in architectures
Identify implementation of Computing Infrastructure Readiness (CIR) practices in architectures
Identify implementation of Communications Readiness (CR) practices in architectures
Identify implementation of NetOps Agility (NOA) practices in architectures
Support JCIDS Processes
Support Capability-Based Architecture (CBA) alignment and assessment
Validate architecture content and quality directed by JCS instruction
Identify validation status of architectures
Identify KPP content in architectures
Identify Joint Potential in architectures
Support Compliance with OMB Guidance for FEA Practices
Support Segment identification
Identify alignment of architectures with Segments
Identify alignment of architectures with FEA reference models
Identify reuse of systems, services, and data in architectures
Specific DARS functions
Ability to tag architectures, architecture artifacts and architecture reference data sets with DoD Discovery Metadata Specification (DDMS)-conformant discovery metadata and provide discovery services in conformance with enterprise content discovery standards. [NCDS Visibility]
Provide automated discovery metadata tagging of registered content,
Provide editing of discovery metadata,
Provide content discovery services
Ability to import, store, index, reference, link, and export architecture data (including taxonomies, reference models, fit-for-purpose data sets, vocabularies, etc.) with authenticated role-based and/or attribute-based controlled access to support architecture development in conformance with DoD EA standards for data structure, semantics and content. [NCDS Accessibility, Understandability and Trust]
Provide content registration services,
Provide group-based visibility and access control to registered content,
Integrate user authentication with DKO,
Provide data import/export services conforming to the DoDAF Meta Model (DM2)
Ability to identify the source and authority of architecture data. [NCDS Trust]
Ability to restrict the recording of source and authority properties of data to authorized parties.
Ability to tag, import, export, discover and visualize the source and authority properties of data.
Ability to restrict the recording of data authority properties in discovery metadata to ensure trust in the pedigree of architecture data. [NCDS Trust]
Ability to federate authoritative architectures, architecture artifacts and reference data with traceability to authority for federation.
Implement architecture federation IAW DoD Architecture Federation Strategy, [NCDS Trust, Understandability, FEA practices]
Ability to federate/align architectures and architecture artifacts, including taxonomies, vocabularies and reference data, with DoD EA segments, Joint Capability Areas and other reference models, reference architectures and taxonomies. [DARS FY-09 Functional Support Agreement, FEA Practice Guidance]
Ability to provide community-based visibility and access control over architecture data and discovery metadata. []
Ability to validate conformance of architecture data with DoD standards, policy and guidance for architecture content.
Ability to provide metrics on federated architecture content and conformance with EA standards, policy and guidance.
Facilitate architecture exchange and interoperability.
Ability to import, export, and manage taxonomies and vocabularies
DARS Roles
Authoritative source for DoD architecture data and EA standards.
Tool for assessment of architecture conformance of with DoD EA standards.
Tool for assessment of data quality management practices for authoritative data sources.
Tool for managing authoritative architectures, including segment, capability and solution architectures, and the federated structure of the DoD EA.
Tool for assessing conformance of architectures with EA federation standards for alignment with segment and other reference architecture standards.
References
DoDD , Data Sharing in a Net-Centric Department of Defense
DoD Architecture Federation Strategy
FEA Practice Guidance
Federal Enterprise Architecture Data Reference Model V 2.0
FAQs
Can required functions be achieved by DKO, the DMR, DISR, JCPAT, KMDS, DITPR, DNAP-IT, or a combination of these capabilities?
How does DARS relate to the DMR?
How does DARS relate to DISR?
How does DARS relate to the DITPR?
How does DARS relate to the SOA Foundation?
How does DARS support acquisition decision making?

41. 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

42. Exporter
We developed (Greg and Ian Bailey in UK MOD) an XSD generator to generate the PES XSD’s from the UML DM2 LDM. We did that because the IDEAS profile that we load into Sparx when we do DM2 modeling so we can use it as an ontology tool was not understandable by Sparx’s native XSD generator.
We didn’t use RDFS/OWL because of our user community (they don’t interoperate with RDFS / OWL, but they do with XML -- tools, DB’s, etc.) but even though we didn’t use RDFS/OWL, all the semantics, including the formal ontology, are explicit in the DM2 XML.

43. Components One per DoDAF model (52) with necessary and optional parts
1 comprehensive with all optional for “fit for purpose” models
3 references – IDEAS Foundation, Security marking (IC-ISM), and Pedigree
Physical Exchange Specification (PES) XSD General Structure
Wrapper, describing that the document is
Independent entities with naming and aliases
Associations
Constraints
Similar to UCORE
Every piece of data:
is tied to the IDEAS Foundation
has a classification marking – a “portion mark”
has a pedigree (chainable) – who, how,… it came into being
# XSD’s
Comprehensive – customize for fit-for-purpose
At this time, local copies of the IDEAS Group (foundation) and DNI (IC-ISM) URI’s.
Every piece of data can have a IC-ISM classification marking and pedigree

44. 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

45. Pedigree
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.

46. Definition of Terms Pedigree: information lineage
a chain of sets of observations or object beliefs used to derive the information along with a description of the derivation (i.e., how the set of observations or object beliefs were used)
this definition of Pedigree includes the information’s Provenance, that is Provenance Ì Pedigree
Source Metadata: information about the source
a characterization of the source, whether it be a sensor, individual operators, or a system of machines and operators
related to Pedigree but is information about the Source, not the particular piece of information being asserted.

47. P&SM Notes P&SM chains can be traversed bi-directionally
P&SM lineage describes how a piece of information came about
P&SM descendancy describes how a piece of information was used.
Context could be important in Pedigree
“Environmental Context” – what background information did I take into account in deriving this information? (And how did I derive that information, i.e., what was my Context estimation P&SM.)
“Mission Context” – what am I doing that focusses and influences the way I perceive things
There can be different levels of detail or granularity of P&SM for different purposes.
In DM2, we provided for the most granular, allowing user to use aggregates as necessary
IA / Security
Source Metadata must allow for information sharing while protecting sources and methods

48. Pedigree Model Based on DM2 Resource Flow Model
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.

50. Resource Flow Model Notes
The term flow implies that something (e.g., materiel, information) is moving from point A to point B, hence the use of the foundation concept of “overlap”.
Resource Flows are Activity-based, not Performer based since a Performer cannot produce or consume a resource other than by conduct of a production or consumption activity.
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 Doctrine, Organization, Training, Material, Leadership and Education, Personnel, and Facilities (DOTMLPF).
Performers 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.
The exchange or flow triple may have standards (Rules) associated with it such as Information Assurance (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.
Resource Flow modeling can be performed at varying levels of detail and fidelity depending on the areas of concern being analyzed and the solutions being sought. The upper-level aggregations have been termed need lines in previous versions DoDAF. Other terminology expressing levels of aggregation are used depending on the community of interest (e.g., The SysML modeling standard uses lifeline).

51. Information Pedigree – workflow model
2. Resources Used, e.g., other Information
6. Where done
5. Measures in the production, e.g., QoS, uncertainties
1. Information Production Activity
~ Open Provenance Model (provenance = linked together pedigrees)
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
4. Rules followed in the production
3. Who did the production

52. Pedigree Chaining Pedigree Objectd State Hypothesis t6
Source Metadata
Objectd State Hypothesis t6
Object C and Object A believed to be working as one “mission object” (Object D)
ObjectD State Hypothesis t5
Attribute x Hypothesis
Pedigree
ObjectC State Hypothesis t4
Pedigree
Source Metadata
Source Metadata
Observation t6
Pedigree
Pedigree
Source Metadata
Object B ESM track (Object B) believed to be same as Object A
Source Metadata
ObjectA State Hypothesis t3
Contexta State Hypothesis tx
Reference Data
ObjectB State Hypothesis t2
Pedigree
Pedigree
Source Metadata
Source Metadata
Source Metadata
Pedigree
Pedigree
Source Metadata
Source Metadata
Pedigree
Reference Data
Upon another SIGINT observation that the two are communicating, Object D’s intent is believed to be “attacking” because ESM mode was WRM, threat context is hostile probable
ObjectA State Hypothesis t1
Pedigree
Observation t1
Source Metadata
Pedigree
Later ELINT observation, EWIR referenced
Source Metadata
ObjectA State Hypothesis t0
Source Metadata
= Source Metadata
Pedigree
Source Metadata
Observation t0
Initial observation causes creation of Object A
Pedigree
Source Metadata

53. Example of Pedigree and Workflow in Biologic Research Community
Taverna network architecture diagram

54. DM2 PES Examples

55. Example: Activity Decomposition Tree
Elements
Activity
activityWholeConsumingPartOfActivity
activityWholeProducingPartOfActivity
ConsumingPartOfActivity
ProducingPartOfActivity

56. Activity Decomposition Tree XSD Root

57. Example: Activity Model
Elements
Activity
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

58. Activity Model Root
Again, very flat.

59. 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.

60. 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

61. 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

62. Tools

63. Unified Profile for DoDAF and MODAF (UPDM)
Object Management Group (OMG) standard
UPDM team consists of many UML vendors such as IBM, Sparx, Artisan, No Magic, and industry and Government participants including Lockheed-Martin, Raytheon, and DoD CIO
UPDM 1.0, based on DoDAF 1.5, was approved this Summer
UPDM 2.0 RFP is in draft
UPDM 2.5 is required to be DoDAF 2 conformant; DoDAF 2 conformance includes PES
Will provides a way for UPDM/MOF tools to exchange data with non-UPDM PES-conformant tools and databases such as EISP, JACAE, and maybe later, M&S tools and databases like Naval Simulation System, NARS, DITPR, and JCAMS
Aid DoD EA COI information sharing
Since DM2 includes IDEAS, makes UPDM 2.0 beneficial to future MODAF and NAF

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

65. UML XMI – Where it fits in the DoD EA COI
XMI is a neutral format for UML file
It 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
But NOT a neutral format for non-UML tools and databases across the DoD EA COI
XMI is hard for UML tools to get right. Not designed for interoperation with non-UML tools and databases.

66. DM2 (including PES), IDEAS Foundation V1.0, and UPDM 2.5 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

67. Questions?

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

69. 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.)

70. Example Conditions

71. Can go into very precise modeling using temporal parts (states)
time
Dave
Dave’s Document, Copy 1, in flow state
Copy and Send
Ian
Copy
Dave’s Document, copy 1
Flow process
Send
part
Dave’s Document, Orig
Receive
part
Dave’s Document, copy 1
Dave’s Doc Ind Type = {Orig, Copy1, Copy2, …}
Dave’s Doc Ind Type Orig = {Orig}
Dave’s Doc Ind Type Copies = {Copy1, Copy2, …}

72. Joint Action: Fatma Selling Cup to Dave
time
Buyer
(PersonType)
Seller
(PersonType)
Transfer
Handover
Dave
(Person)
typeInstance
Handtake
Fatma
(Person)
typeInstance
Transfer
Handover
Handtake
ActivityTypes
Cash (ResourceType)
Cup (MaterielType)

73. Joint Action: Execution Context Fatma Selling Cup to Dave
time
Buyer
(PersonType)
Seller
(PersonType)
Transfer
Handover
Dave
(Person)
typeInstance
Handtake
Fatma
(Person)
typeInstance
Transfer
Handover
Handtake
ActivityTypes
Cash (ResourceType)
Cup (MaterielType)

74. Execution Context Producer Consumer Resource Rules Measures
Execution context (set of dispositional (template) Resource Flow models)
Buy Activity
Sell Activity
Dave and all his $10,000
Make coffee cup visible (Resource Representations)
Fatma and her coffee cup
Establish understanding of communication means (Rules)
Interaction (set of dispositional (template) Resource Flow models)

75. Desired Effects and Requirements: to neutralize Taliban
Ways and means B
Whole-life of Taliban
Neutralized (civilized world desired effect)
Ways and means A
Current day
Rule the world (barbarian world desired effect)
time
Resource states, something with start time and end time
Shows ability to achieve desired effect as being a possible future state, among many, of something. t0 t1 t2
Solution space (super-subtype) tn

76. 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
Successive refinement of the architecture description. For any phase, it is traceable to the prior (pedigree). The prior phase becomes the rules that constrain the activities of the next performer – adherence to requirements baseline.
They’re all aiming at the same future Thing, just describing it in more detail and in different ways as you go along.
Rules
constrain
Rules
constrain
constrain
constrain
Worker
Technician
Engineer
Architect
Executive
Strategic
JCD
IOC
time