Welcome to GFL Website

This site is under construction. At the moment it comprises only a draft of Conceptual Modeling Tutorial.

GFL is a graphic framework for knowledge representation. It is intended for the description of the conceptual models associated with IMT data modules. It is   an integrated part of Ecosystem Services Database (ESD) which will provide a graphical description of data and queries available in ESD.  In the later stages we may also support graphical design of  ESD queries. GFL stands for Graphic Frame Logic. It is a graphical form of popular F-Logic formalism intended for visual representation of ontologies and database queries. GFL is essentially similar to Description Logic frameworks  for knowledge representation.  But since GFL is merely a graphic form of F-Logic, it   has essentially  the same expressive power as the later. Unlike Description Logics  GFL uses variables and supports arbitrarily complex queries. GFL is a web oriented language. Besides the graphical representation of F-Logic it also includes FLML- i.e. F-Logic Markup Language.

Conceptual Modeling Tutorial (Table of Contents)

1. A Quick Introduction to Knowledge Engineering

1.1. Classes, Objects , and All that

1.2. Logic and Prolog

1.3. Ontologies

2. Non Formal Introduction to GFL

2.1. Why GFL?

2.2 Is-a  Statements

2.3. Statements about Object's   Attributes

2.4. Class Signatures

2.5. Inheritance

2.6 Variables and Queries

2.7 Queries with logical operators

2.8 External Symbols and Foreign Ontology Languages Support

3. Inference in F-Logic and GFL

3.1 Rules

3.2  Method, Parameters, and  Relations.

3.3 Mathematical Expressions in rule body

3.4  Aggregation Statements

4. About Graphic Extensions

4.1 A Stimulating  Example

4.2 Graphic Extensions Philosophy

4.3 Family Tree Example

4.4   Semantics of Biodiversity Data .

4.5 Ontology Browsing Philosophy

5. Constrains

5.1 Rules and Structural Constrains

5. 2 Operators and Generic Graphic Extensions 

NOTES ON IMPLEMENTATION (for programmers)

C 2003 S. Krivov ; Send your comments to skrivov@zoo.uvm.edu

 1.A Quick Introduction to Knowledge Engineering

This introduction is written for domain experts, participating in the process of knowledge engineering. More specifically it is intended for domain experts participating in IMT project.  It does not require any programming experience as a prerequisite.

1.1 Classes, Objects , and All that

Non-programmers hearing about classes and objects often think of them as a part of computer jargon. Yet the meaning of these concepts is close to one they have in the context of the common language. Class  usually mean a class of objects - that is a group of objects sharing similar features. Objects in the world of computers are data structures which often represent real world objects. Thus, Object Oriented Programming (OOP)  employ the notion of taxonomy or classification as a metaphor for structuring of data.

You can look around you now and see many examples of real-world objects: your cat, your desk, your computer, your bicycle and so on. These real-world objects share two characteristics: they all have state and behavior. For example, cats have state (name, color, breed, hunger) and behavior (playing, eating, sleeping). Bicycles have state (current gear, current pedal cadence, two wheels, number of gears) and behavior (braking, accelerating, slowing down, changing gears).

Software objects are modeled after real-world objects in that they too have state and behavior. A software object maintains its state in one or more attributes. Attributes are identified by their names.  A software object implements its behavior with methods. Thus,  a software object is a bundle of related attributes and methods.

You can represent real-world objects by using software objects. In the real world, you often have many objects of the same kind. For example, your bicycle is just one of many bicycles in the world. Using object-oriented terminology, we say that your bicycle object is an instance of the class bicycle. The class for our bicycle example would declare the attributes necessary to represent the current gear, the current cadence, and so on, for each bicycle object. The class would also declare and provide implementations for the instance methods that allow the rider to change gears, brake, and change the pedaling cadence. All instances of the class bicycle will contain these attributes and methods.

The classes in the real world  are often grouped  into hierarchies or  taxonomies. For example, mountain bikes, racing bikes, and tandems are 3 different types of bicycles. In object-oriented terminology, mountain bikes, racing bikes, and tandems are all subclasses of the bicycle class. Similarly, the bicycle class is the superclass for these 3 classes.

Inheritance provides a powerful and natural mechanism for organizing and structuring software programs. Each subclass inherits its attributes from the superclass. Mountain bikes, racing bikes, and tandems share some attributes: cadence, speed, and the like. Also, each subclass inherits methods from the superclass. Mountain bikes, racing bikes, and tandems share some behaviors: for example, braking and changing pedaling speed.

However, subclasses are not limited to the state and behaviors provided to them by their superclass. Subclasses can add attributes and methods to the ones they inherit from the superclass. Tandem bicycles have two seats and two sets of handle bars; some mountain bikes have an extra set of gears with a lower gear ratio. Subclasses can also override inherited methods and provide specialized implementations for those methods.

Given above is a description of the most common ideas of  OOP. And here is the difficult part: although all Object -Oriented languages use the same underlying metaphor, classes and objects have slightly different  properties and functions in various languages.  Thus, the precise meaning of these concepts can be defined only in the context of a particular computer language.

1.2 Logic and Prolog

 A system of logic comprises a set of rules which allow to make a right conclusion from the right facts. Logic has a long history. The earliest  form of logic, as well-known in the West, is Aristotelian Logic. Before that, the first known  system of logic was developed in India by Nyaya-Vaiseshika   philosophical school. Various forms of logic have been used for data representation. They all share one important property - that every logic-based representation is designed to facilitate inference of new facts from existing facts.

The First Order Logic, sometimes called simply Predicate Logic, is widely used as a language of modern mathematics. The representation of the knowledge in Predicate Logic  is based on the following ideas:

 1. Every object (real or abstract) has a unique name

2. Predicates are used to describe properties of objects and relations between them. For example notation farmer(roel) may assert the fact "roel is a farmer"; notation likes(roel,roels_bicycle) means "roel likes roels_bicycle". Here "roel" and "roels_bicycle" are unique names for particular objects of the real world - "Roel" and "Roel's bicycle".  In F-Logic those words which start from capitals denote variables. Therefore, (may Roel excuse us) we have to always start object and class names with small letters.

3. Complex expressions are built with the help of  object variables  , quantifiers , and logical symbols .  There are just two quantifiers (forall x) and (exists x).  Logical symbols usually include at least four: & (read it as 'and'), \/ (or),  ~ (not) , and -> (read it as 'follows'  or as if...then...)    Here are the examples of their use.  The expression

(forall x) (organic_farmer(x)-->farmer(x))

states that "for every  x , if x is an organic farmer , then x is also a farmer".; or "every organic farmer is a farmer".

The expression

(forall x) (farmer(x) --> (exists y)(farm(y)&owns(x,y)))

states that for any farmer  (x) there is a farm (y) which this farmer owns.

As we can see logic-based paradigm for knowledge representation differs from Object Oriented paradigm. Although here we also have objects  like roel, roels_bycicle, and classes like farmer(x), or organic_farmer(x), all properties of objects are stored externally in the form of relations.  Say the relation color(roels_bycicle, black ) may represent an attribute "color"  of the object "roels_bycicle" . However, this relation is not bundled with this object; it is independent. The specific paradigm of knowledge representation  where knowledge is represented in the form of a relation is called relational. The term Relational Database means just that. Prolog is another example of a relational language.

