UCore SL Training Event March 17, 2010 Presenters Barry Smith, , Lowell Vizenor, , National Center for Ontological Research (NCOR) Sponsor James Schoening, , Army Net-Centric Data Strategy Center or Excellence in Support of Army CIO/G

Session 1: UCore, the Net-Centric Data Strategy and the Ontological Perspective Overview Ontology successes and failures The Promise of the Universal Core Realizing the Net-Centric Data Strategy UCore SL history / team / acknowledgements UCore SL benefits 2

Why the success of ontology still too often brings failure Ontology technology is designed to break down data silos by bringing controlled vocabularies for the formulation of data schemas, definitions, digests... Unfortunately the very success of this approach is leading to the creation of multiple new silos, because multiple ontologies are being created in ad hoc ways 3

It is easier to write useful software if one works with a simplified model (“…we can’t know what reality is like in any case; we only have our concepts…”) This looks like a useful model to me (One week goes by:) This other thing looks like a useful model to him Data in Pittsburgh does not interoperate with data in Vancouver Science is siloed The standard engineering methodology 4

Ontology success stories, and some reasons for failure A fragment of the Linked Open Data in the biomedical domain 5

What does ‘linked’ mean?’ Strategy serves retrieval, but not reasoning 6

poisoning of wells no global governance poor treatment of time data and objects confused uncontrolled proliferation of links 7

What you get with ‘mappings’ All in Human Phenotype Ontology (= all phenotypes: excess hair loss, splayed feet...) mapped to all organisms in NCBI organism classification allose in ChEBI chemistry ontology Acute Lymphoblastic Leukemia in National Cancer Institute Thesaurus 8

What you get with ‘mappings’ all phenotypes (excess hair loss, splayed feet...) all organisms allose (a form of sugar) Acute Lymphoblastic Leukemia 9

Mappings are hard They are fragile, and expensive to maintain The goal should be to minimize the need for mappings 10

Uses of ‘ontology’ in PubMed abstracts 11

By far the most successful: GO (Gene Ontology) 12

GO provides a controlled system of terms for use in annotating (describing, tagging) data multi-species, multi-disciplinary, open source contributing to the cumulativity of scientific results obtained by distinct research communities compare use of kilograms, meters, seconds … in formulating experimental results 13

Gene products involved in cardiac muscle development in humans 14

Hierarchical view representing relations between represented types 15

$100 mill. invested in literature curation using GO over 11 million annotations relating gene products described in the UniProt, Ensembl and other databases to terms in the GO experimental results reported in 52,000 scientific journal articles manually annoted by expert biologists using GO ontologies provide the basis for capturing biological theories in computable form allows a new kind of biological research, based on analysis and comparison of the massive quantities of annotations 16

GO is amazingly successful in overcoming problems of balkanization but it covers only generic biological entities of three sorts: – cellular components – molecular functions – biological processes and it does not provide representations of diseases, symptoms, … 17

RELATION TO TIME GRANULARITY CONTINUANTOCCURRENT INDEPENDENTDEPENDENT ORGAN AND ORGANISM Organism (NCBI Taxonomy) Anatomical Entity (FMA, CARO) Organ Function (FMP, CPRO) Phenotypic Quality (PaTO) Biological Process (GO) CELL AND CELLULAR COMPONENT Cell (CL) Cellular Component (FMA, GO) Cellular Function (GO) MOLECULE Molecule (ChEBI, SO, RnaO, PrO) Molecular Function (GO) Molecular Process (GO) Original OBO Foundry ontologies (Gene Ontology in yellow) 18

Initial Members – CHEBI: Chemical Entities of Biological Interest – GO: Gene Ontology – PATO: Phenotypic Quality Ontology – PRO: Protein Ontology – XAO: Xenopus Anatomy Ontology – ZFA: Zebrafish Anatomy Ontology The OBO Foundry 19

