As a hybrid language Telos supports three different representation formats: a logical, a graphical (semantic network) and a frame representation. The two latter formats are based on the logical one. As explained in the next subsections the logical representation also forms the base for integrating a predicative assertion language for deductive rules, queries, and integrity constraints into the frame representation. We start with the logical so called proposition representation of a Telos knowledge base.
A Telos knowledge base is a finite set of interrelated propositions (=objects):
where oid has key property within the knowledge base, ID is a non-empty set of identifiers with a non-empty subset LABEL of names. The components oid, x, l, y, tt are called identifier, source, label (or name), destination and belief time of the proposition. We read them as follows:
The object x has a relationship called l to the object y. This relationship is believed by the system for the time tt.As shown below there is a natural interpretation of a set of propositions as a directed graph (semantic network). We distinguish four patterns of propositions and give them the following names:
P(oid,oid,l,oid,tt)
P(oid,x,*instanceof,y,tt)
P(oid,x,*isa,y,tt) and
Telos imposes some structural axioms on knowledge bases, e.g. referential integrity, correct instantiation and inheritance ([JEUS92]). They are linked to predefined classes that are automatically part of each Telos KB:
Additionally, there are the builtin-classes Integer, Real and String.
Integer and real numbers are written in the usual way, strings are
character sequences, e.g. "this is a string".
As a user, you don't work directly with propositions but with textual (frame) and graphical (semantic networks) views on them. Both are not based on the oid's of objects but on their label components. To guarantee a unique mapping we need the following naming axiom:
Naming axiom
The label (``name'') of an individual object must be unique. The label of an attribute must be unique within all attributes with a common source object.
The frame syntax of Telos groups the labels of propositions with common source o around the label of o. The exact syntax is given in appendix A. In this section we introduce it by modeling the employee example:
Individual Employee in Class,SimpleClass with
attribute
name: String;
salary: Integer;
dept: Department;
boss: Manager
end
Individual Manager in Class,SimpleClass isA Employee end
Individual Department in Class,SimpleClass with
attribute
head: Manager
end
The label of the ``common source'' in the first frame is Employee. It is declared as instance of the classes Individual,Class and SimpleClass and has four attributes. The class CFT is a subclass of Employee.
Oid's (preceded by `#' in our examples) are generated by the system. This leads to the following set of propositions corresponding to the frames above. The belief time inserted by the system is denoted by omission marks.
P(#E,#E,Employee,#E,...) P(#1,#E,*instanceof,#Class,...) P(#2,#E,*instanceof,#SimpleClass,...) P(#3,#E,name,#String,...) P(#4,#E,salary,#Integer,...) P(#5,#E,dept,#D,...) P(#6,#E,boss,#M,...) P(#M,#M,Manager,#M,...) P(#7,#M,*instanceof,#Class,...) P(#8,#M,*isa,#E,...) P(#D,#D,Department,#D,...) P(#9,#D,*instanceof,#Class,...) P(#10,#D,head,#M,...)
Instantiation to the class Individual is implicitly given by the structure of the three individual propositions named Employee, Manager, and Department. Analogously, the attributes #3, #4, #5, #6 and #10 are automatically regarded as instances of the class Attribute. The propositions #1, #2, #7 and #9 are instances of the class InstanceOf, and #8 is an instance of the class IsA. Note that all relationships are declared by using the identifiers (not the names) of objects. Thus, #Class, denotes the identifier of the object Class etc.
The identifiers are maintained internally by ConceptBase's object store. Externally, the user refers to objects by their name. A standard way to describe objects together with their classes, subclasses, and attributes is the frame syntax. Frames are uniformly based on object names.
The next frames establish two departments labelled PR and RD and state that the individual object mary is an instance of the class Manager. Mary has four attributes labelled hername, earns, advises and currentdept which are instances of the respective attribute classes of Employee with labels name, salary and dept.
Individual mary in Manager,Token with
name
hername: "mary Smith"
salary
earns: 15000
dept
advises:PR;
currentdept:RD
end
Individual PR in Department,Token end
Individual RD in Department,Token end
The corresponding propositions for the frame describing mary are:
P(#mary,#mary,mary,#mary,...) P(#E1,#mary,*instanceof,#M,...) P(#E2,#mary,*instanceof,#Token,...) P(#E3,#mary,hername,"Mary Smith",...) P(#E4,#E3,*instanceof,#3,...) P(#E5,#mary,earns,15000,...) P(#E6,#E5,*instanceof,#4,...) P(#E7,#mary,advises,#PR,...) P(#E8,#E7,*instanceof,#5,...) P(#E10,#mary,currentdept,#RD,...) P(#E11,#E10,*instanceof,#5,...)
The attribute categories name, salary and dept must be defined in one of the classes of mary. In this case mary is also instance of Employee due to the following axiom which defines the inheritance of class membership in Telos, and hence can instantiate these attributes:
Specialization axiom
The destination (``superclass'') of a specialization inherits all instances of its source (``subclass'').
An example is the specialization #8: all instances of Manager (including mary are also instances of Employee. Telos enforces typing of the attribute values by the following general axiom:
Instantiation axiom
If p is a proposition that is instance of a proposition P then the source of p must be an instance of the source of P, and the destination of p must be an instance of the destination of P.
For example, ``Mary Smith'' must be an instance of String. The individual mary also shows another feature: attribute classes specified at the class level do not need to be instantiated at the instance level. This is the case for the boss attribute of Employee. On the other hand, they may be instantiated more than once as e.g. dept.
In some cases for attribute categories occuring in a frame the
corresponding objects which are instantiated by the concrete attributes,
can not uniquely be determined
. This his multiple generalization/instantiation
problem is solved by the following condition which must hold for
Telos knowledge bases:
Multiple generalization/instantiation axiom
If p1 and p2 are attributes of two classes c1 and c2 which have the same label component l, and i is a common instance of c1 and c2 which has an attribute with category l, then there must exist a common specialization c3 of c1 and c2 with an l labelled attribute p3 which specializes p1 and p2, and i is instance of c3. Particularly if c1 is specialization of c2 and p1 is specialization of p2, c1 and p2 already fulfill the conditions for c3 and p3.
Telos treats all three kinds of relationships (attribute, isa, in) as
objects. Thus each attribute, instantiation or generalization link of
Employee may have its own attributes and instances. For example, each of
the four Employee attributes is an instance of an attribute class denoted by the label
attribute but can also have instances of its own. The attribute with
label earns of mary is an instance of attribute salary of class
Employee. Syntactically, attribute objects are denoted by appending
the attribute label with an exclamation mark to the name of some
individual. The relationship between salary and earns could be
expressed as
Attribute mary!earns in Employee!salary end
Instantiation links are denoted by ''->'' and specialization links by ''=>'':
InstanceOf mary->Manager end IsA Manager=>Employee end
The operators can be combined to complex exppressions. The following example shows how to reference the instantiantion link between the attribute mary!earns and its attribute class Employee!salary. The second frame shows that arbitrarily complex expressions are possible. The parantheses have to be used to make the operator expressions unique. Though such complex expressions are rare in modeling, it is good to know that any object in O-Telos can be uniquely referenced in the frame syntax.
InstanceOf (mary!earns)->(Employee!salary) with
comment
com1: "This is a comment to an instantiation link between attributes"
end
Attribute ((mary!earns)->(Employee!salary))!com1 with
comment
com2: "This is a comment to the the previous comment attribute"
end
Fig. 2.1 shows as the second view on propostions the graphical semantic network representation of mary and her relationships to the other example objects.
Figure 2.1: Graph representing the example proposition network
Individual objects are denoted as nodes of the graph, instantiation, specialization, and attribute relationships are represented as dotted, shaded, and labelled directed arcs between their source and destination components.
Telos propositions have a temporal component: the belief time. The belief time of a proposition is not assigned by the user but by the system at transaction time of an update (TELL or UNTELL). ConceptBase uses right-open and closed predefined time intervals. Example:
P(#mary,#mary,mary,#mary,tt(second(1992,1,11,17,5,42)))
The object mary is believed since 17:05:42 on January 11, 1992. Right-open belief times indicate objects that are part of the ``current'' knowledge base and closed intervals (denoted by binary tt-terms) indicate ``historical'' objects. Example:
P(#E1,#mary,*instanceof,#M,tt(second(1992,1,11,17,5,42),year(1995)))
The object #E1, i.e. the instantiation of mary to the class Manager is believed from 17:05:42 on January 11, 1992, until the end of year 1995.