Ontologies for the Semantic Web Services and Events

Ontologies for the Semantic Web: Services and Events Jerry R. Hobbs USC/ISI Marina del Rey, CA

Outline 1. Services: DAML-S (OWL-S) 2. An Event Ontology for video data 2. Time: DAML-Time 3. Plans for a Space Ontology 3. Ideas toward an Ontology of Information 4. Structure 5. Progress toward an Ontology of Commonsense 6. Psychology

DAML-S Acknowledgements Many slides stolen from David Martin, A few slides stolen from Terry Payne and Dieter Fensel

Motivating Tasks Automatic Web service discovery Find an airline site that accepts Diners Club Automatic Web service invocation Buy coach class United flight 347 for Sept 15 Automatic Web service composition Find the cheapest flight LAX to some Washington airport Sept 15 or 16 and buy a ticket; Rent a compact car for when I arrive; Reserve a room at the Arlington Hyatt. Automatic Web service “decomposition” Use Amazon. com to find reference Automatic Web service execution monitoring Has my credit card been charged yet? Has the ticket been mailed yet?

Why Semantic Web Services? Dynamic Static Web Services UDDI, WSDL, SOAP WWW URI, HTML, HTTP Shallow Intelligent Web Services Semantic Web RDF, RDF(S), OWL Deep Thanks to Dieter Fensel (U. of Innsbruck) for use of this material Bringing the web to its full potential

DAML-S Web Services Coalition BBN: Mark Burstein CMU: Katia Sycara, Massimo Paolucci* ICSI: Srini Narayanan Maryland / College Park: Bijan Parsia Nokia: Ora Lassila Stanford KSL: Sheila Mc. Ilraith* SRI: David Martin* Southampton: Terry Payne* USC-ISI: Jerry Hobbs Yale: Drew Mc. Dermott *Contributor to these slides

What is OWL-S? • Ontology Web Language for Services • An OWL ontology/language for (formally) describing properties and capabilities of Web services • An approach that draws on many sources • Description logic • AI planning • Workflow • Formal process modeling • Agents • Web services http: //www. daml. org/services/

Layered Approach to Language Development OWL-S: a major application of OWL Future versions will build upon emerging layers (e. g. DAML-Rules) OWL-S (Services) DAML-? ? ? (Rules, FOL? ) DAML+OIL OWL (Ontology) RDFS (RDF Schema) RDF (Resource Description Framework) XML (Extensible Markup Language)

OWL-S Objectives Automation of service use by software agents • Ideal: full-fledged use of services never before encountered: Discovery, selection, composition, invocation, monitoring, . . Useful in the “real world” Compatible with industry standards Incremental exploitation Enable reasoning/planning about services e. g. , On-the-fly composition Integrated use with information resources Ease of use; powerful tools

Upper Ontology of Services Ontology images compliments of Terry Payne, University of Southampton

Service Profile: “What does it do? ” High-level characterization/summary of a service Used for • Populating service registries • A service can have many profiles • Automated service discovery • Service selection (matchmaking) • One can derive: • Service advertisements • Service requests

Service Profile Non Functional Properties Functionality Description

Service Profile: Functionality Description • Functional Specification of what the service provides in terms of parameters, subclassed as: – preconditions – inputs – outputs – effects • Summarizes the top-level Process

Service Profile: Non. Functional Properties • Provides supporting information about the service.

Service Profile: Non. Functional Properties • These include – – – service. Name text. Description quality. Rating service. Parameter service. Category contact. Information

Service Profile: Non. Functional Properties - Actor

Service Profile: Styles of use • Class-hierarchical yellow pages – – Implicit capability characterization Arrangement of attributes on class hierarchy Can use multiple inheritance Relies primarily on “non-functional” properties • Process summaries for planning purposes – – – More explicit Inputs, outputs, preconditions, effects Less reliance on formal hierarchical organization Summarizes process model specs Relies primarily on functional description

Exploiting Profile Hierarchies Tie in with UDDI, UNSPSC, … DL Basis for matchmaking Multiple profiles; multiple taxonomies

Upper Ontology of Services

Service Model it work? ” Process Model: “How does it work? ” Process – Interpretable description of service provider’s behavior – Tells service user how and when to interact (read/write messages) & Process control – Ontology of process state; supports status queries – (stubbed out at present) • Used for: – Service invocation, planning/(de)composition, interoperation, monitoring • All processes have – Inputs, outputs, preconditions and effects – Function/dataflow metaphor; action/process metaphor • Composite processes – Control flow – Data flow

Service Model / Process Model

Function/Dataflow Metaphor Input: • customer name • origin • destination • weight • pickup date • . . . Output: • confirmation no. • . . . Acme Book Truck Shipment truck available + ? valid credit card Y N • failure notification • …

