The role of semantics in eGovernment service model verification and evolution AAAI Spring Symposium 2006 Ljiljana Stojanovic, FZI Andreas Abecker, FZI Dimitris Apostolou, University of Pieraus Gregoris Mentzas, ICCS, Rudi Studer, AIFB

2 Politicians define the law Programmers write the code Experts decide how to implement the law End-users use a portal How to cope with the changes? X The goal of the OntoGov project is to improve back-office processes by taking into account the whole lifecycle!!! suppliers customers back- office Semantic Web Service ID Name Time Date City OutputsInputs Get Birthday Information Web Service Description

3 I1 I2 O1 O2 O3 WS1 I1 I2 O1 O2 O3 WS2 I1 I2 O1 O2 O3 WS I1 I2 O1 O2 O3 WS3 Monitor a document version Analyse which activity to change Plan how to achieve the consistency Execute the required changes Document X is changed Activity Y has to be changed Resource Z is not needed Ontology Evolution generates additional changes and propagates Effector (programmer modifies a code) X X Sensor (add entry in a log) X X X Change Management Framework

4 Modelling e-Government services  Meta Ontologies define the schema i.e. the language for modelling the e-Government services  Domain-oriented Ontologies model the concrete e-Government services and all data relevant for these services  Administration Ontologies enable better management of e-Government services

5 OntoGov model Legal Ontology Organisational Ontology Lifecycle Ontology Domain Ontology OntoGov Process Ontology OntoGovProfile Ontology Life-Event Ontology

6 Meta-ontology cluster  Legal Ontology defines the structure of the legal documents, which includes paragraphs, sections, amendments, etc.  Organisational Ontology models an organisation by defining its organisational units, roles, persons, resources etc.  Domain Ontology contains domain specific knowledge  LifeEvent Ontology models the categorisation of the e- Government services  Process Ontology describes the elements for modelling the process flow  Profile Ontology contains metadata about e-Government services and includes all previously mentioned ontologies  Lifecycle Ontology describes the information flow and the decision making process in the public administration

7 Process Ontology  It is based on the OWL-S Process Ontology  We distinguish between the services and the control constructs  Services can be either atomic or composite services  We define a standard set of attributes such as name, description, version, status etc.  There are specific requirements concerning retraceability, realisation, security, costs, etc.  each service can be associated to the laws it is based upon  each service can be associated to several software components that implement it (i.e. dynamic binding)  it is possible to assign security levels to each service  information about cost and time restrictions can be also specified  Consistency conditions are formally defined