First Order Logic can express almost any assertion about real or abstract objects. But it is not decidable. It is said that a system of logic is not decidable if   there is no any generic algorithm which would allow finding whether a given  expression is a logical consequence of certain given axioms. This implies  that Predicate Logic in its pure form is not of much use in computer applications. Numerous decidable systems of logic were  derived from Predicate Logic. One of such systems was a source of inspiration for PROLOG (which stands for PROgramming in LOGic). Prolog was the first declarative language. Unlike procedural ones, declarative languages do not tell computer "what to do",  rather they tell "what things are". Prolog uses such declarative statements for proving or refuting a given query expressed in terms of Predicate Logic. Prolog often serves as a  language for deductive databases.

More to come......

For more information on logic and PROLOG read Alison Cawsey online book "Databases and Artificial Intelligence".

Here are the direct links: A Chapter on Predicate logic   ;   A Chapter on Prolog

1.3 Ontologies

In the context of knowledge engineering,  the term ontology means a specification of a conceptualization. That is, an ontology is a description  of the concepts and relationships pertained to a specific area of knowledge such as biology , ecology, marketing etc.  Ontologies establish a joint terminology between the members of a community of interest. These members can be human or automated agents. Several representation languages and systems were developed for ontologies. KIF-based Ontololingua, Loom, F-Logic are examples of representation languages based on First Order Logic, but with different expressiveness and computational properties. However, for applications on the web it is important to have a language with a standardized syntax.  The World Wide Web Consortium (W3C) has developed the Extensible Markup Language (XML) which allows information to be more accurately described using tags. As an example, the word Algol on a web site might represent a computer language, a star or an oceanographic research ship. The use of XML to provide metadata markup, such as Algol, makes the meaning of the work unambiguous. However, XML has a limited capability to describe the relationships (schemas or ontologies) with respect to objects. The use of RDF and RDF Schema provides a very powerful way to extend the capabilities of XML to describe objects and their relationships to other objects.  An ontology language based  on RDF and RDF Schema is OIL (Ontology Interchange Language). A successor of OIL is DAML+OIL, jointly developed by a group of European and US scientists, gaining popularity in the field.

 Description Logics (DL) are often used to back ontology languages with the reasoning power.  For example,  a tool such as  OilEd   uses  DL reasoner for the analysis  of DAML+OIL ontologies.  DL  syntax based on a set of convention which allows describing the common semantic constructs without any use of variables. All DL constructs allow simple and elegant graphic representation.

2. Non Formal Introduction to GFL

As it was already mentioned Object Oriented paradigm of knowledge representation is different from relational paradigm. Numerous efforts have been  made to reconcile these two. One direction of these efforts is the development of object oriented extension for relational databases. Another direction is related to development of object -oriented logic programming systems. F-Logic is  perhaps the most  elegant theoretical result of the later work. F-Logic is a powerful logic programming system which   naturally  fits into  Object Oriented  paradigm.   GFL provides XML based and graphical representation for F-Logic constructs.  The availability of graphical and xml-based  representation of F-Logic statements in GFL make it  a perfect tool for developing ontologies. Here we will  simultaneously introduce the  basic concepts of F-Logic and GFL.

2.1 Why GFL?

GFL is intended to be a framework for specification of ontologies and Model Based Mediation of heterogeneous data sources.  Why not use a conventional  Description Logic based approach? In our opinion, DL have three major shortcomings: 1) they  use set theoretical semantic which is not as intuitive as Object Oriented Paradigm when we need to deal with constraints on object attributes; 2) native DL notations require set theoretical symbols which are not available in  ASCII set; 3)most important  shortcoming is that DL have extremely limited expressive power for queries.  GFL is designed as a remedy for these three problems. Unlike DL,  GFL supports arbitrarily complex queries. Although the introduction of the variables increases the complexity of the diagram language, this increase is not as significant as one may think of.

2.2 Is-a  Statements

Is-a statements describe class hierarchy and membership of object in various classes. There are two types of is-a statements. O:C means that object O is a member of the class C. You can read it as "O is a C". For example roel:organic_farmer means "roel is an organic farmer".   A::B means that class A is a subclass of class B. You can read A::B as "every A is a B". For example organic_farmer::farmer means that every organic_farmer is a farmer. The logical relation between these two types of statement is as follows:

if O:A and A::B then O:B

For example from two facts roel:organic_farmer and organic_farmer::farmer we may derive the fact roel:farmer. The relation " ::" is transitive. Transitive means that it is similar to the familiar relation of order between numbers. We know from arithmetic that for any three numbers a, b, c the following is true:

if a<b and b<c then a<c.

This property  of order relation "<" is called transitivity.  So now you can guess that for relation  "::" we can write it like this:

if A::B and B::C then A::B.

It is in fact very intuitive. Say if you have two facts  ecological_modeler::ecologist "every ecological modeler  is an ecologist" and ecologist ::scientist "every ecologist  is a scientist"   you can derive that  "every ecological modeler is a scientist",  that is ecological_modeler::scientist.

Here is the way how we shall represent the  two types of is-a statement  in a graphic form. The diagrams were generated with dot program, which is the  part of AT&T Graphviz package  . Each diagram is supplemented by the dot code,

roel:person	ecologist::scientist
dot-code	dot-code

In F-Logic, an object may belong simultaneously to a number of classes which do not have a common ancestor. This is another way to say that F-Logic supports multiple inheritance.

Here is an example pertained to Ecosystem Services Database. It is a small fragment of   ESD biogeochemical cycle model. 

nitrogen_compound::chemical_agent.
nitrogen[label->'N']:nitrogen_compound.
nitrogen_gas[label->'N2']:nitrogen_compound.
ammonia[label->'NH3']:nitrogen_compound.
ammonium[label->'NH4']:nitrogen_compound.
nitrous_oxide[label->'N2O']:nitrogen_compound.
nitric_oxide[label->'NO']:nitrogen_compound.
nitrogen_dioxide[label->'NO2']:nitrogen_compound.
nitrite_ion[label->'NO2-']:nitrogen_compound.
nitrate_ion[label->'NO3-']:nitrogen_compound.
 

dot-code

2.3 Statements about Object's   Attributes

F-Logic  supports two types of object attributes-those which can have only one value and those which can have many values. Here is an example of single valued attribute roels_bycile[color-->black]. Here is another example:  roel[wife-->tiny]. This statement represent the fact 'roel has wife tiny".  We shall use the following graphic representation for single valued attributes:

 dot-code

The example of multi-valued attribute is as follows:

roel[owns -->>{roels_bicycle, roels_farm, sachha, noosam}].

Here it is in the  graphic form:

dot-code

Multi-valued attributes will be always represented by edges with two arrows. It is possible to combine the information about object attributes and classes. The last statement supplemented with class information will look as follows:

roel:person[owns -->>{roels_bicycle:bicycle, roels_farm:farm, sachha:cat, noosam:dog}].

F-Logic allows to combine simple statement into complex ones with the help of logical connections AND, OR ,NOT. As it is common in logic programming languages, AND is denoted by simple comma ','. OR is denoted by a semicolon ';'. NOT is normally described as "not". It is also possible to combine information about several attributes of an object into one statement. The assertions about  different values of one multivalued attribute could be done in several places. The following three statements are equivalent