AI-inspired Action/Process Metaphor Output: • confirmation no. • . . . Effect: • goods at location if successful • credit card debited. . . Input: • customer name • origin • destination • pickup date • . . . Preconditions: • knowledge of the input • . . . Acme Book Truck Shipment truck available + ? valid credit card Output: Effect: Y N • failure notification • … <no effect>

Composite Process Input & Preconditions • • • Output & Effects Acme. Truck. Shpng • • • confirmation no. • . . . • • • customer name • location • car type • dates • credit card no. • . . . www. acmecar. com ? book car service • failure notification • … • confirmation no. • . . . • customer name • flight numbers • dates • credit card no. • • . . . www. acmeair. com book flight service ? • confirmation no. • dates • room type • credit card no. • . . . www. acmehotel. com book hotel service ? • failure notification • … • failure notification • errror information • … ? • •

Atomic Process Example <!– Atomic Process Definition - Get. Desired. Flight. Details --> <rdfs: Class rdf: ID="Get. Desired. Flight. Details"> <rdfs: sub. Class. Of rdf: resource="http: //www. daml. org/Process#Atomic. Process" /> </rdfs: Class> <!– (sample) Inputs used by atomic process Get. Desired. Flight. Details --> <rdf: Property rdf: ID="departure. Airport_In"> <rdfs: sub. Property. Of rdf: resource="http: //www. daml. org/Process#input" /> <rdfs: domain rdf: resource="#Get. Desired. Flight. Details" /> <rdfs: range rdf: resource="http: //www. daml. ri. cmu. edu/ont/ DAML-S/concepts. daml#Airport" /> </rdf: Property> <rdf: Property rdf: ID="outbound. Date_In"> <rdfs: sub. Property. Of rdf: resource="http: //www. daml. org/Process#input" /> <rdfs: domain rdf: resource="#Get. Desired. Flight. Details" /> <rdfs: range rdf: resource="http: //www. daml. ri. cmu. edu/ont/ DAML-S/concepts. daml#Flight. Date" /> </rdf: Property> Airport Flight Date departure. Airport_In Get. Desired Flight Details outbound. Date_In

Composite Process Example <rdfs: Class rdf: ID="Book. Flight"> <rdfs: sub. Class. Of rdf: resource="#Composite. Process" /> <rdfs: sub. Class. Of rdf: resource="http: //www. daml. org/Process#Sequence" /> <daml: sub. Class. Of> <daml: Restriction> <daml: on. Property rdf: resource="http: //www. daml. org/Process#components" /> <daml: to. Class> <daml: sub. Class. Of> <daml: union. Of rdf: parse. Type="daml: collection"> <rdfs: Class rdfs: about="#Get. Flight. Details" /> <rdfs: Class rdfs: about="#Get. Contact. Details" /> <rdfs: Class rdfs: about="#Reserve. Flight" /> <rdfs: Class rdfs: about="#Confirm. Reservation" /> </daml: union. Of> Composite Process </daml: sub. Class. Of> </daml: to. Class> Book. Flight </daml: Restriction> </daml: sub. Class. Of> </rdfs: Class> Get Flight Details Get Contact Details Sequence Reserve Flight Sequence Confirm Reservation

Simple and Composite Processes Acme. Truck. Shpng Expanded. Acme. Truck. Shpng Confirm Shipping Region N Acme Truck Shipping expands truck available + valid credit card Y Get Quote Service Get Shipping Dates Book Truck Shipment

Upper Ontology of Services

Service Grounding: “How to access it” • Implementation-specific • Message formatting, transport mechanisms, protocols, serializations of types • Service Model + Grounding give everything needed for using the service • Builds upon WSDL

OWL-S / WSDL Grounding • Web Services Description Language – Authored by IBM, Ariba, Microsoft – Focus of W 3 C Web Services Description WG – Commercial momentum – Specifies message syntax accepted/generated by communication ports – Bindings to popular message/transport standards (SOAP, HTTP, MIME) – Abstract “types”; extensibility elements • Complementary with OWL-S

OWL-S / WSDL Grounding OWL-S Process Model Atomic Process Resources/Concepts Inputs / Outputs Message Operation Binding to SOAP, HTTP, etc. WSDL

OWL-S / WSDL Grounding (cont’d)

OWL-S / WSDL Grounding (cont’d) WSDL Document input. X output. Y daml-property owl-s-process Atomic Process <message …> <part …> <operation …> <binding …>

Review: Upper Ontology of Services

Path of Evolution DAML Coalition formed (February 2001) Release 0. 5 (May 2001) Initial Profile & Process ontologies Release 0. 6 (December 2001) Refinements to Profile & Process; Resources ontology Release 0. 7 (October 2002) Initial DAML-S/WSDL Grounding; Profile, Process Model refinements; more complete examples Release 0. 9 (May 2003) DAML-S OWL-S Grounding: greater generality, flexibility Initial work on expressing conditions, security More community support (contributions pages) Towards 1. 0 Expressiveness issues; exceptions, lifecycle; process issues

