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.
C 2003 S. Krivov Send your comments to skrivov@zoo.uvm.edu