roel[owns -->>{roels_bicycle:bicycle, roels_farm:farm, sachha:cat, noosam}], roel[wife-->tiny].    (Note that  ',' stands for AND)

roel[wife-->tiny,  owns -->>{roels_bicycle:bicycle, roels_farm:farm, sachha:cat, noosam:dog}].

roel[wife-->tiny,  owns -->>{roels_bicycle:bicycle}],  roel[owns-->>{roels_farm:farm, sachha:cat, noosam:dog}]

Such complex statements are called F-Molecules, while simple statements are called F-Atoms. The graphic representation flattens the differences between these 3 cases:

dot-code

2.4 Class Signatures

2.5 Inheritance

F-logic distinguishes between attributes and methods that can inherit values from superclasses and those that do not. The syntax that we have seen so far applies to non-inheritable attributes only. Inheritable attributes are declared using the *=> and *=>> style arrows and are defined using the *-> and *->> style arrows. For instance, the following is a knowledge base describing  classical Royal Elephant example [taken from FLORA-2 Manual]:

The question is what is the color of clyde? clyde's color has not been defined in the above knowledge base. However, since clyde is an elephant and the default color for elephants is gray, clyde must be gray. Thus, we can derive:

clyde[color->gray].

Here is the graphical representation of the transformed knowledge base.

  dot-code

Here is a tip on how to work with inheritable attribute arrows. If you see an attribute arrow with '*' on the tail, this means you can always drag this arrow up through any isa:: arrow (UP means against direction of the isa:: arrow). If you have done so, it becomes a legitimate inheritable attribute arrow, and you can drag it further if there are other isa:: arrows around. You can also drag arrows with' *' tail up through isa: arrow, but in this case the resulting arrow will have no '*' at the tail. This is natural since inheritance works only on classes and not on the objects. 

Now, suppose we learn that

2.6 Variables and Queries

In F-Logic the queries are expressed with the help of free variables. There is a convention that variable name starts from a capital letter or underscore.

Here are examples of  simple query:

?-X:ecologist.  

This means: "Find all known instances of ecologist".

 In this notations  we want to preserve information about object/classes and attributes. We want to see from the graph weather variable stands for object/class or attribute:  In these notations we recognize variables by the question mark at the end of its name and green color. In the end we will have to stick to one of the alternatives and most likely we will stick to the green one.

Here is another example:

?-roel:ecologist.                                            

"Check if roel is an instance of class ecologist"

 Here is the query related to the value of an attribute. You can read it as "find all X which roel owns".

?-roel[owns->>X].

Here is a graphic representation of the same.

F-Logic allows to query the attributes;

?-roel[Attr->V]

This says "Find all single valued attributes Attr of object Roel along with their values V".

F-Logic allows to query the signatures:

?-personl[Attr=>C]

This says "Find all single valued attributes Attr specified for the class person along with the classes C of attribute contents". Here is the graphic form:

2.7 Queries with logical operators

The logical connection "and" denoted in F-Logic as  "," is default in our diagram language. If a query has only this type of connection  we will not show  "and" explicitly on the diagram, and keep single nodes for  the variables with the same name.

?-roel[owns-->>X],  tiny[owns-->>X].

"Find all those X which are owned by roel and tiny  both".

The queries of the former type are most common.  And they have fair and intuitive representation in GFL. Yet sometimes  (not too often indeed) we will need to make queries that have more complex logical structure. Here are the examples:

?-roel[owns-->>X]; tiny[owns-->>X].     (NOTE  - semicolon  ';' stands for OR)

"Find all those X which are owned either by tiny OR by roel". Here variable name X is used as a mean to connect two different parts of query. To show clearly  the tree structure of the query on the diagram we will use two distinct nodes for such variables. Although we will connect them with  dotted or yellow  line. Alternatively we may use a single node for all occurrences of the same variable.

?-roel[owns-->>X], not tiny[owns-->>X].

"Find all those X which are owned by roel but not owned by tiny ".

2.8 External Symbols and Foreign Ontology Languages Support

All GFL semantic constructs reflect respective F-Logic constructs. For instance the logical operators OR, AND, NOT introduced in previous section reflect respective operators in F-Logic and thus they are different from operations AND, OR, NOT encountered in ontology languages based on the Description Logic. In Description Logic  operator AND has set theoretical semantic and  denotes the intersection of two or more concepts. In DL the operation AND is applied to the concepts to fetch a concept with the denotation  set  equal  to the intersection of the denotation sets of the two concepts. Say the concept (ecologist AND modeler) would denote the set of instances which are ecologist and modeler at the same time. Operator OR fetch the union of denotation sets , and NOT fetch the set theoretical complement.

 GFL has elegant framework for graphic extensions (see section 4) which allows introducing new symbols with a complex meaning. This framework allows to introduce external operators which emulate AND, OR, NOT   operations of Description Logic.  In this section, we shall only illustrate the graphic representation and  describe the meaning of these symbols . Their precise semantics will be described in the section 5.2 (link). Since we have  already reserved AND, OR, NOT for native F-Logic constructs we shall use different names for respective Description logic operations. We shall use Intersect  for AND, Union for OR, and Complement for NOT, besides that we will use DUnion (Disjoint Union) for XOR. The introduction of Complement involves some additional requirements so we postpone it till the section 5.2. 

 Examples:

The following diagram define an ecomodeler as someone  who is both ecologist and modeler. Operator Intersection takes two concepts/classes as input and outputs the concept/class which contains all the instances that belong to both the input concepts/classes.

The following diagram define a commodity as something which is either  a good or service  . The Operator Union takes two concepts/classes as inputs and output the concept/class which contain all the instances that belong to at least one of those  input concepts/classes.

The following diagram suggests that all the organisms fall under one of the five categories: animalia, plantae, fungi,  protista, monera. The Operator DUnion takes two , three or more concepts/classes as input and outputs the concept/class containing all the instances belonging to at least one of those  classes. It also demands that there should be no intersection between the input concept/classes.

Modern ontology editors, such as OntoEdit from Ontoprise allow to convert DAML+OIL ontologies into F-Logic. During such conversion native Description Logic operations AND, OR, NOT find their expression in the form of rules. We must note however that conversion of  DAML+OIL or OWL ontologies is a complex problem which has not been discussed in literature so far.   The working paper by B. Grosof and I. Horrocks  . describes the conversion of DAML+OIL ontologies to RuleML and touches the tip of the iceberg.

3. Inference in F-Logic  and GFL

3.1 Rules

So far we have been considering mainly the structures for representation of knowledge. Yet in the section of inheritance we had one example of the derivation of new facts from existing facts. Inheritance of attribute values from a class to its subclass is the most common type of inference one can encounter in ontologies  application. However, there are many other types of inferences.  In our everyday experience we often relate different attributes of an object. For example if we know that X is the father of Y, we may conclude that Y is the son or the daughter of X.  

Consider the following knowledge base (adopted from ....):

henry:man
tim:man[father->henry].             
theo:man[father->henry].    
paul:man[father->tim].      
peter:man[father->tim].     
mike:man[father->theo].     
john:man[father->paul].     
jack:man[father->paul].     
cliff:man[father->peter].   
abe:man[father->mike]. 

