1. VERSION 15 UPDM Meeting 3 August 2009
11/19/ :55
DoDAF 2.0 Meta Model (DM2)
Why IDEAS?
UPDM Meeting
3 August 2009

2. Common Relationship Patterns Emerged -- Leveraged Ongoing IDEAS Foundation --
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
DoDAF 2 domain concepts are extensions to the formal foundation
Inherits from the IDEAS 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.

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

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

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

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

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

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

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

10. Rules are spatio-temporal
Rule applies across this whole
100 km/hr
Description of the rule
(information)
Exemplar text

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

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

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

14. Desired Effects and Requirements: to neutralize Taleban
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 t0 t1 t2
Solution space (super-subtype) tn

15. Backups

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

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