Wednesday, December 13, 2006

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

Monday, December 11, 2006

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. (???)

  1. 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).

  1. 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.

  1. 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.

  1. 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. ???

  1. 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.

Sunday, December 10, 2006

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