This in some sense a patriarchal  family tree is built around the attribute  "father". Here is a graphical representation of the same knowledge base:

dot-code
    
A human looking at this picture can identify instances of  various family ties - sons, brothers, uncles, nephews, ancestors, descendants.  Is there any easier way to  to transferthis knowledge to computer program? For instance, can we declare a kind of general rule like " if X is a father of  a man Y then Y is a son of X ".   The answer is "yes". Logic programming in general and F-Logic specifically allows us to introduce such rules.  To declare the abovementioned rule F-logic employs the following notation:
F[son->>S]   :-  S:man[father->F].

The sign ':-'  stands for 'if'.  A rule "A:-B."  suggest that  "A is true when B is true"; alternatively you can read it as "A is true because B is true" . In this case A is called the head of rule and B is called the body of the rule.  Here head of the rule has label "define" . The body of the rule has label "conditions". Both are   outlined in  separate frames. Here is the graphic form of the father -son  rule:

Here is a slightly more complex rule that defines the attribute "brother".
X[brother->>Y]  :-   X[father->Z], Y:man[father->Z], not X=Y.

This rule suggests that Y is a brother of X if both have common father Z, and   X  is not the same as Y.

Here is the graphic form of the same rule:

The same with explicit logical connections

 
 Any assertion A can be true due to various reasons. Therefore, it is possible to have simultaneously  two or more rules of the form "A:-B.",   " A:-C".  Sometimes we need to intentionally combine the rules with the same head to achieve desired result. As an example consider the following recursive definition of the attribute ancestor.
X[ancestor->>Y] :- X[father->Y].
X[ancestor->>Y] :- X[ancestor->>Z[father->Y]].

The first rule suggests that Y is an ancestor of X if Y is the father of X. The second (recursive) rule suggests that Y is an ancestor of X if there is Z - ancestor of X, and Y is the father of Z. Here is the graphic form for these couple of rules:

We can load our knowledge base- all facts and  the rules into F-Logic engine such as Flora (if we use Flora we need to change "not" into "tnot"). Having done so we can query our knowledge base . Here are the examples of the queries:

Query 1: ?- F[son->>S].

F-Logic engine performs inference according to specified rules and outputs all the matches for the query which can be deduced from the given knowledge base.

See Output1

Query2: ?-X[brother->>Y].

See Output2.

?-X[ancestor->>Y].

See Output 3.

3.2  Method, Parameters, and  Relations.

In this section, we will consider methods pertained to the objects. In many OOP languages methods describe mainly the behavior of the objects. In context of F-Logic it is more convenient to think about methods as attributes with parameters. Our next example will deal with representation of meteorological data. Suppose we want to describe an average daily temperature and precipitation for some city. We shall use city Burlington as an example. The average daily temperature and precipitation in Burlington vary from month to month and therefore it is not appropriate to consider the  attributes "temperature" and "precipitation". The dependence of temperature on month could be described with the help of method "temperature(month)". Similarly precipitation will be described with the attribute precipitation(month). The following database represents average daily temperature in Fahrenheit and monthly precipitation in inches for Burlington averaged over last 30 years . (The source of these data is here).

KB1:

burlington[ temperature( jan)--> 18.0 ,  precipitation( jan )-->2.22  ].

burlington[ temperature(feb )-->  19.9,  precipitation( feb )-->1.67 ].

burlington[ temperature( mar)--> 30.7,  precipitation( mar )-->2.32 ].

burlington[ temperature( apr )-->  43.5, precipitation( apr )-->  2.88 ].

burlington[ temperature( may )--> 56.5, precipitation( may )--> 3.32 ].

burlington[ temperature( jun )-->  65.6 , precipitation( jun )--> 3.43 ].

burlington[ temperature( jul  )-->  70.6,  precipitation( jul  )--> 3.97 ].

burlington[ temperature(aug )--> 68.2,  precipitation( aug )--> 4.01 ].

burlington[ temperature( sep)--> 59.4,  precipitation( sep )--> 3.83 ].

burlington[ temperature( oct)-->  47.7 , precipitation( oct )--> 3.12  ].

burlington[ temperature( nov)-->  37.1, precipitation( nov )-->  3.06].

burlington[ temperature( dec)-->  24.8, precipitation( dec )--> 2.22 ].

burlington:city.

Here is the graphic representation of the first statement from this list. Note that the argument  "jan" is indicated by an arrows targeting towards the attributes temperature and precipitation. We shall call them argument arrows.

dot-code

In F-Logic, methods can have any number of arguments. In case of more than one argument we will indicate the order number of every argument by an integer after "arg" label.   As we have signatures  type specifications for the attributes we may have them for  the methods. The following are signatures for methods "temperature" and "precipitation".

city[ temperature(month)==>float].

city[ precipitation(month)==>float].

Here they are in a graphic form:

dot-code

 Often there are many ways to represent the same set of facts. For example we may consider Burlington as an object  which has temperature and precipitation depending on time. Alternatively we can think of states of Burlington at every time instance  as separate objects with attributes temperature and precipitation. Unlike many other OOP languages F-Logic allows to parameterize objects and classes. Here is alternative representation of the same knowledge base where we parameterize objects rather than their attributes.

KB2:

burlington( jan)[ temperature--> 18.0 , precipitation-->2.22  ].

burlington(feb )[ temperature-->  19.9, precipitation-->1.67 ].

burlington( mar)[ temperature--> 30.7, precipitation-->2.32 ].

burlington( apr)[ temperature-->  43.5, precipitation-->  2.88 ].

burlington( may)[ temperature-->  56.5, precipitation--> 3.32 ].

burlington(jun )[ temperature-->  65.6 , precipitation--> 3.43 ].

burlington(jul )[ temperature-->  70.6, precipitation-> 3.97 ].

burlington(aug )[ temperature--> 68.2, precipitation--> 4.01 ].

burlington( sep)[ temperature--> 59.4, precipitation--> 3.83 ].

burlington( oct)[ temperature-->  47.7 , precipitation--> 3.12  ].

burlington( nov)[ temperature-->  37.1, precipitation-->  3.06].

burlington( dec)[ temperature-->  24.8, precipitation--> 2.22 ].

Another peculiar feature of F-logic is the possibility of treating the objects as classes and classes as objects. Here is the place where this feature could be used- we can consider states of object burlington as members of one class burlington

burlington(Month):burlington.

Here is the graphic representation of the last and the first  statements from this knowledge base:

Note that we can not use the same box "burlington"   for objects burlington , burlington(jan), and burlington(Month). We need to use separate boxes to  clearly distinguish class/object burlington from   object  burlington(jan) in the diagram and also to   be able to draw isa-arrow burlington(Month):burlington. To make this picture more clear we may  put  the parameterized classes along with their arguments in boxes.

In some cases such arrangement however may require  the duplication of some nodes. Here are the signatures for KB2.

city(month)[ temperature==>float].

city(month)[ precipitation==>float].

Here they are in a graphic form:

dot-code

It is the most convenient to view large  homogeneous datasets like those above in the tabular form. Graphic representation of the methods we describe here is not intended as a framework for   representation of  large homogeneous datasets. Our notations can be  possibly used   for the representation of method definitions. We will demonstrate it by formulating the rules which allow to derive dataset of KB2 from that of KB1. The  similarity of the two knowledge bases is evident for a human eye . Here are the rules which would allow to obtain facts described in KB2 if facts  from KB1 are known.