Examples of Ontologies being built ab initio within the OBO Foundry – Environment Ontology (EnvO) – Infectious Disease Ontology (IDO) – Malaria Ontology (IDO-MAL) – Influenza Ontology (InfluenzO) – Ontology for Biomedical Investigations (OBI) – Ontology for General Medical Science (OGMS) – RNA Ontology (RNAO) – Subcellular Anatomy Ontology (SAO) – Vaccine Ontology (VO) 20

Foundry / Library strategy 21

Library (defined by metadata registry) 22

Foundry (defined by commitment to collaboration) 23 Organism Anatomic Entity Organ Function PhenotypeBiological Process Cell Part Cellular Function MoleculeMolecular Function Molecular Process

OBO Foundry Principles  The ontology is open and able to be integrated freely with other resources  It is instantiated in a common formal language.  Developers commit to working to ensure that, for each domain, there is community convergence on a single ontology,  and agree in advance to collaborate with developers of ontologies in adjacent domains. 24

OBO Foundry Principles  Common architecture simple top level (Basic Formal Ontology): shared Relation Ontology:  Common governance (coordinating editors)  Common training 25

OBO Foundry Principles  Common governance (coordinating editors)  Common training  Common architecture simple top level (Basic Formal Ontology): shared Relation Ontology: 26

> 50 ontology initiatives using BFO Examples Nanoparticle Ontology (NPO) ChemAxiom – Ontology for Chemistry Cleveland Clinic Semantic Database in Cardiothoracic Surgery National Cancer Institute Biomedical Grid Terminology (BiomedGT) Neural Electromagnetic Ontologies (NEMO) EU Ontology for Risks Against Patient Safety Information Artifact Ontology (IAO) 27

Benefits Modular development guarantees additivity of annotations Removes the need for ‘mappings’ Common training implies portability of expertise and pooling of lessons learned through practice Serves as antidote to current business models, which favor one-off artifacts designed to meet local needs 28

Pistoia Alliance Open standards for data and technology interfaces in the life science research industry  consortium of major pharmaceutical companies working to address the data silo problems created by multiplicity of proprietary terminologies  declare terminology ‘pre-competitive’  require shared use of OBO Foundry ontologies in presentation of information 29

Basic Formal Ontology Continuant Occurrent process, event Independent Continuant entity Dependent Continuant property 30

CONTINUANTOCCURRENT INDEPENDENTDEPENDENT ORGAN AND ORGANISM Organism (NCBI Taxonomy) Anatomical Entity (FMA, CARO) Organ Function (FMP, CPRO) Phenotypic Quality (PaTO) Organism-Level Process (GO) CELL AND CELLULAR COMPONENT Cell (CL) Cellular Component (FMA, GO) Cellular Function (GO) Cellular Process (GO) MOLECULE Molecule (ChEBI, SO, RNAO, PRO) Molecular Function (GO) Molecular Process (GO) rationale of OBO Foundry coverage GRANULARITY RELATION TO TIME 31

Anatomy Ontology (FMA*, CARO) Environment Ontology (EnvO) Infectious Disease Ontology (IDO*) Biological Process Ontology (GO*) Cell Ontology (CL) Cellular Component Ontology (FMA*, GO*) Phenotypic Quality Ontology (PaTO) Subcellular Anatomy Ontology (SAO) Sequence Ontology (SO*) Molecular Function (GO*) Protein Ontology (PRO*) OBO Foundry Modular Organization 32 top level mid-level domain level Information Artifact Ontology (IAO) Ontology for Biomedical Investigations (OBI) Spatial Ontology (BSPO) Basic Formal Ontology (BFO)

UCore an XML schema... containing agreed-upon representations for the most commonly shared and “universally understood concepts of who, what, when, and where”

The Promise of UCore “UCore : The Twitter of Information Sharing” 2. a common technical approach and vocabulary that will enable information sharing between Federal, state, regional, and local governments, including the IC, UCore 2.0 is reality-based (it is a model of reality, rather than a model of information) Motto of realist ontology: Where information about one and the same reality is siloed, reality itself can serve as the benchmark for information integration

