[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Ontologies
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|