burlington(Time)[ temperature->T ] :-  burlington[ temperature(Time)->T].

burlington(Time)[ precipitation->P] :-  burlington[ precipitation(Time)->P].

Worth to remind Time, P, T are variables in these rules. Here is the graphic form of these rules:

dot-code1   dot-code2

Note About Domains.  From Linear Algebra we know that numerical coordinates of vectors depend on frame of reference.  When we deal with discrete spatial and temporal data sets the actual format of data depends on grain and resolution. Spatial-temporal data can be transformed if frame of reference or grain/resolution are changed.   In IMT such  transformable objects are called domains. The possibility of alternative representation of the same data set along with possibility of obtaining one representation from another suggest that conceptual domain has certain similarity with space-time and can be also considered as a kind of domain.

3.3  Mathematical Expressions in the  rule body

F-Logic engines usually support arithmetical operations. Assume that in our meteorological example  we want to add the method which indicates the average daily temperature for Burlington  in Centigrade .  Here is an equation for recalculating the temperature:

centigrade = (fahrenheit - 32) * 5/9

We will add  method temperature_cent( float)   to object burlington and using the information about the temperature from KB1 we can obtain the value of the temperature in Centigrade with the help of the  rule below. Note that in in arithmetic equations in FLORA  (as  in  PROLOG) the operator  "is" is used  as sign of equality/assignement instead of "=" .
 
burlington[ temperature_cent( Time)--> TCentigrade]  :-     burlington[ temperature( Time)--> TFarenheit],    TCentigrade    is    (TFarenheit- 32)*5/9.

Here is the graphic form of this rule:

dot-code

Most often rules with arithmetic expressions require some attention to the order of the statements. All variables appearing in the arithmetic expressions  should be instantiated at the time of evaluation. This means that the values of such variables should be determined before the arithmetic expression is evaluated. For example consider the following:.

?- X>1, X is 1+1.  % this does not have sense, because X is not known in expression X>1.

?-X is 1+1, X>1. % this is evaluated as true. X is 1+1 will instantiate X to 2. Next 2>1 evaluated as true.

To facilitate the  right order of expressions we shall  introduce the  following convention: Green arrows connecting the variables indicate the flow of information , or the order of instantiation of the variables. All the variables that appeared in mathematical expression should have corresponding green arrow, originating from variables with the same name and pointing to the mathematical expression box. This will imply that these variables were instantiated before the evaluation of the mathematical expression.

3.4  Aggregation Statements

Some F-Logic engines such as FLORA and FLORID support aggregation operators. These operators compute values pertained to the set of variable instantiations that occur in certain query. It is good to illustrate that by an example. The first rule computes the yearly average of the   daily  temperature in Burlington:

burlington[ avg_yearly_temperature--> TAvg]  :- 

                                         TAvg=   avg{ T | burlington[ temperature( Month)--> T]}.

Here TAvg is the average value of all T which would occur in query ?-burlington[ temperature( Month)--> T].

Here is another  rule. It  computes the minimum    daily  temperature in Burlington during the year.:

burlington[ min__yearly_temperature --> TMin]  :- 

                                           TMin=   min{ T | burlington[ temperature( Month)--> T]}.

TMin is the minimum value of all T which would occur in query ?-burlington[ temperature( Month)--> T].

Besides avg and min other aggregation operators are supported by FLORA and FLORID. Here is the full list of those supported by FLORA : min, max, count, sum, avg, collectset, collectbag. All these  aggregation operators have similar graphic representation. Here is the graphic representation of the   first rule mentioned above .

dot-code

4. About Graphic Extensions

Graphic extensions are  new graphic symbols introduced as abbreviations for complex patterns .They allow  simplifying   the diagrams significantly, while preserving all the information accumulated in those diagrams.

4.1 A Stimulating  Example

Here we shall continue with the specifications pertained to  Nitrogen Cycle. In the previous sections  we already  have had some examples.    Now we will put them together and add new specifications- for organic and mineral nitrogen, plant uptake and mineralization. For time being we will treat plant uptake , mineralization, organic nitrogen , and mineral nitrogen as objects.

nitrogen_compound::chemical_agent.
nitrogen[label->'N']:nitrogen_compound.
nitrogen_gas[label->'N2']:nitrogen_compound.
ammonia[label->'NH3']:nitrogen_compound.
ammonium[label->'NH4']:nitrogen_compound.
nitrous_oxide[label->'N2O']:nitrogen_compound.
nitric_oxide[label->'NO']:nitrogen_compound.
nitrogen_dioxide[label->'NO2']:nitrogen_compound.
nitrite_ion[label->'NO2-']:nitrogen_compound.
nitrate_ion[label->'NO3-']:nitrogen_compound.

stock[agent*=>chemical_agent, ispartof*=>container, quantity*=>value].
flow[source*=>stock, target*=>stock, agent*=>chemical_agent, intensity*=>value].
distributed_stock::stock.
distributed_stock[ related_agents*=>>chemical_agent].
distributed_flow::flow.
distributed_flow[source*=>distributed_stock, target*=>distributed_stock].
container[stocks*=>>stock, distributed_stocks*=>>distributed_stock].
 

//the new things start from here

biota:container.
soil:container.
organic_nitrogen:distributed_stock.
organic_nitrogen[ispartof*->biota].
organic_nitrogen[agent*->nitrogen,related_agents*->>X:nitrogen_compound ]. 

mineral_nitrogen:distributed_stock.
mineral_nitrogen[ispartof*->soil]. 
mineral_nitrogen[agent*->nitrogen, related_agents*->>{ammonia, ammonium, nitrate_ion, nitrite_ion}]. 

mineralization:distributed_flow.
mineralization[source*->organic_nitrogen, target*->mineral_nitrogen].

plant_uptake:distributed_flow.
plant_uptake[source*->mineral_nitrogen, target*->organic_nitrogen].
 

The knowledge base we see is  far more complex than any other we saw so far. It is not surprising that its graphic representation is also complex. Here it is:

Alternative drawing of the same diagram

dot/neato code

As our diagrams grow larger their readability become increasingly difficult. The diagram above stays near the threshold of readability. We can ask a question: Is there any way to split the diagram into pieces and view different pieces separately? One general suggestion is that we can view separately the class signatures and the diagram which describe the instances of these classes. But then perhaps  there is no generic good answer on this question. The answer   entirely depends on the implementation of GFL.  Another question that can arise - is there any way to device abbreviations for the homogeneous parts of the diagram? And this question gives a key insight into our graphic extension philosophy.

 4.2 Graphic Extensions Philosophy

A  complex diagram may  comprise several instances of the same class.   The one in the example above has 9 instances of chemical_agent , 2 instances of distributed_stock, and 2 instances of distributed_flow. The large part of the diagram above is occupied by attributes "label" pertained to the instances of chemical_agent. And as a result the attributes that carry less significant,   trivial  knowledge consume the largest amount of the diagram space!  Can we device special symbols for such frequently encountered objects?  For example we may write the label of a chemical agent right after its name, separated by a column:

