1 / 43

Knowledge Modelling for Service-oriented Applications in the e-Government Domain

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

mcdonough
Download Presentation

Knowledge Modelling for Service-oriented Applications in the e-Government Domain

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Knowledge Modelling forService-oriented Applicationsin 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

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

  3. Purpose • Application of KM techniques within service-orientedsystems in order to supply add-value e-Government services. • Semantically-based framework with which most PAs identify; from which to design and deliver e-Gov services

  4. Presentation Outline • Scenario Overview • Technologies • Problem Statement • Objectives and Goal • Approach • Results • Case study • Future Work

  5. Integration Interoperability WEB Ontologies Vocabularies Services Contexts Scenario Overview

  6. Technologies

  7. conceptual model of a domain (ontological theory) unambiguous definition of concepts, attributes and relationships commonly accepted understanding machine-readability Ontology Definition formal, explicit specification of a shared conceptualization Complete Coherent Supporting use, reuse and interoperability

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

  9. Problems with Web Services Today • Descriptions are syntactic • Application development must be carried out by humans: • discovery, composition and invocation • Problems of scalability

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

  11. SWS Vision Web Services (UDDI, WSDL, SOAP) Semantic Web Services Dynamic Semantic Web (RDF, OWL) Web (URI, HTML, HTTP) Static Semantics Syntax

  12. Environment Services ViewEssex Services DIP case study: Emergency Management System Archetypes Presence Goal Emergency-GIS-Goals SGIS-Spatial Emergency-GIS-Domain Accommodation Goal Environment Goal Smart Filter Services WSMO Google Maps API AJAX BuddySpace Services BuddySpace Server BuddySpace Goals

  13. Problem Statement

  14. Problem Statement (1) • SWSs: a promising infrastructure for next generation e-Government services • Addressing integration and interoperability • However, integratinge-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

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

  16. Objectives and Goal

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

  18. Context Ontological Framework Vocabularies SWS Goal • Modelling a generice-Government service-supply scenario • 3 Knowledge Levels (distinct functionalities) Guidelines Configuration Service Delivery

  19. Approach

  20. Methodology • Cooperative development • Modularization • Smaller, well-defined components • Including and defining new modules Specific Scenario • Meta-Modelling • Expressing modelling process • Mapped into Meta-Ontologies Meta-Model Model of the Specific Scenario abstraction Meta-Modelling andModularization Conceptual Models e-Government Domain

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

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

  23. Results

  24. Ontological Framework • Actor’s autonomy: • Viewpoint/Context • Vocabulary User Description Provider Description Manger Description Politician Description Politician Description User Description Provider Description Manger Description Politician LE Description User LE Description Provider LE Description Manger LE Description Other Ontologies Other Ontologies Other Ontologies Is-a Is-a Is-a Is-a State of Affair Description satisfies Life Event uses Conception Description Life Event Description Domain Ontology Generic Level Plan Description Core Life Event Ontology (CLEO) Interaction Description Specific Level Service Ontology … Goal Mediator WS Knowledge useful at runtime Solving mismatch problems

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

  26. Knowledge Capture Methodology • Life event and Actor Analysis • Viewpoint Analysis • State of Affairs • Interaction • Conception • Plans • Model-specific Scenario • Create SWS descriptions

  27. Case Study

  28. 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 CountyCouncil - 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.

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

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

  31. (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#) State of Affair Analysis (2) Meta-Model (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))) Descriptive Entities specializes specifies (def-class Current-Address (cleo-attribute) ?ca ((played-by :type address))) Current Address Patient Moving Date supplies New Address (def-class New-Address (Information) ?ca ((played-by :type address))) speaks relates Community Care Dept. Case Worker requires Domain Ontology Patient Info

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

  33. InteractionAnalysis (2)

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

  35. Retrieve-list-equipments-need (Delegated to Housing Dpt) • Find-items-matching-weight-goal • Find-items-matching-impairment-goal • List-intersection-goal ConceptionAnalysis (2) Housing Department Case Worker

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

  37. Plan Analysis (2) • Workflow retrieve-list-equipments-need • Any-order-task • Finds-item-matching-weight-goal-task • Finds-item-matching-impairment-goal-task • Sync-task • 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))))

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

  39. SWS Descriptions (2)

  40. Future Work • Developing the Guideline Knowledge Level • Infrastructure/Framework for semantic interoperability • Existing components: IRS-III • New Applications

  41. Thanks a.gugliotta@open.ac.uk • 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

More Related