4882

1. Semantically Rich Experiencesalong the path toOpen Net-Centric InteroperabilityStandards for Training and Testing(ONISTT)Project Sponsored by Deputy Under Secretary of Defense for Readiness (DUSD/R)Briefing to NCOIC/SII Workshop01 August 2006 4882

2. Objective • Share some experiences encountered during the ONISTT project’s efforts to apply concepts & technology from Net-Centric Data Strategy (NCDS), Service Oriented Architecture (SOA), Semantic Web (SW) and Semantic Web Services (SWS) to a specific domain and problem space

3. But first… A diversion about fruit & vegetable salads

4. None of the vendors at the market will sell individual varieties • Only mixed baskets of assorted fruits or vegetables Fruit & Vegetable Salad Analogy • Imagine you had the job of procuring fresh fruits & vegetables for the “daily special” salad at an elegant restaurant • Every day the recipe for the salad changes • So the list of required fruits & vegetables changes daily • You are allowed to examine the items in each basket individually, but must buy the whole basket (even if it contains items that are not on today’s list) • You have a maximum budget for each day’s purchases

5. Solution #1 (Manual Approach) • Go to the market daily with the new list of required items and a scale, pencil, and paper • Catalog the contents of each basket • Perform manual analysis to determine if there exists a combination of baskets such that: • Their collective contents “cover” all the requirements in the list, and • Their aggregate cost does not exceed the budget • If there is no such combination, notify the chef (change the recipe?) • If there are more than one combination satisfying all requirements & constraints, invoke an appropriate “best choice” algorithm

6. Solution #2 (Partially Automated Approach) • Establish standard: • Codes for each fruit & vegetable type • Weighing procedures • Human-readable basket inventory format • Require each vendor to measure & catalog contents of each basket and post (in HTML) on a website, along with cost for each basket • Human retrieves the information from the website and performs steps 3-5 from #1

7. Solution #3 (Fully Automated Approach) • Establish standard: • Ontologies for fruits & vegetables • Including relationships such as “can/can-not substitute for” • Weighing procedures • Ontology for basket inventories • Require each vendor to measure & catalog contents of each basket, express in machine-understandable form (e.g., OWL), and post this metadata in a metadata registry, along with cost of each basket • Software agent accesses the metadata and employs an inference engine to determine if there exists a combination of baskets such that: • Their collective contents “cover” all the requirements in the list, and • Their aggregate cost does not exceed the budget • Same as steps 4 & 5 from #1

8. Not so fast! • The restaurant will not survive long if it bases its choice of fruit & vegies strictly on weight and cost • Other important Quality-related factors: ripeness, freshness, color, … • To make Solution #3 viable, also need: • Ontologies for expressing these quality factors in unambiguous terms • Measurable physical attributes (metrics) that can be translated into Figures-of-Merit to represent these quality-related factors • Example: concentration levels of sugar and malic acid provide primary Figures of Merit to screen for ripeness in some fruit (e.g., grapes) • Standards for measuring those physical attributes • More complex decision algorithm to handle multi-parameter optimization

9. But that’s not all… • The restaurant owner also wants to outsource the Peeling, Slicing, and Dicing (PS&D) of the components of the salad • There are cottage industries specializing in PS&D services • But no single PS&D service provider handles all types of fruit & vegies • Most won’t touch a Durian… • And there are subtle (but important) quality factors involved, such as: • Waste percentage (how much good stuff gets discarded with the peel) • Undesirable content percentage (how much bad stuff gets included in the delivered product) • Automating the selection of PS&D service providers (to match the daily-changing needs) requires a means of describing verb-like things (i.e., services) rather than noun-like things (the fruit) • e.g., OWL-S

10. Now, back to ONISTT

11. Motivation for ONISTT Project • DUSD/R has authority (per DoD Directive 1322.18) to: “Develop policy for and oversee joint architectures and standards for integrating live, virtual, and constructive environments to support training...” • DUSD/R is the single focal point for coordinating US DoD collaborative efforts to develop interoperable training capabilities among the Services and with allies & coalition partners (e.g., NATO) • Does not include sponsoring/funding acquisition of a single homogeneous solution • In order to exercise this authority, DUSD/R needs a coherent policy framework and a means of expressing that policy in clear, unambiguous terms • Including provision for accommodating extended transition period • Cannot immediately replace existing inventory of Live, Virtual, and Constructive (LVC) training systems

12. What does fruit salad have to do with this problem? • Solution #3 to the restaurant’s problem required development of an automated analysis tool and associated metadata infrastructure for both services and objects manipulated by those services • Under the ONISTT project, we are pursuing an approach that leverages NCDS, SOA, SW and SWS concepts to develop an automated analysis tool and associated metadata infrastructure for both services and objects manipulated by those services • Although the application domains are vastly different, the underlying concepts and tools need are substantially the same

13. ONISTT Approach – In Words • Use those concepts & technology to: • Create machine-understandable semantic-rich metadata that describe: • The Services Required to conduct Mission M • The Services Available from each potential constituent of the confederation • Create an Analyzer that can determine if the Services Available from the candidate CF are capable of satisfying the Services Required for a specific enactment of Mission M This approach accommodates the notion that a particular service provider may be adequate for today’s mission but may not be satisfactory for tomorrow’s mission It also provides a way to include legacy systems: characterize their behavior in the same terms as new systems built IAW SOA

14. ONISTT Approach – In Pictures Services Needed Services Available Analyzer