UCore 2.0 Taxonomy 35

UCore 2.0 Taxonomy (Continuant vs. Occurrent) 36

37

38

UCore Semantic Layer 39 An incremental strategy for achieving semantic interoperability Leaves UCore 2.0 as is, but provides a logical definition for each term in UCore 2.0 taxonomy and for each UCore 2.0 relation UCore SL is designed to work behind the scenes in UCore 2.0 application environments as a logical supplement to the UCore messaging standard

UCore SL history / team / acknowledgements Taxonomy Tiger Team prior to release of UCore 2.0 U.S. Army Net-Centric Data Strategy Center of Excellence / Army CIO/G-6 (Lead and sponsor) National Center for Ontological Research (NCOR) (Developer) Office of Director of National Intelligence (ODNI) (Contributor) 40

UCore SL history / team / acknowledgements Taxonomy Tiger Team prior to release of UCore 2.0 Role of BFO (Continuants vs. Occurrents) Role of Relation Ontology (RO) Role of Definitions 41

42 The UCore SL Taxonomy OWL Thing Entity PhysicalEntity InformationContentEntity Property Event

43 UCore SL Taxonomy (Blue) overlaid with UCore 2.0 Taxonomy (Red)

Continuant UCore: Entity Occurrent UCore: Event 44 Blinding Flash of the Obvious

Continuant Occurrent process, event Independent Continuant entity Dependent Continuant property 45

CONTINUANTOCCURRENT INDEPENDENTDEPENDENT ORGAN AND ORGANISM Organism (NCBI Taxonomy) Anatomical Entity (FMA, CARO) Organ Function (FMP, CPRO) Phenotypic Quality (PaTO) Organism-Level Process (GO) CELL AND CELLULAR COMPONENT Cell (CL) Cellular Component (FMA, GO) Cellular Function (GO) Cellular Process (GO) MOLECULE Molecule (ChEBI, SO, RNAO, PRO) Molecular Function (GO) Molecular Process (GO) rationale of OBO Foundry coverage GRANULARITY RELATION TO TIME 46

> 50 ontology initiatives using BFO Examples Nanoparticle Ontology (NPO) ChemAxiom – Ontology for Chemistry Cleveland Clinic Semantic Database in Cardiothoracic Surgery National Cancer Institute Biomedical Grid Terminology (BiomedGT) Neural Electromagnetic Ontologies (NEMO) EU Ontology for Risks Against Patient Safety Information Artifact Ontology (IAO) 47

UCore SL supports leverage of UCore 2.0 through integration with other OWL 2.0 resources logically articulated definitions use of W3C-standards-based software in: enhanced reasoning with UCore message content enhanced quality assurance consistent evolution of UCore 48

UCore SL supports leverage of UCore 2.0 through integration with other OWL 2.0 resources logically articulated definitions use of W3C-standards-based software in: enhanced reasoning with UCore message content enhanced quality assurance consistent evolution of UCore 49

50 Potential benefits for UCore 2.0 Provide automatic warnings e.g. for potential ambiguities in UCore 2.0 terms and definitions Automatic consistency checking when extensions to UCore 2.0 are proposed Identify logical gaps in UCore 2.0 taxonomy and relations Allow integration of UCore 2.0 XML-based technology with W3C (Semantic Web) content

Potential benefits for UCore 2.0 users Provide flexible refactoring of UCore 2.0 for different (DoD, IC, DoJ, …) purposes, while preserving interoperability Allow development of standards-based tools to support and enhance verification of UCore messages for correctness Help UCore users work more effectively in retrieving and processing messages Provide basis for creating consistent extensions that work well across multiple domains employing strategies analogous to those of the OBO Foundry

Benefits of Coordination Each new Community of Interest (COI) can profit from lessons learned at earlier stages and avoid common mistakes can more easily reuse tested software resources can collect data in forms which will make it automatically comparable with data already collected No need to reinvent the wheel 52

