Learning OWL (2)

(http://www.w3.org/TR/owl-guide/)

The OWL Web Ontologoy Language is a language for defining and instantiating Web ontologies. Ontology is a term borrowed from philosophy that refers to the science of describing the kinds of entities in the world and how they are related.

An OWL ontology may include descriptions of classes, properties and their instances.

In addition, OWL makes an open world assumption. That is, descriptions of resources are not confined to a single file or scope. While class C1 may be defined originally in ontology O1, it can be extended in other ontologies. The consequences of these additional propositions about C1 are monotonic. New information cannot retract previous information. New information can be contradictory, but facts and entailments can only be added, never deleted.

A class definition has two parts: a name introduction or reference and a list of restrictions. Each of the immediate contained expressions in the class definition further restricts the instances of the defined class. Instances of the class belong to the intersection of the restrictions. So far we have only seen examples that include a single restriction, forcing the new class to be a subclass of some other named class.

The rdfs:label entry provides an optional human readable name for this class. Presentation tools can make use of it. The "lang" attribute provides support for multiple languages. A label is like a comment and contributes nothing to the logical interpretation of an ontology.

Basic Elements

Most of the elements of an OWL ontology concern classes, properties, instances of classes, and relationships between these instances.

I. Simple Classes and Individuals

A. Simple Named Classes: Class, rdfs:subClassOf

1. The most basic concepts in a domain should correspond to classes that are the roots of various taxonomic trees. Every individual in the OWL world is a member of the class owl:Thing. Thus each user-defined class is implicitly a subclass of owl:Thing. Domain specific root classes are defined by simply declaring a named class. OWL also defines the empty class, owl:Nothing.

B. Individuals

1. In addition to classes, we want to be able to describe their members. We normally think of these as individuals in our universe of things. An individual is minimally introduced by declaring it to be a member of a class.

C. Design and use

1. In certain contexts something that is obviously a class can itself be considered an instance of something else.

2. It is very easy to confuse the instance-of relationship with the subclass relationship.

II. Simple Properties

A. Properties let us assert general facts about the members of classes and specific facts about individuals.

B. Definition

1. A property is a binary relation. Two types of properties are distinguished:

a) datatype properties, relations between instances of classes and RDF literals and XML Schema datatypes

b) object properties, relations between instances of two classes. Note that the name object property is not intended to reflect a connection with the RDF term rdf:object.

2. When we define a property there are a number of ways to restrict the relation. The domain and range can be specified. The property can be defined to be a specialization (subproperty) of an existing property. Properties, like classes, can be arranged in a hierarchy.

C. Properties and Datatypes

1. We distinguish properties according to whether they relate individuals to individuals (object properties) or individuals to datatypes (datatype properties). Datatype properties may range over RDF literals or simple types defined in accordance with XML Schema datatypes.

D. Properties of Individuals

III. Property Characteristics

A. TransitiveProperty: P(x,y) and P(y,z) implies P(x,z)

B. SymmetricProperty: P(x,y) iff P(y,x)

C. FunctionalProperty: P(x,y) and P(x,z) implies y = z

D. inverseOf: P1(x,y) iff P2(y,x)

E. InverseFunctionalProperty: P(y,x) and P(z,x) implies y = z

IV. Property Restrictions

In addition to designating property characteristics, it is possible to further constrain the range of a property in specific contexts in a variety of ways.

A. allValuesFrom and someValuesFrom;

1. local to their containing class definition.

B. Cardinality

C. hasValue

1. specify classes based on the existence of particular property values. Hence, an individual will be a member of such a class whenever at least one of its property values is equal to the hasValue resource.

Ontology Mapping

In order for ontologies to have the maximum impact, they need to be widely shared. It is important to realize that much of the effort of developing an ontology is devoted to hooking together classes and properties in ways that maximize implications. It will be challenging to merge a collection of ontologies.

I. Equivalence between Classes and Properties

A. equivalentClass, is used to indicate that two classes have precisely the same instances.

B. equivalentProperty

II. Identity between Individuals

A. sameAs

III. Different Individuals

A. different from

B. All different

Complex Classes

OWL provides additional constructors with which to form classes. These constructors can be used to create so-called class expressions. Note that Class expressions can be nested without requiring the creation of names for every intermediate class. This allows the use of set operations to build up complex classes from anonymous classes or classes with value restrictions.

I. Set Operators

A. Intersection: intersectionOf

B. Union: unionOf

C. Complement: complementOf

II. Enumerated Classes

A. oneOf

