2

Knowledge Modelling forService-oriented Applicationsin the e-Government Domain

Alessio GugliottaKnowledge Media Institute, The Open University

2006 AAAI Spring Symposium SeriesStanford University, California, USA, March 27-29,

2006

3

Background

• Research Fellow at KMi, the Open University, Milton Keynes (UK)– DIP Project http://dip.semanticweb.org

• Approaches, Tools, Applications of SWSs

– WP9: e-Government applications based on SWS

• PhD Student at the University of Udine– “Knowledge Modelling for Service-oriented

Applications in the e-Government Domain”

• SOA, Ontologies, SWS (WSMO) and e-Government

4

Purpose

• Semantically-based framework with which most PAs identify; from which to design and deliver e-Gov services

• Application of KM techniques within service-oriented systems in order to supply add-value e-Government services.

5

Presentation Outline

• Scenario Overview• Technologies• Problem Statement• Objectives and Goal• Approach• Results• Case study• Future Work

6

IntegrationInteroperability

WEB

Scenario Overview

ServicesContexts

Vocabularies

Ontologies

7

Technologies

8

Ontology Definition

formal, explicit specification of a shared conceptualization

commonly accepted understanding

conceptual model of a domain

(ontological theory)

unambiguous definition of concepts, attributes

and relationships

machine-readability

Complete Coherent Supporting use, reuse and interoperability

9

What’s a Web Service?

• A program accessible over standard Internet protocols

• Loosely coupled, reusable components

• Encapsulate discrete functionalities

• Distributed

• Add a level of functionality on top of the current Web

10

Problems with Web Services Today

• Descriptions are syntactic

• Application development must be carried out by humans:– discovery, composition and invocation

• Problems of scalability

11

Semantic Web Services

• Semantic Web Technology– Machine readable data– Ontological basis

Applied to:

• Web Services Technology– Reusable computational resources

Automating all aspects of application development through reuse

• Combine flexibility, reusability, and universal access of WSs with the power of semantic markup and reasoning

12

SWS Vision

Web(URI, HTML, HTTP)

Web Services(UDDI, WSDL, SOAP)

Semantic Web(RDF, OWL)

Semantic Web Services

Dynamic

Static

Syntax Semantics

13

DIP case study: Emergency Management System

ViewEssexServices

BuddySpace Server

BuddySpace Services

Google Maps APIAJAX

AccommodationGoalEnvironment Goal

Presence Goal

ArchetypesArchetypes

SGIS-SpatialSGIS-Spatial

Em

ergency-GIS

-Dom

ainE

mergency-G

IS-D

omain

Em

ergency-GIS

-Goals

Em

ergency-GIS

-Goals

BuddySpace GoalsBuddySpace Goals

EnvironmentServices

Smart FilterServices

WSMO

14

Problem Statement

15

Problem Statement (1)

• SWSs: a promising infrastructure for next generation e-Government services– Addressing integration and interoperability

• However, integrating e-Government applications and SWSs is a hard task

• E-Government requirements– The PA worker (domain expert) does not use the SWS

infrastructure for representing knowledge internally– PA routines involve interactions with non-software agents:

citizens, PAs, managers, politicians, etc. • Multiple viewpoints need to be considered• Services are not atomic; may require an interaction protocol

– WS description is an important but restricted aspect

16

Problem Statement (2)

• A more complex semantic layer to be modelled

• A technological framework to fit a distributed organization of knowledge

• Two dimensions:– Knowledge Modelling

• Ontologies for describing concepts and services• knowledge retention and creation

– Creating the infrastructure for semantic interoperability

• knowledge use and transfer

17

Objectives and Goal

18

Objectives

• General Purpose– Reusable, extensible, and flexible model

• Multi-Viewpoints

• Contextualization– Describing a context– Distinguishing descriptive entities (independent

views) and actual objects they act upon (concept of the actor’s vocabulary)

• Business Process description – Distinguishing Plans and Interactions

19

Goal

• Modelling a generice-Government service-supply scenario– 3 Knowledge Levels (distinct functionalities)

Guidelines

Configuration

Service Delivery

Vocabularies

Context

SWS

OntologicalFramework

20

Approach

21

Meta-Modelling andModularization

e-Government Domain

abstraction

Specific Scenario

Model of the Specific Scenario

Meta-Modelling•Expressing modelling process•Mapped into Meta-Ontologies

Meta-Model

