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