Extension Of The M-Gov Ontology Mapping Framework For .

As in [10], it is referred as “to analyze the addressed ontologies to identify difficultiesthat may be involved for generating mappings.” 3) Reuse: It discovers whether anyexisting alignment can be used for the new mappings. 4) Match: This phase uses theinformation captured in the characterization phase. The selected ontologies and theconfigured matchers are used to identify the potential correspondences, which need tobe evaluated for their fitness to form an alignment. 5) Align and Map: Manual refinement of the candidate correspondences is needed to create an alignment. The ruleswritten based on the alignment is called as mapping. 6) Application: The stakeholders identify the application, which will use the formed mappings. If either source ortarget ontologies change over time, this will trigger the new interaction in the community and lead to a new version of mapping.Adopting a project-centric perspective in ontology mapping process allows one tocapture the metadata of various aspects of the mapping process. Using the extensionof PROV-O as metadata model makes the ontology mapping process more traceable,as it will not only allow one to formulate queries to reuse existing mappings but alsoformulate questions about the activities happened during the mapping process.This paper is built on [4] by a) using an extension of PROV-O to capture each activity in alignment creation process; b) using IBIS [12] for structuring the discussions;c) extending the work done by [4] on M-Gov framework. The “stage” and “characterize” phase of M-Gov was already implemented by [4].This paper extends the initial M-Gov implementation; it implements the “matchphase” of M-Gov and evaluates the correspondences identified in match phase. Thenext section presents the methodology adopted for ontology matching and evaluationof correspondences.3 Match Phase of M-Gov frameworkThis section describes the requirements, design, and implementation of the matchphase newly developed for the M-Gov framework.3.1 Functional requirementsThe main objective of the Match Phase is to identify the potential correspondencesbetween two datasets automatically and capture the metadata produced during thealignment creation [4], with the following functional requirements being derived. Thematch phase should allow a user to configure the matcher by selecting a source ontology, a target ontology, and a matching tool. A matching tool needs to be used to identify the correspondences between the selected ontologies automatically. Identifiedcorrespondences need to be displayed on a web page. Users should be allowed todiscuss every displayed correspondence with other users by presenting their opinionabout its fitness. Based on the discussion, users should be allowed to accept or reject acorrespondence. The configuration of matcher, identified correspondence, and discussions of the users about the fitness of the correspondences, need to be stored as themetadata. The metadata should be captured in a queryable format, as that will enablethe traceability in the alignment creation process.

3.2 DesignTo fulfill the functional requirements, there needed to be a number of aspects designed. In this section, we present a quick overview of the design. The design wasfocused on an initial baseline without sophisticated UI as our focus was on interactionprocess and capturing of discussions. Future work will develop the UI. In addition, wefocused on an alignment problem where pre-processing is not necessary, as the experimental focus was on traceability of the captured discussions. However, it would beeasy to add further steps and linked discussions in the M-Gov framework.A web based form was built to allow the users to configure the matcher by selecting a source and target ontology, and a matcher tool. The matcher configuration wasstored in a database. Selected ontologies were matched using Alignment API 4.8. AREST call was designed for communicating with the Alignment API. The AlignmentAPI returns the potential correspondences in alignment format (an XML format asshown in Fig. 2.), which was used to capture the M-Gov metadata about the identifiedcorrespondences. The captured metadata is again stored in the database. Furthermore,an interface was designed to present the M-Gov metadata about the potential correspondences for stakeholders to discuss. To provide context for discussions about thecorrespondences, the values of object1 and object2 on the interface were linked totheir online Linked Data resources. The interface was also designed to show thecomments of all the stakeholders on a correspondence. Thus, allows the stakeholdersto see other perspectives about the fitness of a correspondence. The discussions ofstakeholders are structured by using the IBIS framework and the metadata model usedin the M-Gov framework is an extension of PROV-O, as suggested by [4]. Fig. 1shows the interaction between the elements of the design during the match phase ofthe M-Gov framework.Fig. 1. Design of match phase of M-Gov Framework [4]The capture of discussions was the major challenge faced while designing the MGov match phase supports, as this will enable the traceability in an alignment creation