15. Sounds Easy… • As is often the case, the concept is simple – but the devil is in the details! • First messy detail involves identification of the Services Needed (the analog to the daily recipe for the salad) • Not as easy as in the restaurant case

16. Role A Each role may be Implemented by one or more warfighters In the force Service 1 Service 2 Performance of a service is triggered by the receipt of a C2 message Service 3 Review Msg w Msg k Msg w Msg x Role C Role B Send Msg x Service 7 Service 4 Service 8 Service 5 Service 9 Service 6 Each service Is defined as a Task network Msg m Msg r Msg q Role D Role E Each warfighter may implement one or more roles Msg d Information may be shared between services within A role Service 10 Service 11 Service 13 Service 14 Service 12 Service 15 We Are Not Alone: Mission Behavior Modeling Using OWL-S Slide courtesy of DCS Corporation, Alexandria, VA

17. 7. Populate Ontologies to form Scenario KBs 6. Populate Ontologies to form Actor KBs Scenario KBs Actor KBs Role KBs 5. Populate Ontologies to form Role KBs 4. Develop Ontologies for all Referents Upper Domain Common Ontologies Service System Referents TA & JTA Referents 1. Develop Referents for TAs & JTAs Scenario & QoS Referents Systems 2. Develop Referents for System capabilities TAs & JTAs 3. Develop Referents for Scenario constraints & QoS metrics ONISTT Approach – In Pictures

18. 1. Mission planner selects specific mission enactment parameters from menus 2. Analyzer asks “Can Actor X provide services required for Role Q in Scenario P?” If No-go (b) decision is rendered, Mission Planner can modify scenario parameters and request re-evaluation 5. Analyzer notifies mission planner either: (a) Mission can be executed by the confederation, or (b) Mission cannot be executed for the following reasons… Role KBs Scenario KBs Actor KBs ONISTT Approach – In PicturesInvocation Phase 3. Analyzer asks “Can Actor X and Actor Y provide services required for interactions between Role Q and Role R in Scenario P?” 4. Analyzer asks “does the sum of all Actors in the confederation satisfy all the roles in Scenario P?” 7. If Go (a) decision is rendered, Analyzer can supply specification for configuring middleware to provide Mediation Services

19. Canonical Training Services – Initial Candidates

20. Engage Simulated Target:Subtask, Role, and Services

21. Why can’t we just apply SW & SWS Technology “as-is” • SW & SWS technologies provide very powerful tools (OWL & OWL-S) • So why can’t we just “turn the crank” (i.e., follow their use-case examples)? The Good News is: (so far) we have found ways to deal with these issues without breaking through the OWL & OWL-S capability envelopes… Caveat: the pudding is not yet half-baked…

22. ONISTT use cases must deal with SW/SWS Use-Cases focus on “Free-floating” services – software agent can compose a workflow using the optimal choice from each category Most services are bundled together in systems – few cases where execution latency will allow “outsourcing” an inadequate service from one system to another Discovery by the system that needs the service – at the time it needs it (i.e., realtime, on-the-fly) Discovery by an Exercise Analyzer & Configurator – prior to (days, weeks, months) commencement of the exercise Service selection based mainly on functional parameters (e.g., inputs & outputs) – not typically including arbitrary constraints Complex constraints and utility functions A few more differences

23. ONISTT Establish patterns & conventions for building parallel ontology structures to describe (1) services available from a specific system implementation and (2) services needed by a specific exercise enactment Establish patterns & conventions for describing messaging via Interface Ontologies SemanticWeb SemanticWeb Services Establish patterns & conventions for decomposing macro-services into workflows of micro-services or “service fragments” Semantics WWW Web Services Syntax Dynamic Static Evolution Towards ONISTT

24. Isolating Atomic Services • OWL-S provides mechanisms to support “Composition of Services” into a workflow • ONISTT applies that construct in reverse: • Each canonical Training Service is decomposed (“teased-apart”) into Atomic Service • The service decomposition process stops when the point is reached where the service fragment contains a single AIB category (whose performance characteristics can be quantified in a static/gross sense by one or more Figures of Merit) NOTES: (1) This step requires a judgment call by a SME (2) The resulting service fragments often do not fit the usual perception of a “service” BUT WE CAN STILL USE OWL-S TO DESCRIBE THEM!

25. Example: Decomposing “Share TSPI Service” into Motion State Vector Workflow

26. Weapon FlyoutOWL-S Protégé Plugin

27. Weapon FlyoutOWL File

28. tspi: TspiReport timestamp msv time: Timestamp spatial: Spatial3DTuplet Orientation xsd: double Acceleration Velocity spatial: GeocentricPosition position value: meter magnitude isa x individual value: Length measurand spatial: Position measure: LengthMeasurement units value: LengthUnit srf uncertainty srf: SpatialReferenceFrame uncertainty: UncertaintyValue value measure: uncertainty orm type uncertainty: UncertaintyEstimateType orm: objectReferenceModel acs distribution isa acs: AbstractCoordinatesSystem acs: AbstractCoordinatesSystem uncertainty: UncertaintyDistributionType isa individual srf: Celestiocentric orm: OblateEllipsoidCenterORM uncertainty: SphericalErrorProbable individual individual uncertainty: Gaussian individual acs: Eclidean3D acs srf: GeocentricWGS1984 Class Object or datatype property individual Individual orm Subclass of orm: WGS1984 Primitive datatype Individual of Visualization of Partial TSPI Ontology