xml-dev - Re: Ontologies

["W. E. Perry" <wperry@fiduciary.com>]

Jonathan Borden wrote:

>     An ontology itself does not define a processing mechanism. Rather
> ontologies are *used* by processing mechanisms.

True. But in theory (if you can accept that the way I do it does not violate the
nature of ontologies by insisting that they are of real-world use only when in
the service of process) the use of ontology by processing mechanism necessarily
implies that the processing mechanism, or at least an understanding of its
workflow, comes first. In practice, I have been able to do something useful only
by working on that assumption.

> The nodes of a directed graph representing an ontology (e.g. a semantic
> network) do not require unique processing code. Certainly the resolution of
> a URI into a resource *may* involve processing of unique code (e.g. a
> servlet) but this is not required by nor central to the definition of an
> ontology.

Not at the level of definition or of abstract specification perhaps but, beyond
resolving a URI, how do you get the ontology to serve the need to *do* something
which fulfills the intended function of a node.

> I think Walter is proposing a model whereby code is attached to a node
> and by all means this may indeed be a useful way to do things, to wire up
> the semantic web. My view of the semantic web, on the other hand, is one
> where custom code exists in the form of a smart "user agent" that navigates
> a web of URIs.

Is anyone actually building these user agents? I tried it this way two years
ago, and I have talked to a few people whose designs look like this, but I
couldn't get it to work, and I haven't seen a convincing implementation. In
brief, my problem with the user agent is that it is built on the unidimensional
pipeline, rather than the web, metaphor. It is actually a very complex and very
stubborn object, programmed a priori with an inflexible mission. It sets out to
navigate a predetermined course of nodes, adding something to its store of data
or undergoing some transformation at each one, but never allowing anything it
might experience to deter it from returning to its master. In trying to
implement such a thing I found that  a) in most cases, one of the most useful
things a node can do is direct its output somewhere unknown to the node upstream
which first sent it a data message (often this routing is the highest expression
of a node's expertise), but following this ad hoc routing would violate the a
priori program of the agent's mission;  b) there are many real-world situations
where there are multiple interested parties to the output of a particular node,
and in order to complete a task all of those parties must be involved, but doing
that involves forking the user agent, which violates its fundamental unitary
design;  c) there is no good way to deal with the case where the user agent
fails in its task at a given node, in a manner which, though easily understood
at that node, cannot be recorded in the predetermined data structure of the
agent object, which returns home unable to express its failure. When these
designs got sufficiently baroque I threw them away and began again with
something much simpler in concept.

Respectfully,

Walter Perry