2 Knowledge Modelling for Service-oriented Applications in the e-Government Domain Alessio Gugliotta Knowledge Media Institute, The Open University 2006 AAAI Spring Symposium Series Stanford University, California, USA, March 27-29, 2006

3 Background Research Fellow at KMi, the Open University, Milton Keynes (UK) –DIP Project 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 Integration Interoperability WEB Scenario Overview Services Contexts 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 CompleteCoherentSupporting 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 ViewEssex Services BuddySpace Server BuddySpace Services Google Maps API AJAX Accommodation Goal Environment Goal Presence Goal Archetypes SGIS-Spatial Emergency-GIS-Domain Emergency-GIS-Goals BuddySpace Goals Environment Services Smart Filter Services 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 generic e-Government service-supply scenario –3 Knowledge Levels (distinct functionalities) Guidelines Configuration Service Delivery Vocabularies Context SWS Ontological Framework

20 Approach

21 Meta-Modelling and Modularization 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 GoalWSMediator Life Event Description User Description Provider Description Manger Description Politician Description User Description User LE Description Provider Description Provider LE Description Manger Description Manger LE Description Politician Description Politician LE Description State of Affair Description Conception Description Plan Description Interaction Description satisfies uses Is-a Generic Level Other Ontologies … Specific Level Core Life Event Ontology (CLEO) Service Ontology Domain Ontology Knowledge useful at runtime Solving mismatch problems Actor’s autonomy: Viewpoint/Context Vocabulary

26 Life Event Need Description Offer Description Legislation Description Policy Description Interaction Desciption Transitions Transition Event Transitions State of Affair Description Transitions State of Affair Description Plan Description Transitions Goal Description Transitions Service Description Plan Description Transitions State of Affair Description Transitions State of Affair Description Plan Description Transitions Strategy Description User Politician Manager Provider Configuration Guidelines Need Description Service Description ResourceCondition Service Ontology Domain Ontology Core Life Event Ontology

27 Knowledge Capture Methodology 1.Life event and Actor Analysis 2.Viewpoint Analysis I.State of Affairs II.Interaction III.Conception IV.Plans 3.Model-specific Scenario 4.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 Worker Community Care Dept. New Address Current Address Moving 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 Interaction Analysis (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 Interaction Analysis (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 Conception Analysis (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-need 1.Any-order-task 2.Finds-item-matching-weight-goal-task 3.Finds-item-matching-impairment-goal-task 4.Sync-task 5.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 into WSMO 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