End of Session 1 53

Session 3: Effecting Successful Data Coordination The human factors: traffic rules for ontologists Top Down / Bottom Up (TDBU) methodology Dealing with vocabulary conflicts across communities Registration of metadata Traffic rules for definitions Traffic rules for relations 54

The human factors Computers will process UCore and its extensions But humans must create and maintain them, which means: natural language definitions (top-down) consistent traffic rules and associated governance and developer and user training (bottom-up) feedback mechanisms to ensure domain accuracy (realism) and incremental improvement of resources virtuous cycle of use and improvement 55

Examples of traffic rules Populate with singular nouns Always check that terms in your ontology have instances in reality Don’t confuse ontology with epistemology (there are no unknown infectious agents) Don’t confuse use with mention (swimming is healthy; swimming has two vowels) Traffic rules for definitions 56

Examples of definitions from UCore 2.0 GeographicFeature =def. Physical or cultural areas, regions or divisions that can be defined in terms of geographic coordinates. (Derived from Geographic Names Information Service. USGS.) CriminalEvent =def. An event relating to or constituting a crime; an action which constitutes a serious offence against an individual or the state and is punishable by law. (Verbatim from Concise Oxford English Dictionary, 11th Edition) 57

Problems with these definitions Violate the traffic rule: “Ensure agreement in number between term and definition” Expand vocabulary using undefined terms Not logically decomposable Provide multiple distinct meanings for single terms Provide opportunities for forking (and thus for inconsistency) when extensions are created 58

Definitions in UCore SL For ‘A’ the child term and ‘B’ its immediate parent, all definitions have the form: an A is a B which Cs Example: GeographicEvent =def a NaturalEvent that affects some GeographicFeature. 59

Advantages of Aristotelian Definitions Work on formulating definitions provides a check on the correctness of the backbone is_a hierarchy Every definition logically encapsulates all the definitions of all higher terms within the relevant single branch This simple traffic rule (“always use Aristotelian definitions) contributes to coordination of the ontology development effort 60

Simple traffic rules for relations Distinguish instance-level and type-level relations For example Mary has_part brain human being has_part brain Mary has_part uterus Not human being has_part uterus 61

The All-Some Rule Ontology terms are always on the level of types For ontology terms ‘A’ and ‘B’, we should assert A R B only if: all instances of A stand in the instance- level counterpart of the relation R to some instance of B 62

The All-Some Rule For example Mary has_part uterus Not human being has_part uterus 63

TBDU Methodology If we develop an ontology Bottom-Up, it may meet a specific need, but will not interoperate with other ontologies. If we start with an upper ontology and extend just Top-Down, it probably won't meet the specific needs of a given system. The solution is to do both at the same time and iterate until the ontology is both a clean Top-Down extension and also expresses the Bottom-Up semantics needed by specific systems. (Jim Schoening) TDBU technical paper and wiki page due for release ca. April

How to create an ontology from the top down Continuant Occurrent (Process, Event) Independent Continuant Dependent Continuant 65

Example: The Cell Ontology

Library (defined by metadata registry) 67

Foundry (defined by commitment to collaboration) 68 Organism Anatomic Entity Organ Function PhenotypeBiological Process Cell Part Cellular Function MoleculeMolecular Function Molecular Process

Dealing with vocabulary conflicts across communities Commitments to collaboration between developers working in overlapping or adjacent domains The goal is: one authoritative representation for each domain To achieve this goal: border treaty negotiations community-specific views of the terminology (using exact synonyms) 69

Metadata: What should a COI do? from FAQ for Communities of Interest in the Net-Centric DoD 1. Make their data assets visible, accessible and understandable... by tagging their data assets with discovery metadata, and posting those metadata to searchable catalogs. 2. Define COI-specific vocabularies and taxonomies to promote semantic and syntactic understanding of data assets. 3. Register semantic and structural metadata to the DoD Metadata Registry. By posting metadata to the DoD Metadata Registry, COIs can work together to converge on metadata specifications/standards that support many functions across the Department. 70