process. For this, we capture every statement given by each stakeholder during thealignment creation. In M-Gov every statement is linked with its creator, and correspondence’s ID on which the statement has been made. M-Gov also captures theconclusion and the stakeholder’s ID who concluded that discussion. Table 2 describesthe M-Gov metadata used to track the discussion.Table 1: M-Gov metadata related to discussionM-Gov captured usiondecideddecidedByoutcomeDescriptionUnique identifier attached to each discussionType of discussion: a conclusion or just an opinionStakeholder who made the statementContent of statementType of statement, e.g.: supporting or objectingFinal statement while concluding the correspondenceTimestamp of the conclusionStakeholder who concluded the correspondenceIf the correspondence is accepted to rejected3.3 ImplementationA form has been built to allow a user to select a source and target ontology, and amatcher tool. A user can select these parameters from a drop-down menu to configurethe matcher. The M-Gov uses these parameters to create the URL to invoke a RESTcall to Alignment API. Fig. 2 describes the response from Alignment API, it shows anexample of a potential equivalence correspondence (line 5) between “HumanActor”(line 3) and “HumanActorAge” (line 4) with a confidence of 0.93 (line 6).Fig. 2. Response of Alignment APIThe M-Gov displays every potential correspondence on a webpage using grid tables, which also contains a "state" column, whose default value is “inDiscussion”.The M-Gov also attaches a “change decision” button to every displayed correspondence, which is used to start a new discussion thread for that correspondence. If thediscussion thread is already created then this button will lead to the in progress discussion for that correspondence. Once the users reach a consensus after discussion,the M-Gov provides a “Conclude discussion” link, which allows a user to change thestate of the correspondence to either “Accepted” or “Rejected”. The M-Gov alsostores the discussions along with the user’s information under the “post” table in thedatabase.

Fig. 3 represents the page by which stakeholders can add their arguments to participate in a discussion about a correspondence. In our example of Fig. 2, this wouldinvolve discussion of whether HumanActor and HumanActorAge are really equivalent? Fig. 3 shows the overview of the correspondence and arguments about its fitness. “reply” textbox can be used to add arguments, while a suitable reply type needsto be selected from the dropdown “Reply Type”, whose values are “Supporting example, objecting example, supporting justification, objecting justification, supportingmotivation and objecting motivation”.Fig. 3. M-Gov Match Discussion page4 EvaluationMotivation. The purpose of this experiment was to trace the discussions among thestakeholders during the alignment creation process and identify the following: 1) levelof participation of various users of a group during alignment creation. 2) most discussed correspondences by users of a group. 3) accuracy of a group in creating alignment.In the experiment, we have used three types of correspondences: a) Correct correspondences - those in which both objects point towards the same resource. b) Incorrect correspondences - those in which both objects point towards completely differentresources. c) Ambiguous correspondences - those in which both objects point towardsdifferent resources. But to understand the difference, a user needs to go through asubstantial amount of information, as the difference might not be clear from the labelof the entities.Hypothesis. In most cases, the discussion thread attached to an ambiguous correspondence will be longer than correct and incorrect correspondences.Experiment method. We formed 4 groups, 3 groups contained 3 users while 1group contained only 2 users. A separate instance of the framework was provided for

each group. Every user was located at a different workstation and was allocated discrete credentials to log into the framework. We have only used instance level correspondences in the experiment, since creating concept level correspondences requiresparticipants with a deeper understanding (who are harder to recruit). It was thus decided to first investigate stakeholder collaboration tracing using instance level correspondences, which could be performed by a wider range of participants. We created adiscrete set of 7 instance level equivalence correspondences for each group, the complete list is available online1. Semantic mapping researchers validated the createdcorrespondences. These correspondences have been created manually and injected inthe framework for discussion, which covers three types of correspondences as follows: a) Correct correspondence: These are created by taking an entity from OSi2dataset as object1, while the object2 has been selected from DBpedia 3, which pointsto the exact same resource as referred by object1. For example, “County Roscommonrepresented by OSi” and “County Roscommon represented by DBpedia”, b) Incorrectcorrespondence: These are created by taking an entity from OSi dataset as object1,while the object2 has been selected from DBpedia, which points to a completely different resource than that referred by object1. For example, “County Roscommonrepresented by OSi” and “County Clare represented by DBpedia”, c) Ambiguouscorrespondence: These are created by taking an entity from OSi dataset as object1,while the object2 has been selected from DBpedia, which points to the resource thathas a label similar to the resource referred by object1. To figure out the differencebetween both objects, a user needs to ex

community-driven ontology matching and an overview of the M-Gov framework. 2.1 Collaborative ontology engineering . Ontology engineering refers to the study of the activities related to the ontology de-velopment, the ontology life cycle, and tools and technologies for building the ontol-ogies [6]. In the situation of a collaborative ontology .