[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: A multi-step approach on defining object-oriented nature

• To: 'John Cowan' <jcowan@r...>, paul@p...
• Subject: RE: A multi-step approach on defining object-oriented nature
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Thu, 22 Aug 2002 13:13:28 -0500
• Cc: wperry@f..., xml-dev@l...

It is that interpretive selectors are always locally programmed 
and mediated by local perceptions of what is important.  

That is fine in a unidirectional message pipe.  It is messy if the 
pipe has feedback loops or is multi-directional with the 
expectation (ontological commitment) that receivers will 
behave (where behavior is a sign) predictably 100% of 
the time.  They won't.  We may need them to.  When we 
do, apriori agreements on needs and signs is the best 
way to go unless we want to endure a learning negotiation 
with all of the frequency problems and semantic noise.

Allow me to repost something I sent to the HumanML list:

 -> intention ---> Select(sign+) ---> encodeForTransmission ---> 
 |  transmit ---> decodeFromTransmission ---> Select(sign+) ---> intention ->|
 |                                                                           |
 |________________________________< sign_____________________________________|

although that isn't quite right either.  What I want to emphasize is the 
role of selectors that mediate the signs chosen and transmitted.  That is, 
intention itself requires a selection process and the data being fed to 
that comes from the types we have described as culture (itself a sign 
set), personal experience (episodic memory) and the emotional impressions 
made by these that predispose the semiote to select certain signs over 
other signs.  I don't think we can transmit our intentions.  We can 
transmit representations of these as signs.  Again, the problem is 
symbol grounding.  That is why Y=F(X) is overly simplistic.  Perhaps 
codelist is inappropriate as well in that it also connotes a single 
list of value pairs.  We may program it that way, but actually, we 
end up in vector space working with proximate values and fuzzy signs.

No all of that doesn't apply to purely mechanical exchanges, but I
think the issue of the selectors is universal. The reason for 
having sharable schemata is to cut down the learning expense 
for sign selectors.

len



-----Original Message-----
From: John Cowan [mailto:jcowan@r...]

> How can a process select the data it will work upon without a priori
> knowledge of the semantics of the element types. 

This is the place where WP and I still butt heads.  I think I see his
point of view, but I'm not clear enough on it yet to actually state it.

• Prev by Date: Re: A multi-step approach on defining object-oriented nature
• Next by Date: Re: Lindasphere, XML spaces, RELAX NG ??? (was Re: A multi-step
• Previous by thread: Schema Sanity Check
• Next by thread: RE: Schema Sanity Check
• Index(es):
  • Date
  • Thread