Library / Foundry strategy applied Library = metadata posted to DoD Metadata registry Foundry = commitment to collaboration to achieve convergence on a single non-redundant module for each domain – no need for mappings 71

Prospective Standardization: Two sets of issues Lay down a set of evolving (and increasingly rigorous) standards to achieve semantic interoperability 1.how to deal with legacy resources? – here mappings are needed; modularity provides a unique target for mappings 2.how to create new resources with maximum likelihood of effectiveness? – those in need of new resources will be able to identify what exists, who developed it, how to tailor their needs to the evolving consensus standard 72

Anatomy Ontology (FMA*, CARO) Environment Ontology (EnvO) Infectious Disease Ontology (IDO*) Biological Process Ontology (GO*) Cell Ontology (CL) Cellular Component Ontology (FMA*, GO*) Phenotypic Quality Ontology (PaTO) Subcellular Anatomy Ontology (SAO) Sequence Ontology (SO*) Molecular Function (GO*) Protein Ontology (PRO*) OBO Foundry Modular Organization 73 top level mid-level domain level Information Artifact Ontology (IAO) Ontology for Biomedical Investigations (OBI) Spatial Ontology (BSPO) Basic Formal Ontology (BFO)

UCore 2.0 / UCore SL Extension Strategy 74 top level mid-level domain level Can we use a Top-Down/Bottom Up strategy to create an ontology for NIEM’s 1450 terms, as an extension of UCore-SL?

End of Session 3 75

Session 4: Applications of UCore SL Using semantics for quality assurance of UCore – Preamble on BFO: Role – The change management process – Creation of coherent extensions of UCore UCore SL and external resources – NIEM – C2 Core 76

Preamble on BFO’s Treatment of Properties Continuant Occurrent process, event Independent Continuant entity Dependent Continuant property property depends on bearer 77

depends_on Continuant Occurrent process, event Independent Continuant entity Dependent Continuant property event depends on participant 78

instance_of Continuant Occurrent process, event Independent Continuant event Dependent Continuant property types instances 79

Continuant Independent Continuant Dependent Continuant Non-realizable Dependent Continuant (quality, e.g. mass) Realizable Dependent Continuant (role) 80

depends_on Continuant Occurrent process Independent Continuant entity Dependent Continuant quality temperature depends on bearer 81

realization depends_on realizable Continuant Occurrent Independent Continuant entity Dependent Continuant role Process of realization 82

Continuant Independent Continuant Specifically Dependent Continuant Quality Realizable Dependent Continuant (function, role, disposition) 83

Roles as Properties in UCore SL OWL Thing Entity PhysicalEntity InformationContentEntity Property Role Event

Roles as Properties in UCore SL A soldier is sometimes warm and sometimes cold. But UCore 2.0 does not distinguish WarmSoldier and ColdSoldier classes. But the current UCore 2.0 treats e.g. Cargo as an Entity: Cargo =def. goods or merchandise conveyed in a ship, airplane or other vehicle How does UCore 2.0 treat locations? There is an entity, a location, and a relationship of located_at together with a timestamp. Why not embrace a parallel treatment for Roles ?

UCore 2.0 has no Properties The current UCore Entity hierarchy makes no distinction between entities that bear properties and the properties themselves The UCore 2.0 set of relationships does not include the needed relationship for binding a property to its bearer But, the UCore treatment of location is instructive on how to remedy this

Roles Proposal: Add Role to UCore 2.0 as child of Entity role =def. a dependent continuant entity which exists because the bearer is in some special physical, social, or institutional set of circumstances Examples: commander role, soldier role, member role, first responder role Reject. Adds unnecessary complexity and overhead to the digest without clear benefit for associated cost."

Yet the lack of a Role class brings significant shortfall in informational content for example as concerns time. Consider a bill of lading that includes the information that a personnel carrier was an item of cargo. A UCore digest digest must convey this via multiple “what” assertions: e/ /ucore/2.0/codespace/ Roles

