dot-codeF-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]:
elephant[color*=>color].
royal_elephant::elephant.
clyde:royal_elephant.
elephant[color*->gray].
gray:color.
Here is the graphical representation of this knowledge base:
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.
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
royal_elephant[color*->white].
Although we have previously established that clyde is gray, this new information renders our earlier conclusion invalid. Indeed, Since clyde is a royal elephant, he must be white, while being an elephant he must be gray. The conventional wisdom in object-oriented languages, however, is that inheritance from more specific classes must take precedence. Thus, we must withdraw our earlier conclusion that clyde is gray and infer that he is white: clyde[color->white]. Thus here is one more rule on diagram transformation. You can not drag the tail of inheritable attribute arrow to the node where already there is a tail of the same attribute. This is the example of so-called non-monotonic inference. Non-monotonic behavior naturally emerges in Object -Oriented paradigm.Here is an example pertained to Ecosystem services Database. It contains the definitions for stock and flow, used in description of biogeochemical cycles. Chemical elements such as nitrogen form complex compound. When ecologists talk about a stock of nitrogen they encounter as pure nitrogen as the nitrogen contained in the nitrogen compounds. The concepts of distributed stock and distributed flow intend to capture this idea.
stock[agent*=>chemical_agent, ispartof*=>container,
quantity*=>value].
flow[source*=>stock, target*=>stock, agent*=>chemical_agent, intensity*=>value].
This image was created with neato, see dot/neato-code
C 2003 S. Krivov Send your comments to skrivov@zoo.uvm.edu