8 Life-Event ontology  It is used for the classification of the e-government services  It includes concepts such as residential affairs, residential permissions, identification certifications, naturalization citizenship, moving, education etc.  It has been developed based on the existing standards for modelling lifeevents  For example, the Swiss Standard eCH-001 (Best Practice Structure Process Inventory - aims:  to give an overview over all relevant e-government services in Switzerland and  to provide a consistent and standardized classification of the services.  The inventory comprises e-government services that are all services initialized by a citizen or internal administration processes

9 Legal ontology  It models the structure of the legal documents, which includes paragraphs, sections, amendments  We have analyzed the structure of legal documents in Switzerland, Greece and Spain  We concluded that the legal documents have very similar structure independently of the country they are defined for  Even though different countries use different terminology to organize their legal documents, all of them use three levels of abstractions  However, each country can extend (i.e. specialise or instantiate) it as needed  It is very important to document the laws and regulations the process is based upon:  not only for the whole process but also for specific activities  By associating legislation to these services, it is possible to trace and propagate the effects that a change in the legislation (or administrative regulations) produces on the models of the administrative services

10 Organisational ontology  It describes the roles and areas of responsibility and capabilities within an organisation with respect to the activities of a process model  It models the structure of an organisation, its resources, know-how, etc.  For example, we distinguish two types of resources:  human resources who perform an activity  equipment (i.e. hardware, software etc.) that is occupied by the activity

11 Lifecycle ontology  It describes the decision-making process in the public administration  It bridges the gap between decision making and realisation by providing means:  for describing these decisions and  formally stating reasons that motivate the design decisions  It provides answers on the following questions:  “How have the process design (e.g. regarding atomic activities) and flow (e.g. regarding control constructs) been realized?”  “Why has a design decision been taken?”

12 Domain ontology  It encodes concepts of the public administration domain such as the “terminology” used in the e- government domain  For example, it defines the type and structure of documents such as passport  Input and output of an activity are represented using entities defined in this ontology

13 “Announcement of moving” e-government service modelled using the OntoGov model Lifecycle aspects Design Decision 1: Eligibility handling Reason I: Citizen must have Swiss domicile in order to perform automatic registration/deregistration Related Instance(s): SR 101 SR 210 Art. 22A – 26A Legal aspects Organisational aspects Domain aspects

14 Role of ontologies  Ontologies are used to model (formally and explicitly) e- government services  OntoGov Profile Ontology:  Used for advertising and discoveing e-government services  Based on OWL-S Profile Ontology  Extends it with e-government specific metadata LifeEvent Ontology is used for the classification of the e-government services  OntoGov Process Ontology:  Gives a detailed description of a process flow  Based on OWL-S Process Ontology  Extends it with: e-government specific metadata (e.g. Legal Ontology) in order to enable better and easier management of services set of rules: for defining consistency of a service description for resolving inconsistencies  Set of ontologies (i.e. Legal, Organisational, Domain, Lifecycle and LifeEvent) used for annotation of a service description  Are e-government specific  Model different part of reality  Contain only the top-level entities Each public organisation can extend it e.g. by specializing concepts or by creating instances

15  Ontologies are used to model aspects relevant for change management:  Service Evolution ontology  It models what changes, why, when, by whom and how are performed in a service description, e.g.  Hierarchy of possible changes is developed based on the OntoGov model They build the backbone of the change management system They correspond to the “conceptual” operation that someone wants to apply without understanding the details (i.e. a set of ontology changes) that the management system has to perform  To enable reversibility as well as the synchronisation between different version of an ontology, this ontology includes: the “cause-effects” dependency between changes a change may cause new changes in order to keep the service model consistent the order in which the changes are requested groups of changes of one request (requested or induced) are maintained in a linked list using the Role of ontologies (cont.)

16 Change Management Framework Ontology Evolution Change Detection M M A A P P E E Evolution Ontology Process1Process2Process3 StartEnd Law Code A A E-Government Portal M M Service ontologies Usage Ontology Lifecycle Ontology Evolution Log Usage Log

17 Change management  It has to enable the resolution of a given change in a systematic manner by ensuring the consistency of the whole ontology Inconsistency Detection Change Generation Change Application Change Resolution  Inconsistency Detection: It is responsible for checking of the consistency of an ontology with the respect to the ontology consistency definition. Its goal is to find ”parts” in the ontology that do not meet consistency conditions  Change Generation: It ensures the consistency of the ontology by generating additional changes that resolve detected inconsistencies  The approach requires:  explicit specification of changes that can be applied  the consistency definition  Changes have to preserve the consistency

18 Service consistency  Ontology consistency in general is defined as a set of conditions that must hold for every ontology  An e-Government service ontology is consistent:  if it is ontology consistent and  if it satisfies a set of consistency constraints defined for the service model  Consistency constraints have been defined in order to take into account specificities of the Meta Ontologies  Meta Ontologies represent the language for describing services and therefore they define consistency of e- Government services

19 Inconsistency detection Two approaches are possible:  The procedural approach - semantics is given by a procedural mechanism that is capable of providing answer to wide class of consistency problems  It traverses the process model and checks every entity within on its consistency  Difficult to cover all options, since models may be very complex  The declarative approach is based on the sound and complete set of consistency rules (provided with an inference mechanism) that formalises the model  It applies reasoning based on a set of consistency rules

20 Incosistency detection

21 Changes  Ontology changes include changes such “AddAxiom” and “RemoveAxiom”  To make a service s1 a predecessor of a service s2, a domain expert needs to apply a list of ontology changes that connects s1 to s2  Domain experts require a method for expressing their needs in an exacter, easier and more declarative manner  For a domain expert it would be more useful to know that he can connect two services rather than to know how to do that  Intent of changes has to be expressed on a more coarse level

22  Semantics of changes is specified  It guarantees that a required change is correctly propagated and that no inconsistency is left in the system  Each change is described in a form:  Precondition - a set of assertions that must be true to be able to apply a change  Postcondition - a set of assertions that must be true after applying a change and it describes the result of a change  Actions are additional changes that have to be generated  E.g. RemoveAtomicService X  Precondition – AtomicService X has been defined  Postcondition – AtomicService X doesn‘t exist anymore  Actions:  Remove all input links of AtomicService X;  Remove all output links of AtomicService X;  Remove all metadata defined for AtomicService X that includes: the attributes such as name, description, fist and last service; the relations to the legal, organisational and domain ontology; the pre- and post-conditions X Changes

23 Change propagation  Two types of change propagation are supported:  From the associated ontologies to the service description  From the included composite services to the service description  The following procedure is realized:  The definition of a process model is extended with the version of each referenced ontology  Changes in the referenced ontologies are logged in their logs (which results in the new version of these ontologies)  Push-based synchronisaton: On the explicit request all changes between two synchronisatons are discovered  Their impact on a service model is determined  For each „link“ the corresponding Remove change is recommended  For new entities the LifeCycle aspects are taken into account  The domain expert may accept recommendations or not

24 OMS

25 State-of-the-art

26 OntoGov achievements

27 OntoGov SWS Activities  Ontology Management  Publishing  Discovery

28 Ontology Management  Within the OntoGov project, we have extended the standard approaches in two directions:  Change Management – it is the timely adaptation of a service description to the changes in business requirements, users’ needs, etc. as well as the consistent propagation of these changes to dependent artefacts  The OntoGov approach enables agile response to frequent and huge changes by ensuring the consistency preservation as well as the propagation of changes;  Lifecycle Management – even though knowledge is becoming recognised as one of the most important success factors of engaging policy makers, public administration managers, citizens and businesses in e- government, there is a lack of proven methods for the application of knowledge technologies  The OntoGov lifecycle management bridges the gap between decision making and realisation by providing means for describing these decisions and formally stating reasons that motivate the design decisions

29 Publishing  Publishing OntoGov service is based on the OntoGov Profile Ontology  Our approach focuses on imprecise or redundant annotation  It contains guidelines for building well-formed service announcement that are easier to be understood and cheaper to be modified  The “quality” of the annotation can be assessed through the existence of redundancy, inaccurate or incomplete information

30 Discovery  A number of proposals for automating the discovery of services are available  They do not consider the fact that a user’s query is just an approximation of his information need  OntoGov service discovery has been realized by combining three different types of conditions:  Query-by-example– it is used for specifying conditions on the service definitions, supplying the constraints on various fields;  Reasoning using class hierarchy – the user can specify the type of services. Subsumption reasoning is used to locate services that are more specific than specified;  Conceptual Query Refinement – the user defines keywords specifying the relevant terms that the service description must contain. The refinement system takes as the input the results of keyword-based search; whereas results are service descriptions. The system calculates refinements and generates a set of possible extensions of the original query

31 Architecture  The novelty of the OntoGov approach lies in the formal verification of the service description as well as in the using of formal methods for achieving consistency when a problem is discovered  This has been realized through two components:  Verificator  Verification of the OWL-S process model is extended in several dimensions First, we model the not only control-flow and data flow consistency constraints. We allow to the public administrators to specify arbitrary domain-dependent consistency constraints. In this way we are able to cover all perspectives of the business models, i.e. control flow, data flow, operational issues (e.g. interactions between systems) and resources (e.g. humans, machines etc.) Second, we do not consider only the process model but also the profile of a service Finally, we have realized the verification of the e-government service descriptions using rule-based inference process  Recommender  We propose formal approach for suggesting fixes that directly point to the source of the inconsistencies  The recommender is based on the so-called change-dependency graph, which is a common technique for the maintenance of the knowledge-based systems

32 Service Ontology  The most similar approach to the OntoGov approach is the OWL-S, since other approaches do not include the ontologies for modeling processes  The OntoGov model consists of two major parts – the OntoGov Profile ontology and the OntoGov Process ontology, which are developed based on the OWL-S ontologies  However, both of them are extended / adapted in order to take into account unique characteristics of the e-government services as well as some aspects needed for the better management of changes

33 Conclusion  Ontology-based change management system enables:  automatic identification of inconsistencies in the description of the E-Government services (log)  analysis of a problem (lifecycle ontology)  generation of recommendations for resolving problems  Advantages:  Faster and better service design by all stakeholders involved in the service lifecycle (e.g. managers, software developers)  Better control and propagation of changes (e.g. control of changes in law and propagation of changes to the software that delivers the service online)  More and better information about each step of the service delivery process, for all stakeholders involved in the service lifecycle

34 Thanks! Any questions?

Back up slides

36 User-defined Consistency  The user-defined consistency constraints are user‘s requirements that need to be expressed “outside” of the ontology language itself  Two types of the user-defined consistency conditions are identified:  generic conditions that are applicable across domains and represent best design practice or modeling quality criteria modeling quality conditions: redundancy, misplaced properties, missing properties, etc.  domain dependent conditions that take into account the semantics of a particular formalism of the domain All entities in the model must be connected Inputs & outputs must be defined in the domain ontology If input of a service is output of another service, then it has to be subsumed by this output

37 OMS – Service Modeller & Service Registry

38 Change generation

39 Change propagation  Extracting Deltas  Reading Evolution Log  Analysis of changes  For a new amendment a corresponding law can be found  For a law all services that realize it can be found  Making Recommendation  Lifecycle Ontology describes design decisions and their relationship to affected parts of the service as well as to the requirements that motivate the decisions  It is a description of the service design process, which clarifies which design decisions were taken for which reasons, proves to be valuable for further development and maintenance Legal Legal ‘ Meta OntoGov Supplier