ucore sl training event march 17, 2010 presenters barry smith, 716-650-0075, [email protected]...

UCore SL Training EventMarch 17, 2010

Presenters Barry Smith, 716-650-0075 , [email protected]

Lowell Vizenor, 410-982-8140, [email protected] National Center for Ontological Research (NCOR)

http://ncor.buffalo.edu/

Sponsor James Schoening, 732-532-6820, [email protected]

Army Net-Centric Data Strategy Center or Excellence in Support of Army CIO/G-6

http://architecture.army.mil/data.html https://wiki.kc.us.army.mil/wiki/UCore-SL_Implementation_Guidance

http://architecture.army.mil/data.html

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 reasoning6

• 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 maintainThe 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 GOexperimental results reported in 52,000 scientific journal articles manually annoted by expert biologists using GOontologies provide the basis for capturing biological theories in computable formallows 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

CONTINUANT OCCURRENT

INDEPENDENT DEPENDENT

ORGAN ANDORGANISM

Organism(NCBI

Taxonomy)

Anatomical Entity(FMA, CARO)

OrganFunction

(FMP, CPRO) Phenotypic

Quality(PaTO)

Biological Process

(GO)CELL AND CELLULAR

COMPONENT

Cell(CL)

Cellular Compone

nt(FMA, GO)

Cellular Function

(GO)

MOLECULEMolecule

(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

http://obofoundry.org

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

AnatomicEntity

OrganFunction Phenoty

peBiological Process

CellCellPart

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):http://www.ifomis.org/bfo/home

• shared Relation Ontology: www.obofoundry.org/ro

Common governance (coordinating editors)

Common training25

OBO Foundry Principles

Common governance (coordinating editors)

Common training

Common architecture

• simple top level (Basic Formal Ontology):http://www.ifomis.org/bfo/homehttps://wiki.kc.us.army.mil/wiki/ISO_Standard_Upper_Ontology

• shared Relation Ontology: www.obofoundry.org/ro

26

> 50 ontology initiatives using BFOExamplesNanoparticle Ontology (NPO)ChemAxiom – Ontology for ChemistryCleveland Clinic Semantic Database in Cardiothoracic SurgeryNational Cancer Institute Biomedical Grid Terminology

(BiomedGT)Neural Electromagnetic Ontologies (NEMO)EU Ontology for Risks Against Patient SafetyInformation Artifact Ontology (IAO)

http://www.ifomis.org/bfo/users

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

http://pistoiaalliance.org/

29

Basic Formal Ontology

Continuant Occurrent

process, eventIndependentContinuant

entity

DependentContinuant

property

30



ORGAN ANDORGANISM

Organism(NCBI

Taxonomy)

Anatomical Entity

(FMA, CARO)

OrganFunction


Quality(PaTO)

Organism-Level Process

(GO)

CELL AND CELLULAR

COMPONENT

Cell(CL)

Cellular Compone

nt(FMA, GO)

Cellular Function

(GO)

Cellular Process

(GO)

MOLECULEMolecule

(ChEBI, SO,RNAO, PRO)


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)

CellularComponentOntology

(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 2.0

33

• 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

34

1. “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, ...

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

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 ThingEntity

PhysicalEntityInformationContentEntityProperty

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

Blinding Flash of the Obvious



entity

DependentContinuant

property

45



ORGAN ANDORGANISM

Organism(NCBI

Taxonomy)

Anatomical Entity

(FMA, CARO)

OrganFunction


Quality(PaTO)

Organism-Level Process

(GO)

CELL AND CELLULAR

COMPONENT

Cell(CL)

Cellular Compone

nt(FMA, GO)

Cellular Function

(GO)

Cellular Process

(GO)

MOLECULEMolecule

(ChEBI, SO,RNAO, PRO)


Molecular Process

(GO)

rationale of OBO Foundry coverage

GRANULARITY

RELATION TO TIME

46

> 50 ontology initiatives using BFO

ExamplesNanoparticle 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)

http://www.ifomis.org/bfo/users

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 extensionsBut 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 exampleMary has_part brain

human being has_part brainMary has_part uterus

Not human being has_part uterus

61

The All-Some Rule

Ontology terms are always on the level of typesFor 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 exampleMary has_part uterus

Not human being has_part uterus

63

TBDU MethodologyIf 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 2010

64

How to create an ontology from the top down

Continuant Occurrent(Process, Event)

IndependentContinuant

DependentContinuant

65

Example: The Cell Ontology

Library (defined by metadata registry)

67

Foundry (defined by commitment to collaboration)

68

Organism

AnatomicEntity

OrganFunction Phenoty

peBiological Process

CellCellPart

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

CellularComponentOntology

(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



entity

DependentContinuant

property

property dependson bearer

77

depends_on



entity

DependentContinuant

property event dependson participant

78

instance_of



event

DependentContinuant

property

.... ..... .......

types

instances 79

Continuant


DependentContinuant

..... .....

Non-realizableDependentContinuant(quality, e.g. mass)

Realizable DependentContinuant(role)

80

depends_on


process


entity

DependentContinuant

quality

.... ..... .......temperature dependson bearer

81

realization depends_on realizable



entity

DependentContinuant

role

.... ..... .......Process of realization

82

Continuant


Specifically DependentContinuant

..... .....Quality

Realizable DependentContinuant(function, role, disposition)

83

Roles as Properties in UCore SL

OWL ThingEntity

PhysicalEntity

InformationContentEntity

Property

RoleEvent

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:

<ucore:Entity id="PersonnelCarrier1“> <ucore:What ucore:code="GroundVehicle"

ucore:codespace="http://ucore.gov/ucore/2.0/codespace/"/> <ucore:What

ucore:code="Cargo"ucore:codespace="http://ucore.gov/ucore/2.0/codespace/"/></ucore:Entity>

Roles

Roles

• And similarly in the case of an intelligence report that includes the information that a person was the source of certain information:

<ucore:Entity id="Person1">

<ucore:What ucore:code="Person" ucore:codespace="http://ucore.gov/ucore/2.0/codespace/"/>

<ucore:What ucore:code="InformationSource"ucore:codespace="http://ucore.gov/ucore/2.0/codespace/"/>

</ucore:Entity>

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 2.0

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

102Clay 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 CoreIntroductory 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 3-13.1 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 DomainForce Structure, Integration, OrganizationSituational AwarenessPlanning and AnalysisDecision Making and DirectionOperational Functions and TasksMonitoring 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

ucore sl training event march 17, 2010 presenters barry smith, 716-650-0075, [email protected]...

Documents