Issues to be Concerned in the Implementation of Demo

We have some steps to follow in the demo. Here, these are displayed below one by one:

1. Input of Ontologies

A. OWL files are taken as the input

1. Parse OWL file

a. Learn the definition of OWL

b. Get all classes, instances, and relationships

2. Represent entities and relationships with a hierarchical graphic view,

a. for instance, an E-R model, thus a label depicting the relationship could be associated with each edge.

B. Transformation

1. OWL – (input, parsing) --> Hierarchical Graphic View (such as E-R model) – (export) --> OWL

2. If there exist some integrity constraints, they should be defined with some formal way, so as to be understood by the program. (???)

2. Matching Ontologies.

A. Automatic matching:

1. text similarity based matching, from the content of OWL directly.

2. When a string repeats in some ontologies, it’s not clear that how to match them. For instance, ‘name’ occurs in one ontology several times, and also happens in some other ontology not only once, the solutions could be:

a. User decides (for now)

b. Leave it alone

c. Context-based

3. visualize the matching with some suitable way.

a. Table might be used to display all text-similar matching, like:

	Ontology 1	Ontology 2	......	Ontology n
1	Large Mam	Large Mammmal		--
2	Baron	--		Baro

B. Manual matching: (human interaction involved)

1. matching types:

a. node-node (1:1)

b. node-set (1:m)

c. set-set (n:m)

2. the challenge here is to implement matching operations directly on the graphic view (in other words, a friendly interface assisting to the user to finish the matching work).

3. Merging Ontologies

A. Zonal graph is generated based on results from previous step and the merging rules defined in our paper. In other words, by means of introducing exclusive choices and coordinated choices into the hierarchical graphic view above.

1. Three different cases as follows should be handled:

a. 1:1 matching:

b. 1:n matching:

c. m:n matching:

2. If the zonal graph is treated as the intermediated form of the integration, it may be necessary to store it in some form in order for the later use.

B. Some preparations for the following steps

1. Zones could be recorded or stored somewhere for the computation of agreement values, since each zone could be identified at this step.

2. Even more, the agreement of each connection could be computed at this step as well.

4. Zone Identification and Agreement Computation

A. Get all zones caused by merging.

B. Compute the agreement of each edge representing one relationship in OWL file.

1. For each zone, compute the number of models.

2. Calculate the agreement of each source-sink pair in the zone.

C. Produce the agreement-based integrated graphic view, whose edges are associated with their agreements.

1. The graph generated here is more general, as an edge-labeled directed graph.

5. Query Processing

A. For now, we could only handle the simple path query without containing branches. The basic components in the query include:

1. a/b

2. a//b

3. a/*/b

4. //* or *// is equal to // (it seems that not only once is required for parsing of the query expression. )

B. Algorithm: when the path query is represented as 'a1 t1 a2 t2 a3 t3 ......', how to process it? (where a? is node, t? is {/, //, *}.)

1. Direction

2. Splitting and Processing and Joining etc. (looks not so easy)

3. The results should be ranked based on the path agreement.

C. Display the results to the user with some suitable way, in order for the user to provide with feedback.

1. What kinds of feedback are potential?

a. change the ranking

b. eliminate some results

c. ask more results

d. ???

6. Conflicts Analysis and Agreement Update

A. Definition of conflicts and constraints according to our paper

1. zonal conflicts

2. path integrity conflicts

3. acyclicity conflicts

4. user's feedback

5. other global / integrity constraints

6. user defining constraints???

B. Generation of fuzzy program to capture validity postulates

1. Construct the fuzzy program

2. solve the program with Lingo API

3. analyze the results from Lingo, and

C. Display the conflicts solution and the agreement update

1. the edges whose agreement is changed should be redrawn in the integrated graphic view.

D. How to reflect the user's feedback to the original ontology!? In other words, how to connect the user’s feedback and the system update explicitly.