<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
I have made a few changes since I last posted. The multi-path
graph traversal remains the same, but I have decided that classes do
not make great related item selectors. I have tried to index
primarily on related item class, but that has performance problems when
you allow for class inheritance, because you have to either do a
dynamic class test of each related item, or check your related item
index for members of each sub class of the original class.<br>
<br>
The standard way to find related items is with named attributes. In
traditional data modelling a named attribute can only have one value.
If you need more than one value, you must normalize out a separate
entity. This makes life really easy for compilers and the like, but is
really quite an artificial distinction - after all what is the semantic
difference between a in-line attribute set to a value and a child table
with only one related entry?<br>
<br>
Partly due to a serious weakness for premature optimization (the 'root
of all evil' according to Donald Knuth), and partly due to the desire
to maintain inline C++ class compatibility, I have avoided the whole
concept of named attributes in favor of Prolog style relationship class
based access. I have decided that in the general case, this is a
mistake. <br>
<br>
Named attribute access is much easier to conceptualize and specify.
Given transparent support for multi-valued attributes and object role
aliasing, it should be more than flexible enough for a general
knowledge model. Named attribute access is not sufficient for all
queries - but it is considerably faster for most of them, not to
mention more susceptible to special case optimizations.<br>
<br>
The classic problem with named attributes is name / semantic clashes in
entities with multiple inheritance. For example, let's say I want to
know an employee's start date. Aside from particular knowledge of a
system's naming convention, how can I be sure that I don't actually
return the employee's birth date, which after all is a the start date
of a person's tenure on the earth? In the case of C++ there are name
resolution conventions for multiple inheritance that specify which
value will be returned in the case of a name clash.<br>
<br>
In a more general knowledge meta model, this is a serious issue,
especially if you have automatic role aliasing such that an Employee
can be treated as a Person without inheriting from the Person class in
a way that keeps the same person from being an employee multiple times
over.<br>
<br>
In my prototype data modelling language, I might declare some classes
like this:<br>
<br>
class Person<br>
{<br>
};<br>
<br>
class Employee : alias Person<br>
{<br>
employer : Employer { partner set employees; };<br>
start_date: date;<br>
end_date : date;<br>
};<br>
<br>
class Employer<br>
{<br>
employees : Employee { partner set employer; };<br>
};<br>
<br>
<br>
Notice the partner set declarations - they allow the system to maintain
referential integrity between the set of each employer's employees and
each employee's specified employer. Modern relational databases have
the same type of constraint enforcement, but do not have explicit names
for multi-valued partnership sets - instead requiring all queries to be
written in terms of the global set of all records of the same type,
which is fragile and inconvenient. Specifying named multi-valued
attributes is the standard OO way do this, but generally speaking OO
systems do not support constraint enforcement, something that is a
practical necessity in a general purpose knowledge meta model.
Otherwise a model can easily become corrupted with update anomalies,
just like a poorly normalized relational database.<br>
<br>
Please note by the way, that just because I have a class specification
language, does not mean I plan to eliminate the ability to declare
classes and class attributes at runtime. That is a key requirement.
One might just as easily enter class definitions into a flight
simulator (while the simulation is running) with a GUI entry system at
runtime, as enter them with a text editor ahead of time.<br>
<br>
It is important in the long run that class modification can be done
while there are other active queries going on in the system. It is
really annoying to have to kick everyone off just to add a new field A
multi-user general knowledge modelling system would be useless if this
was the case.<br>
<br>
- Mark<br>
<br>
<br>
<br>
</body>
</html>