It is in generally good to have a clear mark on abbreviated symbols which would allow to quickly distinguish them from regular GFL symbols. For example we can paint a box for abbreviated chemical agents in blue color.   The main concern  however is that we should not loose the complete information pertained to the chemical agents. We should have a way back from our  abbreviations to the original notations. This could be resolved if we describe our abbreviations with the help of logical implications as follows:

These notations are similar to the F-Logic rules introduced in the previous sections and in fact they will be translated into some sort of rules (see notes on implementation). However in this case the implication goes in both directions. The symbol defined in the graphic rule implies the set of  conditions (meaning). At the same time those conditions that match the meaning of the symbol imply the possibility of using this symbol. Another important distinction- our rule is associated with instances of some class, in this case chemical_agent. The only one instance of this class is the subject of our definition. The new symbol introduced is related to this instance. The graphic definition suggests that any instance of certain class may have the  specified graphic representation. We may also introduce rules for signatures of subclasses and for the attributes. Yet in all the cases    the object oriented features of our language will provide a vehicle for the systematic graphic definitions. We will consider our graphic rules as legends. In fact they can serve as legends in complex diagrams. Yet another distinction- although we draw all variables boxes  in green color, this convention is applied only to the meaning part of the rule. It is necessary as long as we wish to use different colors for the newly introduced symbols.

An abbreviation for an object of some class does not  necessary wrap all the features (attributes, isa arrows) pertained to the class. But all the features (read " all arrows") related to original version of a symbol could also be attributed to the abbreviated version. The following principle articulates this idea:

Principle of substitution

Any arrow which originates or terminates at non -abbreviated version of a symbol, which is not included into meaning of the (new abbreviated) symbol can be used with the new symbol exactly in the same way as it is used with original symbol.

For instance if we have arrow:

We can   draw the same arrow for the abbreviated symbol:

 It is important to note that the new symbol introduced in the define symbol part of the diagram is related to the only one instance of the class mentioned in the legend. Here are the legends for distributed_stock  and in this case we define abbreviation for instances of distributed_stock.

In fact, the definition of a symbol for one class instance introduced several graphic conventions at once. First it suggest that distributed stocks will be represented by red boxes with double border. Second,  it   describes the relation between a distributed_stock and the container it belongs to. We wish to denote the container as a box which contains related instances of distributed stocks (and   stocks). Third, the blue arrow with doted arrowhead represents related_ agents attribute. Thus a graphic definition creates a kind of abbreviation for a possibly large pattern of the diagram.

We would achieve a better clarity if we separate signatures from the instances which are represented by variables in symbol definition. Here is the legend for distributed_flow which uses this idea:

In the large nitrogen cycle diagram the signatures for distributed stock and distributed flow were related only to the instances of these objects. Therefore when we mentioned the entire signatures in the legends there is no further need to show them in the diagram which describe the instances of these classes. Now the entire map from the previous section will be represented as follows:

Legends:   chemical_agent        districbuted_stock        distributed_flow

 This map contain exactly the same information as the one in previous section. (A few chemical agents not related to the other elements of the diagram were omitted intentionally). In fact it can be translated back to that format. Yet it has discernable  advantage of clarity and readability. These advantages will increase as we add more instances of distributed_ flow and distributed_stock to the main diagram  ,which we will certainly need to do as we move to the real biogeochemical cycles models.

At the bottom of the diagram there are links to the legends. Alternatively, such links can be attached to the symbols on the diagram , so that while clicking on unfamiliar symbol user can retrieve its meaning.  We can envisage structure of such maps. We may think of graphic symbols defined in terms of non standard graphic symbols, i.e. those symbols which have their own graphic definition.

4.3 Family Tree Example

We shall continue examples of graphic vocabularies . In this section, we shall consider simple graphic  vocabularies based merely on color coding. Here is a description of a family tree. It includes both sexes and thus it is a bit more realistic comparing to our previous family tree example.

henry:man.

susan:woman.

tim:man[father->henry, mother->susan].             
theo:man[father->henry, mother->susan].  

julia:woman.  
mary:woman[father->tim, mother->julia].      
peter:man[father->tim,  mother->julia].   

kate:woman.  
mike:man[father->theo, mother->kate]. 

mary:woman.    
john:man[father->james, mother->mary].     
jack:man[father->james, mother->mary]. 

sophia:woman.    
cleo:woman[father->peter, mother->sophia].   

rosa:woman.
diana:woman[father->mike, mother->rosa]. 

Here is the graphic representation of our family knowledge base.

Although it is readable , it is not as vivid as customary drawn family trees in history textbooks. We may decide to represent all man by blue boxes and all woman by red boxes. Then we may represent relation mother by red arrows drawn from mother of a person to this person. Similarly we may represent relation father by blue arrows drawn from father of a person to this person.

Here is the transformed view of our knowledge base.

Introducing new graphic symbols for instances of man, woman, and attributes father, and mother we have achieved a lot in terms of clarity and readability. In fact we have transformed our family knowledge base to a shape which may resemble real representations of family tree  in history books. Yet this representation has precise computational semantic. It can be converted back to the basic GFL .

4.4   Semantics of Biodiversity Data 

Taxonomy of living being made by Carolus Linnaeus is known for a couple of centuries. Although it is clear and unambiguous for biologist , an attempt  to formalize it reveal certain  ambiguities which  arise exclusively on account of the formal languages we use. In this section  we will argue that certain peculiar properties of F-Logic , such as meta-classes may be essential for the representation of Linnaean  taxonomy. In this section will we will describe a simple example of food web and the taxonomy of related species just to illustrate the   problems pertained to semantics of biodiversity data. In the subsequent section this data will be extensively used for the  illustration of domain browsing philosophy.

Consider a fragment of  food web of Illinois Wetland:

Here are the details about the species that constitute the food -web.

Earthworm='Lumbricus terrestris '

'Spotted Salamander'='Ambystoma maculatum'

Mosquito='Aedes aegypti'

The categories kingdom, phylum, class, order, family , etc are well known to biologists. However their semantic role is ambiguous. They have at least two types of semantic representation. Consider them separately:

 1. All the italics word in the table above are classes. The Linnaean taxonomy is merely a hierarchy of classes. Yet each class has a certain type on its own which describes the level of this class in the whole hierarchy. For example animalia, plantae, protista, monera, fungi are 5 classes on the top of hierarchy. They describe the Kingdom where a   particular organism belongs. The classes Anneliada, Chordata, Athropoda, etc belongs  to the second level of the hierarchy. The whole second level is called Phylum.  This is how the taxonomy is arranged:

                                 Kingdom
                        /-----------|-------------\
                 Phylum                                   Phylum
             /                 \                             /             \
         Class              Class               Class            Class
       /       \                  /    \                /       \            /       \
    Order Order     Order   Order   Order Order  Order  Order
   

Now we can suggest that words kingdom, phylum, class, order, family , etc represent metaclasses for those classes which are written in italics in the table above. For example animalia, plantae, protista, monera, fungi are the 5 instances of the class kingdom. We can treat them as objects and we can write:

animalia:kingdom.

plantae:kingdom.

 protista:kingdom.

monera:kingdom.

fungi:kingdom.

At  the same time animalia, plantae, protista, monera, fungi are classes and they have their own subclasses. For example we can write:

vertebrata::chordata::animalia.

