He sold/has sold/is selling/will sell/may sell a car to John
He did not/could not/would not/should
not sell a car to John
John bought/is buying/may buy a car
from him.
Object Groups
We can give any grouping of objects
properties through inheritance or through connection with a relation, properties which are
then inherited by the members of the group – “the team won” – the
members are winners too. This works both ways – if we can show that every member of
the group has some property, and the group can have that property, then the object group
acquires that property. This gives us a form of computable inheritance from realised
classes.
Computable Inheritance
Treating relations as objects and
allowing them to acquire properties through inheritance greatly increases the density of
the inheritance structure. We cannot assume the inheritance structure is static or known a
priori. We should expect collaborative contributions to change the inheritance structure,
requiring it to be dynamic. Frequently, disambiguation will turn on changing the location
of the connection of an object into the inheritance structure.
Two situations arise where
inheritance is not fully known, even after contributions. One is where an object is part
of another complex object, but we are unsure which part. “Part of the building is on
fire”. Until we know more about the “part”, it needs to potentially inherit
all the appropriate properties of the building and any (combustible) component and its
container, and we need to interpose some control over the inheritance path, initially
allowing alternatives and pruning them as we learn more. A related case is where we know
an object is a member of a group, but we don’t know which member. We are told a
member of staff is to receive an award. That member has potentially acquired the
individual properties of every staff member. We are then told the person is female,
sloughing off many possible properties (“not the janitor”), and so on. Under
some circumstances, inheritance needs to be controlled, does not just come from above in
the hierarchy, and the methods of constraint reasoning can be used to aid in narrowing the
possibilities.
Relations on Relations
We gave an example – “the
option to extend the lease” – in this example, there are three relations, all in
a row. If human intention is involved, a whole new layer of relations is added –
“he thought he needed to exercise the option to extend the lease” (in this case,
the statement is incomplete as it is the term of the lease that is extended, and it is
assumed that the option exists, but it is not activated by this structure). With
existential control on relations, and seeing relations as objects, relations on relations
is easily handled. A relation on relation structure to any depth is built by connecting
the relation objects and their parameters, which may be relation objects. In AI, we have
struggled without this facility for a very long time.
Existential, logical and inheritance links are
not shown in figure 4. For a complex DSS, there may be hundreds of thousands of elements
required in the active structure, many of which may change their state rarely. It means
that all the context of the DSS application is continually able to be sensed (but while
there is no change, there is no activity, so a large and densely connected structure is
not necessarily wasteful).
Active Maps
We have been describing components,
like relations, and how they may be joined to form larger structures. This is a reasonable
analogy of what happens when a person builds cognitive structure starting from nothing,
but people rarely do that, and collaborators never do. A more realistic and more
complicated problem arises where we have significant pieces of knowledge –
contributions that form relatively independent islands of knowledge - and we wish to
combine them into a DSS, based on their interaction with each other. Humans have an
ability we call the “semantic octopus”. Something arrives at a point of
disconnected activity, grasps the free connections, ties a knot, and moves away. It has
about the same range as an octopus – somewhere between six and nine free connections.
We haven’t yet conceived of how we can directly match this, but if contributions are
to be stitched together into a seamless whole, some similar mechanism is required. An
active map connects itself to the things it finds, then runs a constraint reasoning
problem involving itself and what it has connected to. If the problem solves, further
structure is built and the active map detaches itself.
A Package
The ability to actively represent
relations on relations relies on existential control of individual relations, on relations
being conceptualised as objects, so they may be part of the inheritance hierarchy, and on
relations inheriting a component of time period, which determines their existence. These
properties of the structure are not divisible into separate properties which can be added
individually – they support each other synergistically.
Some Relevant Issues
Assembly
It is much easier to assemble active
structure than it is to assemble directed algorithmic components of an overall algorithm.
It is also much easier to assemble active structure than some preconceived pieces for an
application anchored in a particular domain, where one relies on the foresight of the
programmer to predict all the interactions and operations that may occur. For many
systems, most of the skill in creating a DSS consists in twisting algorithmic elements to
achieve some end that was not foreseen. Pieces of active structure can be knitted together
with other active structure to cross mismatched joins so the resulting structure is
seamless, or they can come with hooks that seek out other pieces of structure and then
dissolve after their work is done. Active structure can be built and tested as
self-contained islands of knowledge, which later coalesce into archipelagoes and then
continents, using the properties of self-modifiability and immediate activity on
connection.
Common Understanding
Collaborators can achieve a common
understanding by exercising parts of the structure, by observing how other contributions
feed back into and affect their contributions, by observing weaknesses and fault lines. By
being exercisable while incomplete, and allowing temporary structure to be placed on top,
the structure lends itself to being a foundation for further work at each stage of its
building. Sometimes the common understanding will break down as the structure nears
completion, or even after it has been in use for a while and does not provide the
decisions some of the collaborators expected. It is then that the ability to isolate the
faulty structure becomes critical, particularly if the faulty structure crosses
contribution boundaries.
Complexity
Complexity comes in two forms. One is
where the complexity lies wholly within the bounds of the contribution, and while needing
connections into other areas, the complexity is managed by one of the collaborators. The
other form is where complexity emerges from the interaction of different, relatively
simple, contributions, with no collaborator expecting it or responsible for managing it.
Emergence of complex and unexpected behaviour is typical of many systems, so it becomes
important to ensure that the tools of systems analysis are available. Typically these
include localised or controlled activation, tracking of behaviour with different,
including extremal, inputs, hypothesising and testing, temporary removal of feedback
paths. As active structure allows probing at an atomic level of activity, fine control
over existential and logical states, hypothesising, and the addition or removal of
structure at any point, it is ideal for the kinds of analysis required at a system-wide
level.
Data collection and Exchange
We would argue that any data comes
with a structure and a process, and a model of the process can be easily built in active
structure. While statistics can be used to seemingly provide information from data without
a process being known, this only works at a shallow level. It is just as easy to produce a
model component, which, for given inputs, produces a desired output, and vice versa. That
is, the data model is undirected, and while the transformation from output to input would
usually be one to many, it follows the undirectedness paradigm of the rest of the
structure, and the DSS is easier to understand and debug as a result.
Utilising Context in Knowledge Management
There are two forms of context in a
knowledge-based system. There is the overall context in which the DSS is embedded, and
there is the context of each decision, which is not predictable. The first form of context
can be represented by a very large amount of structure which has a low probability of
change. If any part of it does change, that change will flow through the system, causing
it to alter its behaviour. The second form of context can be passed from one decision
point to another by creating and propagating an active structure, allowing subtle
description of the transient context.
Examples
Planning and Scheduling
There is a continuum in planning and
scheduling of projects, from the initial concept, through tendering to program and project
management. We have the people who conceived of the need, the people who let the contract,
the people who manage the project, and the people who will own the project product.
The planning process may look like an
orderly progression through time, but the project can run into problems, the contract
price blows out or there are delays, calling the concept into question. It is normal for
back-connections to play a significant part in the process. The current decision support
tools are algorithm-driven and the process is directed and segmented, so that people who
could collaborate are held at arm’s length by a methodology that cannot allow their
input until it becomes necessary, or their input becomes unconnected from the current
project plan by the passage of time. It is much more powerful to use a broad spectrum
planning approach, which, with the same methodology, supports the concept development, the
cost-benefit analysis, the tendering process, requirements management, the contract
management, the project management, the owner’s view. Active structure allows every
stakeholder to contribute their requirements and constraints to the DSS, so that the DSS
continuously supports a model which includes the what, the why, the when and the how much,
rather than one aspect. There is a stitching of the contributions that is required, shown
in figure 6, as the contributions will usually not overlap. The stitching not only needs
to be undirected, as influences may flow in any direction, but must be able to represent
any process, which is why we describe the structure as active. Only if the stitching is
capable of connecting anything to anything, through whatever intermediate structure is
necessary, can synthesis be achieved outside the head of one person. Otherwise, no matter
how diverse and detailed the contributions, a person must maintain synthesis, which is
impossible for large and complex projects over a long time scale.
If the project drifts off spec,
the contribution from the strategists drags it back (because the initial specifications,
the why, are part of the structure), if the project drifts from what the owners can pay,
it will be killed by the owners’ contribution to the model (and the project manager
can feel the potential pain of failure, and plot another course).
Figure 6 - Stitching
Figure 7 shows a simple form of
an ACTIVITY, with only logical control from a spine or logical condition (costs and
resources associated with the activity are not shown). A more complex form makes it the
same as any other relation, with the same subtlety of start and finish date.
People may be concerned at the cost of modelling projects at this level of detail, but
the cost of large failed infrastructure projects regularly runs into billions of dollars,
so providing the capability for all the stakeholders to directly collaborate to the
success of the project is a small price to pay.
Requirements Elicitation
Requirements elicitation is only a small part of the planning spectrum, but it carries
its own problems of collaboration. The ideas will usually be woolly, and there may be
several possible scenarios, each with its own particular details. Trying to put a hard
edge on everything too early is a mistake, but carrying forward flawed concepts longer
than necessary is equally a mistake, as attributes of an impossible choice may seem
attractive and spawn further investigation down dead ends, or people will defend worthless
concepts because they have invested their time in them. Active structure can be used to
outline the possibilities and slowly draw in the constraints, switching properties on and
off as scenarios are examined. What emerges is an outline, but with sufficient connection
to reality that a design is possible.
Supply Chain Management
Supply chain management has the need
for people to collaborate across many domains – scheduling, price, quality assurance,
manufacturing. If we broaden the definition, and include the distribution of the good
produced by the supply chain, we bring in other groups, such as sales, management
accounting, who may wish to collaborate if their direct involvement could be supported.
One aspect of supply chain management that is particularly difficult is the supply
contracts, which are usually handled as repositories of opaque knowledge until something
goes wrong (it usually has to go badly wrong, at that). A collaboration occurred in
creating each contract (often with little connection between contracts or any sense of
being part of a supply network), and the sense of this connection is largely lost in
operation. Using active structure permits the structure of each contract to be extracted,
so the collaboration it represents can be actively represented. The drivers of the
contributions in each of the different domains are quite different, making it preferable
to use a methodology that turns all the contributions into an integrated whole and allows
tradeoffs backwards and forwards into any domain. Within a domain, cost of components
needs to be weighed against cost of assembly, and then outside it, cost of delivery of the
assembled product. An initially undirected structure assembled from contributions would
seem an appropriate choice, both within each domain and over all the domains involved.
Knowledge-Intensive Collaborative Design
It sounds trite to suggest that the
collaborators contribute knowledge, which is assembled to produce the design, together
with the structures that support the design, such as market surveys, product standards,
even aesthetics. It requires that their contributions be in the form of knowledge that is
active and can be assembled without limits imposed by preconceptions of what is possible.
If the design must fit within a predefined framework that suits horses and carts, the
emergence of a design for a helicopter is unlikely.
This is a crunch test for
collaborative design – if the framework of the collaboration cannot support new
ideas, ideas that were not envisioned when the framework was created and which would
require either a subtly or radically different form of knowledge to be used, it is not
design at all, but merely “tiling the plane” of what is possible within the
framework. Active structure would seem an appropriate form to allow new designs to emerge.
Will the collaborators need to consider the existence of the different components of the
design – undoubtedly. Will the analysis of the quality and likely success of the
design use relations on relations – probably. If the methodology they use cannot
support these things, the collaboration process is likely to be heavily compromised.
Conclusion
We have described a methodology which
is capable of representing and activating knowledge, allowing collaboration at the level
of knowledge. The methodology supports a close integration of propositional, existential
and temporal logic, and relations among objects. This integration frees the collaborators
from concern about process, and allows their individual contributions to contain
ambiguity, which can be washed out by activation of the structure that is built from the
contributions. An active structure, like knowledge, is undirected, so that collaboration
results in the creation of a much more powerful system than one which is geared towards a
particular end before it receives contributions. Emergence of unexpected behaviour can be
handled by allowing the system to analyse itself for consistency and coherence. Building
active structure allows collaborators to contribute at the level of complexity attainable
if they wrote or spoke to each other, but with easier integration, less ambiguity and more
rigour, as each contribution can be tested for consistency with the structure that has
already been built. We emphasise the level of complexity – active structure can be
very dense in its possible connections, as dense as is required to reflect the complexity
– no more, no less.
Bibliography
Whither Directionality (http://www.inteng.com.au/whither.htm)
Active Structure Extensions (http://www.inteng.com.au/NLP%20Operation/extension_to_active_structure_to.htm)
Cognitive core of an EIS (http://www.inteng.com.au/cognitive_eis.htm)