III. Disjoint Classes

A. disjointWith

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.

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

Some Issues to be Concerned in our Research

There are 2 parts in the work of next month, one of them is about research, and the other is about the implementation of the Demo. Now, let's take a close look at what we should do with the research work first. (The other part will be checked soon. )

1. Query extension - XPath & XQuery: we could introduce the evaluation of complex queries in our work. We have two choices:
1. Define the intermediate representation of the query. Then, transformation from XPath or XQuery to the intermediate form should be defined. 
2. Another one is to equivalently transform the XQuery into one XPath query expression or one set of XPaths queries etc. 
2. Dealing with the branch queries: (necessary, since we want to handle more complex queries in XPath)
1. In our current work, we can process the simple path query by means of k-shortest paths algorithm in the directed graph. 
2. When the branch query is concerned, we could make use of the existing algorithm like k-shortest paths, to finish the evaluation. 
1. The assumption is that we should have a way to measure the 'agreement' of the branch, like that of the path. (More general definition of agreement. )
2. Another question is related to the way how to get the instance satisfying the branch query from the directed graph. The possible solutions include:
1. JOIN method: splitting the branch query into path queries,  evaluating each path query, and finally joining all instances from each path query. 
2. some holistic query-evaluating algorithm could be used to process the branch queries, for instance Prufer sequence gives a choice to evaluate the branch query holistically. 

       One problem is that most of holistic algorithms require tree-like data modal, not         the directed         graph. Therefore, algorithms to find spanning tree in the directed         graph may firstly be exploited in this case.

3. The last issue is about the definition of conflicts in our paper. It might need improving in the new situation where complex queries compared with the path query, are involved.

1. In sum, we (actually it's me) should do something to try solving problems above. I have a very simple plan, as follows:
1. XPath and XQuery 
1. write a report on the basic knowledge of these two concepts.
2. Path query --> Branch query
1. implement the Join algorithm to evaluate the branch query
2. implement the holistic query evaluating algorithm to evaluate the branch query.
3. Understand the current definition of conflicts in our paper, and summarize the properties of the conflicts. It should be able to handle more complex cases about conflicts, like those among path instances that have different sources or sinks. 

In the morning, we had a meeting about the proceeding of the research. In the following work, we have two concentrations: one is about Demo, and the other is about the Journal paper for VLDB. 

1. Research paper
1. Based on the CleanDB paper, a journal paper should be compiled. Since the CleanDB paper is relatively simple because of the space limit, more details should be provided in this journal paper, such as:
1. Motivation
2. Extensions
3. Expressive power
4. Evaluation
2. Some new aspects need noticing, such as 
1. In order to deal with more complex query, (not only path query, but branch query ...), we should improve the query processing by introducing the algorithms to find ranked candidates for the branch query. (one way is to exploit the spanning tree to handle the branch queries, and the other is to use the join operation on the basis of path results.)
2. Now, we can only deal with part of XPath query. In the future, XPath, even XQuery should be considered. 
3. For results of one path query, they could have different sources or sinks, since many nodes can have the same tag, or value. It is not very hard if virtual nodes are used as the common source and sink. On problem in this case might be related to the identification of conflicts. (??? I am still considering what it is??? ) 
2. Implementation of Demo: Three main parts make up the whole process: matching, merging and query evaluation. Furthermore, some components could be defined for each part. We also have some questions about the implementation.
1. What data model we will use in our demo? In other words, what is the input of the system? The candidate includes OWL, which could be used for ontologies from multiple sources. 
2. Matching: 
1. Text similarity based matching; (please find the right algorithm ...)
2. User can provide additional information to assist the matching among nodes
3. Structure based matching, where we could make use of Kim's work (?? how)
3. Merging algorithm, 
1. for the moment, we use the scheme presented in the paper (submitted to Sigmod) to merger matched nodes.
4. Zone identification and agreement computation
1. From the integrated view of inputting ontologies, the zone graph should be constructed.
2. Based on the zonal graph, zones are identified and agreements of zonal choices are computed. 
3. A edge-labeled directed graph is then generated to be the agreement-based graph.
5. Path instances enumeration for XPath
1. Based on the user's XPath query, candidates of the results are enumerated and ranked based on the path agreements. (here, we could introduce k-span tree searching algorithm to extend the complexity of queries, from path to branch ...)
6. Constraints evaluation and fuzzy program optimization
1. this part is domain specific.
2. degree of conflicts needs measuring.

The first 3 issues above and the last one are domain specific, and the rest is relatively independent of the domain of application.