Event Ontology for Video Data (work with Ram Nevatia, USC) Some concepts Single-thread composite events Multi-thread composite events Granularity and primitive events The functionality of events An ontology of mobile objects

Motivation In a convenience store surveillance videotape, how do you tell the difference between a legitimate purchase a holdup shoplifting A language of describing the structure of event in video data for recognition and retrieval

Role of Ontology Abstract Theory Fixes meaning of terms in common vocabulary Common Vocabulary Application 1 Application 2 Mark-Up Language

How to Build an Ontology What types of objects are there? What are their attributes or properties? What relations can obtain between various types of objects? What possible changes are there in properties and relations? = Events

Reification of Events p(x) The state or event of p being true of or happening to x Various notation devices possible. If events are your main topic, your logic should have variables that can refer to them.

Some Terminology Properties, Attributes, Relationships An event is a change of state (e. g. , location). change(p(x), q(x)), change(at(x, y), at(x, z)) An agent, state or event can cause a state or event. [change(p 1(x), q 1(x))] -cause-> [change(p 2(y), q 2(y))] An agent is an entity that can initiate a causal chain. a -cause-> [change(p(x), q(x))] An action is an event with an agent. a -cause-> [change(p(x), q(x))] Agent Instrument John -cause-> change(at(H, A), at(H, W)) -cause-> change(intact(W), broken(W)) Theme/Object

Some Terminology A process is a complex of tightly coupled events. e 1 e 2 e 3 e 4 e 5 An activity is a set of loosely coupled events and/or processes. {[change(p(x), q(x))], . . } An event is a limiting case of a process; a process is an event at a finer granularity.

Single-Thread Event Composition for Single Agents/Objects Sequence: open door; go thru; . . . Iteration: walking: {move left leg; move right leg}* Alternation: take part; [toss into bin A | toss into bin B] Conditionals: take part; square? ==> toss into bin A round? ==> toss into bin B Hierarchical Composition Interruption and Resumption Similar to DAML-S Process Model

Multi-thread Events Each agent/objects executes its single-thread process. Sometimes agents/objects interact (physically). Some agents can observe other agents’/objects’ actions and events, and modify their behavior accordingly. Some agents can perform actions in order to be observed: communication. . .

Multi-thread Events: Example Blender: Cook: Pot on Burner: off & empty off & filled turns on burner off fills blender on on blending turns on blender increasing temperature boiling

Temporal Constraints Many processes have temporal constraints among component events. Topological relations: begin, inside, end, before, interval relations. part appears on conveyor belt; pick it up Duration: rhythm -- two agents keep iterations at same duration Clock and calendar: process begins at 9: 00 am DAML-Time Ontology for relating events and describing their temporal properties

Granularity Coarse-grained view: PERSON CROWD Fine-grained view: person 1 head arm torso person 4 person 3 person 6 leg person 2 person 5

Granularity COARSE: Complex object as single entity. FINE: Complex object as multiple independent, coordinated agents.

Granularity COARSE: Complex object as single entity. INTERMEDIATE: Complex object as single entity with parts FINE: Complex object as multiple independent, coordinated agents.

Primitive Actions Granularity-dependent, domain-dependent. Some primitive actions in visual applications: Cars: move w speed in direction, change People in indoor/outdoor surveillance: tens, not hundreds walk, look at objects, pick up and carry objects, hand objects to other persons, . . . People in meetings: Gaze direction, body position, Hand gestures: deictic, iconic, “metaphorical”, . . .

The Functionality of Events Structure: How events decompose into subevents. Function: How events, undecomposed, relate to their environment. Communication Physical Intentional drinking cup of coffee Nonintentional fall off chair Physical: personal pick something up utterance yawn? interpersonal hand it to someone Communication: medium: spoken in person, phone, whiteboard, . . . audience: one’s self, one other, whole group, . . .

A Simple Ontology of Mobile Objects Change +. . Mobile. Object: velocity, direction Mobile. Object-Object: distance-from, near Container: portal (open/closed) Mobile. Object-Container: in/out Mobile. Object-Portable. Object: hold Mobile. Object-Mobile. Object: relations are all derived from above Derived notions: start, speed-up, turn, approach, enter, exit, pick-up, carry, transfer, exchange

Example: Tailgating Field of vision has regions that are restricted, unrestricted Persons (Mobile. Object): entry to restricted area can be authorized/unauthorized Tailgate: Person 1 moves thru portal into restricted area without authorization by staying near Person 2 who causes portal to be open by establishing authorization Functional inference: intrusion

Summary Ontology of events, processes, and services is useful in Semantic Web for recognition/discovery/analysis retrieval composition of novel processes decomposition into parts