And similarly in the case of an intelligence report that includes the information that a person was the source of certain information: ore.gov/ucore/2.0/codespace/

Entities and their Roles TSGT Jones is always a person, but he is an “Information Source” while on a mission

Roles Lack of roles will have adverse effects on interoperability, as COI’s extend UCore 2.0 because it will lead to increasing multiple parentage and thus to forking and integration problems. For example, MedicalEquipment will need to be sub-typed under both Equipment and Cargo. Such multiple inheritance leads to forking and difficulties for merging ontologies. One COI may extend cargo by the means of conveyance (e.g. Air Cargo, Water Cargo, Ground Cargo), another by the objective (e.g. Humanitarian Aid Cargo, Military Cargo, Medical Cargo).

Roles Recommended Solution: Supplement the UCore 2.0 Entity sub-hierarchy with two new entity types: Object and Dependent Entity as Immediate children of Entity. Add entity type of Role as immediate child of Dependent Entity. (Add other Property types as needed) Add Object-Dependent Entity type relationship bearer_of These terms will support the coherent use of UCore 2.0, but we anticipate that (like ‘Entity’) they will not be used in UCore messages.

Observation report UCore.Person = John Jones UCore.Role = Tech Sergeant UCore.Role = Information Source Role UCore.Organization = Opposition Force UCore.GroundVehicle = Personnel Carrier UCore.Property = Armored submitted by TSgt. John Jones containing the information of the presence of an opposition force armored personnel carrier.

UCore 2.0 Proposed Change Proposal: CyberAgent should be a subclass of Agent, add Agent to taxonomy. "Reject. The case has not been made that an operational/ mission/business gap results from withholding the term "Agent" from the taxonomy. However, if it were determined that "Agent" should reside in the taxonomy, we would agree that the terms "CyberAgent", "Organization" and "Person" should be child elements of it.“ (Revised proposal: Add Agent as a Role)

UCore 2.0 Proposed Change PoliticalEntity should be a subclass of Group Reject: President is_a PoliticalEntity Response: 1. (see under Role) 2. President does not satisfy the definition of PoliticalEntity PoliticalEntity =def. An organized governing body with political responsibility in a given geographic region. (Derived from Concise Oxford English Dictionary, 11th Edition, 2008)

Other Changes Proposed for UCore Alert Event  sub-class of Communication Event. 2. Weather Event  sub-class of Natural Event. 3. Exercise Event  sub-class of Planned Event. 4. Financial Instrument  sub-class of Document.

Library / Foundry strategy applied Library = metadata posted to DoD Metadata registry Foundry = commitment to collaboration to achieve convergence on a single non-redundant module for each domain – no need for mappings 97

NIEM and UCore (from NIEM Newsletter, Jan. 2009) April 17, 2008 memo “U.S. Department of Defense (DoD) and Intelligence Community (IC) Initial Release of Universal Core: UCore is a standard approach to representing a few elements of information common to many exchanges in the DoD and IC The involvement of the NIEM program in the requirements, design, and implementation of UCore 2.0 ensured its compatibility with NIEM UCore 2.0 is largely agnostic with respect to the information exchange vocabularies of various communities. UCore 2.0 messages can supplement the basic UCore "digest" with richer, more detailed information content in the form of NIEM "payloads" 98

UCore 2.0 (Vehicle terms) uc:Vehicle – uc:Aircraft – uc:GroundVehicle – uc:Spacecraft – uc:Watercraft This is what we mean when we say that UCore 2.0 is reality based 99