Here is the right time to explain why in our graphic formalism we used boxes for both objects and classes. If we dealt with the language other then F-Logic  it would be appropriate to device different graphic symbols for classes and their instances, because in most of the languages classes can not be treated as objects. Yet in F-Logic any class can be also treated as an object which can be an instance of some metaclass. The possibility to treat classes as objects may seem to be unnatural to a programmer. But our  example of Linnaean taxonomy illustrates that in  scientific taxonomies we often do treat classes as objects! And  if we expect ontologies to be faithful representation of real taxonomies the last remark makes a strong case for using F-Logic as an ontology language.

2. Here is the second semantic role for categories kingdom, phylum, class, order, family , etc. They can be considered as attributes (roles or binary relations if we like to express the ideas in FOL or Description Logics). Say in F-Logic/GFL we may describe an earthworm as follows:

If we use description logic we have to describe kingdom, phylum, class, order, family , etc as roles or binary relations which will be equivalent to the representation of these categories as attributes. And if we use description logic this would be the only representation, since description logic does not allow using classes as objects! F-Logic would allow to consider both the  representations at the same time and the two representations may be related. Now, after going through the issues we shall discuss the systematic F-logic  representation of the data pertained to our food web example.

 We start from representation of isa arrows. The semantic for attributes such as kingdom, phylum, class, order, family , etc is derived from the information provided by isa arrows. Here is the set of facts which represent the class hierarchies related to our example of food web of Illinois Wetland. Compare the following  with the table above. Our set of facts  starts from description description of vertebrata subphylum. The first fact specifies the sub tree which is common for all the vertebrata species.

'Vertebrata'::'Chordata'::'Animalia'.

'Ambystoma maculatum'::'Ambystoma'::'Urodela'::'Amphibia'::'Vertebrata'.

'Rana pipiens'::'Rana'::'Ranidae'::'Anura'::'Amphibia'::'Vertebrata'.

'Casmerodius albus'::'Casmerodius'::'Ardeidae'::'Herodiones'::'Aves'::'Vertebrata'.

'Lepomis macrochirus'::'Lepomis'::'Centrachidae'::'Perciformes'::'Osteichthyes'::'Vertebrata'.

'Blarina brevicauda'::'Blarina'::'Soricidae'::'Insectivora'::'Mammalia'::'Vertebrata'.

'Nerodia sipedon'::'Colubridiae'::'Squamata'::'Reptilia'::'Vertebrata'.

'Lumbricus terrestris' ::'Lumbricus'::'Lumbricidae'::'Opisthopora'::'Oligochaeta'::'Annelida'::'Animalia'.

'Aedes aegypti'::'Aedes'::'Culicidae'::'Diptera'::'Insecta'::'Arthropoda'::'Animalia'.

'Typha latifolia'::'Typha'::'Typhaceae'::'Typhales'::'Liliopsida'::'Magnoliophyta'::'Plantae'.

The following assertion would allow to use common name as synonym with species name:

earthworm='Lumbricus terrestris '

'spotted salamander'='Ambystoma maculatum'

mosquito='Aedes aegypti'

..........

Here are the facts that specify the meaning of  the metaclasses kingdom, phylum, class, order, family , etc. 

'Animalia':kingdom.

'Plantae':kingdom.

'Annelida':phylum.

'Chordata':phylum.

'Magnoliophyta':division.

'Vertebrata':subphylum.

'Oligochaeta':class.

'Amphibia':class.

'Insecta':class.

'Amphibia':class.

..............

...............

'Typha latifolia':species.

'Nerodia sipedon':species.

There are two ways of describing the respective attributes kingdom, phylum, class, order, family , etc. In the first case we may derive them with the help of  the following rules:

X[kingdom*->King] :- King:kingdom, X::King.

X[phylum-*>Phyl] :- Phyl:phylum, X::Phyl.

X[class-*>Class] :- Class:class, X::Class.

....................

........................

Alternatively we can describe attributes kingdom, phylum, class, order, family , etc. with the help of  the following facts:

