xml-dev - Re: Ontologies

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

Ronald Bourret wrote:

> Could you explain at a technical level what is happening? It sounds like
> a node contains code to extract whatever it needs from the input, but
> that this code must be written explicitly. That is:
>
>    "The point is that in all these cases there is processing
>     code--unique to each node--to be written, and nothing will
>     magically obviate that chore."
>
> Is this correct?

I would not use the term 'extract'. An integral step in the processing at each node is
instantiating the particular data structure(s) which the node's specific process
expects. This work is a necessary part of coding any executable process:  even in
those cases where the whole of the data structure required is passed in through a well
known API, the executable code must instantiate the process instance of that data. The
salient point is that the process is capable of instantiating its own requisite data
structures. What is unorthodox in the cases we are considering is that any of a number
of input data forms might be presented. Some might convey all of the data required to
initiate a node's processing. Others might convey less, and still others might convey
none of the required data, but serve merely as an event notification that the process
needs to be initiated. My own practice is to code a series of alternative procedures
for instantiating each component of the requisite data structure. If, for example, the
data presented conveys everything which a process needs to know of the specifics of a
customer on whose behalf a transaction is to be executed, then great:  the required
data structure can be instantiated directly from the input and the process initiated.
Otherwise, there should be alternative procedures specifying reference nodes to which
this node can submit some of the data which it has in order to 'lookup' and return
additional related data which it needs but does not maintain locally and did not
receive in the particular input.

Designing these alternative procedures is actually the heart of implementing a
processing node's particular expertise. Coding such procedures demands the domain
expertise for which that node will be called on. Often the ancillary process which a
node must trigger is not a lookup so much as it is submitting data to another node of
different domain expertise. It is an expression of the first node's own expertise that
it knows of the node to invoke; that it knows, in general terms, what data to submit
in order to be likely of receiving a processing return similar to one it has received
before; and that it knows what to make of return data, at least in the terms of its
own data needs. Effectively, this first node must do its own expert factoring of the
problem as originally presented to it, and then coordinate the operation of, and
interpret the returns from, any ancillary processes upon which it calls. Again, the
metaphor of the semantic web, rather than semantic pipeline, is apt.

There are therefore two distinct operations for a processing node in dealing with
input data as presented. The first is determining what components of that data--most
likely stripped from the alien structure in which they arrive--can be identified as
data which the processes implemented at this node can make use of. The second is
instantiating that data in the 'native' form which those processes expect. This second
task may well involve invoking processes at other nodes in a manner which, in
programming terms, looks like building a stack, or an execution queue, across a vast
distributed system.

> If so, why doesn't this contradict your earlier statement that:
>
>    "It is just as futile to try solving this problem by creating
>     a separate API for each class of node-to-node pair interactions."
>
> since the node would need to contain different processing code for each
> node from which it could possibly extract useful data to use as input?

I hope that it is now clear from the response above that node-to-node pair
interactions are implemented in this web in a manner utterly different from  1)
identifying each interaction;  2) formulating an API which covers the union of the
data needs of the participating nodes;  3) gaining the acceptance of that API by all
participating nodes of both the identified types before beginning general execution of
operations covered by that API.

Respectfully,

Walter Perry