[
Lists Home |
Date Index |
Thread Index
]
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@reutershealth.com]
> 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.
|