'Animalia'[kingdom*->Animalia'].

'Plantae'[kingdom*->'Plantae'].

'Annelida'[phylum*->'Annelida'].

'Chordata'[phylum*->'Chordata']

'Magnoliophyta'[division*->'Magnoliophyta'].

'Vertebrata'[subphylum*->'Vertebrata'   ].

'Oligochaeta'[class*->'Oligochaeta'   ].

'Amphibia'[class*-> 'Amphibia'  ].

'Insecta'[class*-> Insecta'  ].

'Amphibia'[class *->Amphibia'   ].

..............

...............

cattails[species*->'Typha latifolia'].

water_snake[species*->'Nerodia sipedon'].

The inheritable character of attribute kingdom in specification 'Animalia'[kingdom*->Animalia']  ensures that it will be inherited by all subclasses derived from the class  Animalia'. It will be inherited for example by 'Vertebrata', 'Chordata', Ambystoma maculatum', 'Ambystoma',  'Urodela', 'Amphibia', etc.

And finally here is the description of feeding relations, i.e. those relations which form food-web

'spotted salamander'[eats*->>{ mosquito, frog , ' blue gull fish}].       //salamander eats mosquito, frog ,and blue gull fish

frog[eats*->>{mosquito , 'spotted salamander'  }].                                            //frog eats mosquito, salamander

 .................

.................

With  the experience we already have we may anticipate that if we draw the whole diagram which describes the complete knowledge base of this section, this diagram will be too complex and hardly readable. Therefore we will not draw it. The knowledge base developed in this section will be used as the example in the next section.

4.5 Ontology Browsing Philosophy

In this section we will continue discussing graphic vocabularies and the problem of browsing of the knowledge bases. Yet the main goals of this section is to introduce domain views.  As an ontology or domain model become large it becomes increasingly difficult to browse it. The domain views provide a technique to elicit tractable and meaningful portions of the ontology. We shall introduce 3 types of views -relation views, object views , and query views. Let us consider them in sequence.

Relation Views

An ontology can be considered as a set of nodes and  relations represented by arrows. Typically we have such relations as  isa:, isa::, attributes, signatures. We can essentially simplify the view of ontology if we depict only one or two types of relations hiding all other. For example in context of example from previous section, if we focus on isa:: relations we shall view only the class hierarchy -the Linnaean  taxonomy pertained to our ecosystem.  If we focus on relation eats, living aside all other , we shall see only the food web. Here is the typical relation view. To increase the readability we may use graphic vocabularies along with the views. The following example illustrates that  conventional food web picture may be obtained with the help of relation view.

To specify a relation view user has to select the names of relations s/he wishes to view, and   choose if s/he wishes to consider signatures, exclude them, or view only signatures and also choose if predefined graphic symbols for relations should be used.  Thus specification of a relation view can be accomplished with merely two groups of radio buttons and one text area or list box with enabled option for multiple choices.

Object Views

Sometimes a user may be interested to view relations pertained to a specific object be it class or instance. Object views  of depth one depict only the object and those related to it via any relations. Object view of depth N built via recursive procedure which constructs  an object view of depth one for the given object and then takes  every object from this view and constructs an object view of depth N-1 for each. Here is an example of object view:

To specify an object view user must specify an object and  the depth. Object can be specified via typing its name into a textbox or by a mouse click. It is possible also to distinguish between bidirectional and unidirectional object views. The latter will depict only the attributes and values of the given object, while former will depict also those objects which have the given object as a value of their attributes.

Query views

The query view outputs all objects and relation generated by a query . This type of views is the most powerful. The effect of two previous view types may be also achieved via query vies. Here is the example:

Although query view provides an ultimate power of ontology browsing it would require a mechanism for specification of the queries. This mechanism may not be really as simple as the ones needed to specify relation and object views.

5. Constrains

5.1 Rules and Structural Constrains

Besides class hierarchies and class signatures  ontologies often require to specify certain constrain on the elements. For example in our biogeochemical cycles ontology we have stocks and flows. Both   of them have attribute agent that indicates the chemical agent stocked or transferred. An instance of flow object is connected to two instances of stock -its source and target. In accordance with our common sense we would require that in this case the flow instance should have the same agent attribute as its source and target. Say flow of nitrogen is always connected to two stocks of nitrogen. Yet this obvious requirement does not follow from our signatures for stock and flow class. The requirement of this kind are called constrains  and   we have to specify it  separately using rules. The rules for constrain would allow to find out if some constrain is violated in some ontology.

One way of specifying constrain rules is to introduce special inconsistency class ic (this idea initially  was proposed by Ludasher et. all). The inconsistency class ic is a set of various objects possibly with arguments which report violation of various constrains. The constrain rules designed by such a way that a simple query ?-X:ic. - retrieving all the instances all class ic would report all constrain violations. For example to report the fact that a flow instance Fl and its source S have different agent attribute we will introduce parameterized object

fw('wrong chemical agent in source' , Fl, S)

Now, the following rules will create real instances of this object, binding variables Fl and S to those instances of stock and flow where flow agent is not that same as agent of its source:

fw('wrong chemical agent in source' , Fl,S):ic:-
            Fl::flow[source*->S, agent*->A1], S[agent*->A2],  not A1 = A2.

Similar rule would report the violation of the constrain that  suggests that flow and its target should have the same chemical agent:

fw('wrong chemical agent  in target' , Fl,T):ic:-
            Fl::flow[target*->T, agent*->A1], T[agent*->A2],  not A1 = A2.
           
                 
To describe   constrains in GFL we may simply describe the rules which represent the constrains. For example the following is the representation of the first rule:

The representation constrain in form of rules is the most flexible method . It allows to tackle a wide range of the constrain types. Yet we have to pay a price for this flexibility- the diagrams that represent rules are normally not simple. In certain cases, we can introduce special graphic symbols that indicate specific types of constraints. This would increase the readability of our diagrams. In the next section we shall consider the operators which are frequently encountered in various ontology languages. They often are defined with the help of constrain rules.

5. 2 Operators and Generic Graphic Extensions 

This is the most technical part of the tutorial . In this section we shall demonstrate the use of constrain and graphic extensions for  extending GFL with new operators. Such new operators may for example emulate some operators of DAML+OIl ontology language. It is worth to note however, the systematic conversion of DAML+OIL ontologies to any logic programming framework is a complex problem , that will probably bring forth a number of papers in the future. At present the only paper that deals with this problem is  working paper by B. Grosof and I Horrocks  .

Intersection is the least difficult operator to deal with. It allows exact translation from set theoretical to Logic programming semantic. There are possibly different ways of defining the intersection of concepts. Consider our previous example- ecomodeler which is Intersection of  ecologist  and  modeler.

This statement is equivalent to the set of 3 rules:

X:ecomodeler:- X:ecologist, X:modeler.

X:modeler:- X:ecomodeler.

X:ecologist:-X:ecomodeler.

Note we can use the same variable X in all the three rules. It is because in logic programming variable name has meaning only inside the rule. Alternatively it can be translated into one fact and 3 generic rules.

intersection(ecomodeler, ecologist, modeler).

X:Int:-intersection(Int, C1, C2), X:C1, X:C2.

X:C1:-intersection(Int, C1, _),X:Int.

X:C1:-intersection(Int, _, C1),X:Int.

We will use the first set of rules to define intersection operator. Here is how definition looks.

The green arrows  suggest that variable symbols in meaning part of the diagram should exactly correspond to the  names in operator part .Note, only variable X in the diagram is a real logical variable. The symbols C1, C2,  Cinter denote arbitrary classes. But they are not logical variables (so we do not use question mark after their name. The definition of the operator Intersection suggest that each occurrence of such operator  should be accompanied by insertion of 3 rules into the database. During this insertion variables C1, C2,  Cinter substituted by the respective concepts from left hand side of the diagram. Variable X is logical variable and is inserted as is. We can frealy use the same variable X in all the three rules , or we can use other names. IIn F-Logic   variable name is local for the rule.

Operation Union is more difficult one since it does not allow exact translation from set theoretical to logic programming framework  However we can emulate set theoretical semantic using negation as failure and integrity constrains. (although it will not always work precisely as a set theoretical union). Again there are different ways of defining Union. For example  the following set of rules suggest that the concept commodity  is a union of concepts good  and   service .

X:comodity:-X:good; X:service.

wu('the result is larger then union of the operands' , comodity, good, service):ic:-   X:comodity, tnot (X:good; X:service) 

Alternatively the same  logical construction may be defined as follows.

union(comodity, good, service). %ensure different variables names

X:ConceptU:-union(U,Concept1,C2), (X:Concept1;X:C2).

wu('the result is larger then union of the operands' , U, Concept1, Concept2):ic:- union(ConceptU,Concept1,Concept2),  X:ConceptU, tnot (X:Concept1; X:Concept2) 

Now we will use the first set of rules to define the symbol Union

The definition of  Disjoint Union of many variables is far more complex task. For example the assertion that concept  organism  is a disjoint union of concepts animalia, plantae ,fungi,  protista ,monera may be expressed as the following set of rules:

organism:dunion[members->>{animalia ,plantae, fungi,  protista, monera}].

X:DU:-DU:dunion[members->>C], X:C.

wu('the result is larger then union of the operands'  , DU):ic:- DU:dunion, X:DU, not (DU[member->C],   X:C).

wd('union is not disjoint', C1, C2):ic:-X:dunion[members->>C1], X[members->>C2], Y:C1, Y:C2.

We shall live it as an exercise to draw the graphic definition of DUnion operator.

We can use external symbols to enrich our graphic formalism. For example we may introduce symbol near the attribute name which will indicate that the attribute is transitive. We can use label inv near attributes to identify  the inverse attribute

NOTES ON IMPLEMENTATION

The implementation of GFL without the graphic extension would be merely a straightforward mapping of F-Logic database into the language of appropriate diagram drawing tool , such as Graphwiz. The implementation of graphic extension require to keep track of the newly introduced symbols and corresponding rules. Thus it requirea a full fledged language for diagram specification. There are at least three ways how this can be accomplished.

1. Use XML for description of F_logic database and graphic specification. A markup language for F-Logic (FLML ) may be used to specify the facts and rules. An XML  wrapper for graphwiz language (say GraphwizML) may specify the diagram. And besides the special XML language would need to track  the correspondence between external graphic symbols specified  in GraphwizML and their  definition in FLML.

2.  F-logic database, diagram specification language and the correspondence between two may be specified in F-logic

3. Any combination of the two approaches above.

C 2003 S. Krivov  Send your comments to skrivov@zoo.uvm.edu