NIEM Core (sample Vehicle terms) 100 nc:Vehicle nc:VehicleAxleQuantity nc:VehicleBrand nc:VehicleBrandCode nc:VehicleBrandDate nc:VehicleBrandDesignation nc:VehicleBrander nc:VehicleBranderCategoryCode nc:VehicleBranderIdentification nc:VehicleCMVIndicator nc:VehicleColorInteriorText nc:VehicleColorPrimaryCode nc:VehicleColorSecondaryCode nc:VehicleCurrentWeightMeasure nc:VehicleDoorQuantity nc:VehicleEmissionInspection nc:VehicleGarage nc:VehicleGarageIndicator nc:VehicleIdentification nc:VehicleInspection nc:VehicleInspectionAddress nc:VehicleInspectionJurisdictionAuthority nc:VehicleInspectionJurisdictionAuthorityText nc:VehicleInspectionSafetyPassIndicator nc:VehicleInspectionSmogCertificateCode nc:VehicleInspectionStationIdentification nc:VehicleInspectionTestCategoryText nc:VehicleInvoiceDate nc:VehicleInvoiceIdentification nc:VehicleMSRPAmountnc:VehicleMakeCode nc:VehicleMaximumLoadWeightMeasure nc:VehicleModelCode nc:VehicleMotorCarrierIdentification nc:VehicleOdometerReadingMeasure nc:VehicleOdometerReadingUnitCode nc:VehiclePaperMCOIssuedIndicator

Some NIEMCore Vehicle terms 101 nc:VehicleBrand nc:VehicleBrandCode nc:VehicleBrandDate nc:VehicleBrandDesignation nc:VehicleInspectionJurisdictionAuthority nc:VehicleInspectionJurisdictionAuthorityText nc:VehicleInspectionSafetyPassIndicator nc:VehicleInspectionSmogCertificateCode nc:VehicleInspectionStationIdentification nc:VehicleInspectionTestCategoryText

102 Clay Robinson, Office of DoD CIO, 9 September 2009

UCore 2.0 / UCore SL Extension Strategy 103 top level mid-level domain level Can we use a Top-Down/Bottom Up strategy to create an ontology for NIEM’s 1450 terms, as an extension of UCore-SL?

C2 Core Introductory remarks by Jim Schoening on the status of the C2 Core Conceptual Data Model 104

Extending UCore 2.0 Goal: A C2 Taxonomy – Using categories that extend from UCore 2.0 – To act as a mid-layer ontology – To connect UCore 2.0 with COI controlled vocabularies – Using doctrinally sound terminology 105

JP 5-0 Joint Operation Planning JP 1-02 DoD Dictionary of Military and Related Terms JP Joint Doctrine for Command and Control JP 3-0 Joint Operations FM 3-0 Operations MCDP Command and Control C2 Core Ontology Doctrinal Source 106

Extending UCore 2.0 A C2 Ontology Resource –Using categories that extend from UCore 2.0 –Act as a mid-layer ontology –Connects UCore 2.0 with COI controlled vocabularies –Using doctrinally sound terminology 107

6 Components of the C2 Domain Force Structure, Integration, Organization Situational Awareness Planning and Analysis Decision Making and Direction Operational Functions and Tasks Monitoring Progress (Assessing) The proposed resource would be based upon these elements using vocabulary derived from Joint Doctrine

Three Levels of Reality 1. Entities and events which we can observe or describe 2. Thoughts about and representations of such entities and events in people’s minds 3. Publically accessible expressions of such thoughts and representations (Examples: ontologies, databases, messages) UCore SL: InformationContentEntity (command, plan) UCore SL: InformationBearingEntity (hard drive, logbook) 109

Three Levels of Reality: C2 Examples Level 1: Events: Operation, Communication Event, Evacuation Event, Campaign, Planning Process Entities: Facility, Geospatial Location, Area of Operations Level 2: Events: Decision Making, Commander’s Visualization Level 3: Entities: Information Content Entity, Objective Specification, Plan 110

Statements about the world: Every C2Operation has_part Some CommunicationEvent Operation Rector has_duration 7 months Valid specifications for data models: Valid C2 Operation Data Structures use duration codes of type XXXX or YYYY Ontologies vs. Data Models

To integrate them we need some common benchmark, that comes as close as possible to the reality (the who, what, when, where) Many valid data models