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
1. OWL files are taken as the input of the demo
1. Parse OWL file
1. Learn the definition of OWL
2. Represent entities and relationships with a hierarchical graphic view, 
1. for instance, an E-R model.
2. Transformation
1. OWL -- parsing --> Hierarchical Graphic View (such as E-R model) -- export --> OWL
2. Matching Ontologies. 
1. Automatic matching:
1. text similarity based matching, from the content of OWL directly.
2. mostly 1:1 matching
3. visualize the matching with some suitable way.
2. Manual matching: (human interaction involved)
1. matching types: 
1. node-node (1:1) 
2. node-set (1:m)
3. set-set (n:m)
2. matching operations on the graphic view are required (a friendly interface assisting to the user to finish the matching work).
3. Merging Ontologies
1. Zonal graph is generated based on results from previous step, and according to the merging rules defined in our paper. In other words, introduce exclusive choices and coordinated choices into the hierarchical graphic view above.
1. We could also use the merging rules in the example we used in the paper. The basic idea is as following rules:
1. algorithm please !?!?
2. Is there a way to transform the zone graph into OWL file? How to express the concept of zone in the form of OWL.
2. Some preparations for the following steps
1. Zones could be recorded or stored somewhere for the computation of agreement values which can even be calculated at this step.
4. Zone Identification and Agreement Computation
1. Get all zones caused by merging.
2. 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.
3. Produce the agreement-based integrated graphic view, whose edges are associated with their agreements. 
5. Query Processing
1. For now, we could only handle the simple path query, without branches. The basic components in the query include:
1. a/b
2. a//b
3. a/*/b (? how)
4. //* or *// is equal to // (it seems that not only one parsing of the query expression is required. )
2. Algorithm please: when the path query is represented as '1 t1 a2 t2 a3 t3 ......', how to process it?
1. Direction
2. Splitting and Processing and Joining etc. (looks not so easy L )
3. At the same time, the results should be ranked based on the path agreement. 
3. Display the results to the user with some suitable way, in order for the user to provide with feedback. 
1. What kinds of feed back do we have? 
1. change the ranking
2. eliminate some results
3. ask more results
6. Conflicts Analysis and Agreement Update
1. 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
2. Generation of fuzzy program to capture validity postulates
1. solve the program with Lingo API
2. analyze the results from Lingo, and 
3. Display the conflicts solution and the agreement update
1. the edges whose agreement is changed should be redrawn in the integrated graphic view. 
4. How to reflect the user's feedback to the original ontology!?