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