Conceptual Models

Modularization•Smaller, well-defined components•Including and defining new modules

Methodology• Cooperative development

22

Conceptualization

• Government Service Supply Conceptual Model– describing the main concepts, actors, and existing relations:

Citizen, PA, Agencies, Need, Service, Legislation, Policy…

• System Conceptual Model– roles and processes for the design, development, delivery of

services: Politician, Manager, Domain Experts, Develepers, User

• Life Event Metaphor Conceptual Model– describing the life event as the point of contact among all the

actor’s viewpoints

• Business Process– Plan Conceptual Model– Interaction Conceptual Model

• Interactions between users and providers• Mapping the Two-way interaction and Full Transaction levels of on line

services sophistication

23

Reference Ontologies for Meta-Modelling

• DOLCE [Oltremari et al. 2002]– Upper ontology for domain-dependent concepts

(vocabularies)

• Description & Situation [Gangemi et al. 2001]– Module of DOLCE– For knowledge contextualization

• WSMO [WSMO working group 2004]– For SWSs– Ontological Role Separation: ontologies, goals, WS, mediator – Strict Decoupling – Centrality of Mediation

24

Results

25

Ontological Framework

Goal WSMediator

Life Event Life EventDescription

UserDescription

ProviderDescription

MangerDescription

PoliticianDescription

UserDescription

User LEDescription

ProviderDescriptionProvider LEDescription

MangerDescriptionManger LEDescription

PoliticianDescription

Politician LEDescription

State of AffairDescription

ConceptionDescription

PlanDescription

InteractionDescription

satisfies uses

Is-a Is-a Is-a Is-a

Generic Level

Other OntologiesOther OntologiesOther Ontologies

…

Specific Level

Core Life Event Ontology (CLEO)

Service Ontology

Domain Ontology

Knowledge useful at runtimeSolving mismatch problems

Actor’s autonomy:•Viewpoint/Context•Vocabulary

26

Life Event

NeedDescription

OfferDescription

LegislationDescription

PolicyDescription

InteractionDesciption

TransitionsTransitionsTransitionEvent

TransitionsTransitionsState of AffairDescription

TransitionsTransitionsState of AffairDescription

PlanDescription

TransitionsTransitionsGoalDescription

TransitionsTransitionsServiceDescription

PlanDescription

TransitionsTransitionsState of AffairDescription

TransitionsTransitionsState of AffairDescription

PlanDescription

TransitionsTransitionsStrategyDescription

User

Politician

Manager

Provider

Co

nfig

uration

Gu

idelin

es

NeedDescription

ServiceDescriptionResource Condition

Service Ontology

DomainOntology

Core Life Event Ontology

27

Knowledge Capture Methodology

1. Life event and Actor Analysis2. Viewpoint Analysis

I. State of AffairsII. Interaction III. ConceptionIV. Plans

3. Model-specific Scenario4. Create SWS descriptions

28

Case Study

29

Change of Circumstances

• DIP case studies• Prototype is a portal for Essex County Council in UK, where

two governmental agencies were involved: – Community Care (Social Services) in Essex County Council -

coordinating role in relation to a range of services such as support for elderly and disabled people (day centers, transportation). It uses the SWIFT database as its main records management tool.

– The Housing Department of Chelmsford District Council - handles housing services and uses the ELMS database

• End User: A case worker of the Community Care department helps a citizen to report his/her change of circumstance (e.g. address) to different agencies. The government agency automatically notifies all the agencies involved.

• The case worker opens a case for a citizen who is eligible to receive services and benefits – health, housing, etc. Multiple service providing agencies need to be informed and interact.

30

Life Event and Actor Analysis

• Scenario segmented along two orthogonal dimensions:– Life events:

• Patient moves House• Patient passes away

– Actor viewpoints: • Community Care• Housing Department• Case Worker

• Devised 3 teams for Viewpoint Analysis– Cooperative development

31

State of Affair Analysis (1)

• Representing one or more “pictures” of the life event situation: initial, final, specific cases, etc.

• Identifying main concepts and relations: actors, resources, attributes and functional and non functional parameters

32

State of Affair Analysis (2)

(def-class state-of-affair-description (egov-description) ?soa((uses-role :min-cardinality 1 :type cleo-role) (uses-attribute :min-cardinality 0 :type cleo-attribute) (uses-parameter :min-cardinality 0 :type cleo-parameter) (expressed-by :type constraint-expression :min-cardinality 1)))

Patient

Case WorkerCommunityCare Dept.

New Address

Current AddressMoving Date

Patient Info

speaks

specifies

relates

supplies

specializes

requires

(def-class Current-Address (cleo-attribute) ?ca((played-by :type address)))

(def-class New-Address (Information) ?ca((played-by :type address)))

Domain Ontology

Meta-Model

Descriptive Entities(def-class case-worker-PMH-change-address-initial-SOA (service-request) ?soa((uses-role :cardinality 5) (uses-attribute :cardinality 1) (uses-parameter :cardinality 1) (expressed-by :value (and (patient ?p) (patient-case-worker ?cw) (community-care-department ?ccd) (current-address ?ca) (patient-information ?pi) (new-address ?na) (moving-date ?md) (speaks ?p ?cw) (cleo-relates ?cw ?ccd) (cleo-supplies ?p ?na) (cleo-specifies ?p ?md) (cleo-specializes ?ca ?p) (cleo-requires ?cw ?pi)))):constraint #omitted#)

33

InteractionAnalysis (1)

• Describing – dynamic between 2 viewpoints

(user-provider or provider-provider)– knowledge crossing 2 viewpoints

(exchanged values)• Distinguishing

– Communication (two way: notification, enquiry)– Transaction (full transaction)

• Transition Event– Conditions on the state, time, agents– Resource Exchanged – State and Resource define descriptive entities with 2

counterparts• Axioms on the descriptive entities allow to early

discover shortcomings in the state of affair definitions– E.g. state defines a concept that is not described in the

state of affair

34

InteractionAnalysis (2)

35

Conception Analysis (1)

• Describing what an actor may conceive in a particular state of affair

• Defining– Need/goals decomposition– Offer/services decomposition

• Considering complex services– Decomposed in terms of

• Service description (composition)• Need description (delegation)

36

ConceptionAnalysis (2)

Retrieve-list-equipments-need (Delegated to Housing Dpt)•Find-items-matching-weight-goal•Find-items-matching-impairment-goal•List-intersection-goal

Case Worker Housing Department

37

Plan Analysis (1)

• Describing dynamics within a Viewpoint• Organizing

– Goals/Services within Need/Offer– Need/Offer within a Life Event Description

• Defining Tasks (descriptive entities)– Representing Goal, Services, Need, Offer,

and workflow control structures

38

Plan Analysis (2)

Workflow retrieve-list-equipments-need1. Any-order-task2. Finds-item-matching-weight-goal-task3. Finds-item-matching-impairment-goal-task4. Sync-task5. List-intersection-goal-task

(def-class retrieve-list-equipments-need-plan (goals-plan-description) ?pd((uses-task :cardinality 5)):constraint (exists (?a ?t1 ?t2 ?s ?t3) (and (uses-task ?pd ?a) (retrieve-list-equipments-any-order-task ?a) (uses-task ?pd ?t1) (finds-items-matching-weight-goal-t ?t1) (uses-task ?pd ?a) (finds-items-matching-impairment-goal-t ?t2) (uses-task ?pd ?s) (retrieve-list-equipments-syncro-task ?s) (uses-task ?pd ?a) (list-intersection-goal-t ?t3) (successor ?a ?s) (direct-successor ?a ?t1) (direct-successor ?a ?t2) (direct-predecessor ?s ?t1) (direct-predecessor ?s ?t2) (direct-successor ?s ?t3))))

39

SWS Descriptions (1)

• Traducing the knowledge captured so far intoWSMO descriptions – Descriptive entities (context)– Concepts from the Domain Ontology (vocabulary)

• WSMO Goal– Axiomatization allows to obtain possible:

• Inputs, Outputs • Capability (pre-post conditions, assumptions, effects)

• WSMO web services– Axiomatization allows to suggest:

• Choreography (guarded transitions)• Orchestration

• WSMO mediators– Linking the previous elements– Solving mismatch problems

40

SWS Descriptions (2)

41

Future Work

• Developing the Guideline Knowledge Level

• Infrastructure/Framework for semantic interoperability– Existing components: IRS-III

• New Applications

42

Thanks

Acknowledgements:• Prof. Vito Roberto, University of Udine • The Semantic Web Services group at KMi: John Domingue, Liliana Cabral, Stefania Galizia, Barry Norton, and Vlad Tanasescu

a.gugliotta@open.ac.uk