Re: [humanmarkup-comment] Base Schema - Intention

[Rex Brooks <rexb@starbourne.com>]

My last post stands as is. If we include intent or intention in the 
Primary Base Schema is one question. Codelists would be appropriate 
in the Secondary Schema for Diplomatic Communications following a 
brief enumeration (not an exhaustive ontological list) of base 
characteristics in the Secondary Base Schema to set the stage for the 
Diplomatic Communications Schema. The Primary Base Schema is not the 
place for large lists. It is the place for the briefest, most atomic 
element units.

However, having said all that, my personal opinion on codifying 
intent is that it is best handled within cultural/social contexts. We 
are striving to reduce miscommunication, and in particular with 
regard to intent, we are striving to clarify intent in such a way 
that those parties who would rather promulgate confusion or 
perpetuate plausible deniability find it increasingly difficult to do 
so successfully.

If we have a means to say: "Given the cultural context K,L,M in which 
you assert you belong, and in regard to event N,O,P when you said 
X.Y.Z, did you really mean A,B,C?"; then, (if K,L,M has agreed-upon 
definitions according to HumanML DipCon to which parties have agreed) 
we can clarify what event N,O,P was according to cultural context 
interpretation by following up relentlessly on what was 
meant(intention) in the signal X,Y,Z. That is where we can get 
traction on people whose diplomatic skill is to lie convincingly.

So, IMHO, if what you are suggesting can lead to increasing clarity 
by pinning down intentions according to cultural context--which has 
been supplied, hopefully, by members of the culture itself--I'm for 
it. However we need to be very careful so that we can expose 
discrepancies between what the culture says and what the individual 
member or representative says, then we can expose deliberate 
miscommunication, or we can show where terms have different meanings 
to different cultures and we can show both sides where that 
disconnect occurs in a way that they can only maintain their 
intransigence by exposing themselves as refusing to understand a 
clear explanation of the miscommunication in front of the court of 
public opinion. (For instance, Freedom Fighter/Terrorist, Innocent 
Victim/Collateral Damage, Revenge/Retaliation)

I think that's where I'd like to see us go. I am pretty sure that 
complexifying the Primary Base Schema is not the way to do that, but 
setting the stage with a clear base element - intent - with a clear 
description that says simply that there is a purpose in mind for a 
communiciation/signal is a way to do that. What that purpose is or 
what the intent is must either be asserted by communicator/semiote or 
inferred, but if inferred we will have to resort to the Secondary 
Base Schema and reference cultural context and then the DipCon Schema 
for codelists and rules by which we can reliably and accurately make 
such inferences, and document our process for doing that very very 
carefully.

Ciao,
Rex

At 4:45 AM -0400 9/7/02, Ranjeeth Kumar Thunga wrote:
>Following (and renaming) my own post so quickly?
>
>From another review of Len's original Base Schema, I see that the
>HumlIdentifierAtts Attribute Set may not be referring to the human the
>way I had assumed it did.  This actually makes discussion of this
>proposed attribute much simpler.  (I cut and paste the entire discussion
>thus far below, for convenience.)
>
>Thus, at this point, I propose that the new attribute simply be called
>"intention".  Perhaps it would serve the dual function of identifying a
>specific intention ...or perhaps we actually would need another
>attribute called "intentionID".
>
>As for specific enumerated codelists, and whether there may be other
>related attributes to consider as part of an attribute set, and how they
>should be included, I would certainly like to hear ideas. 
>
>To clarify, these codelists would of course be referring to the original
>intention themselves--not the resulting signs (i.e. speech actions).
>
>-----
>
>Ranjeeth Kumar Thunga
>
>
>
>(CUT AND PASTE FROM LAST POSTS...)
>
>(NOTE: Hopefully we WON'T stick with this attribute name--if any of you
>have any suggestions, please do post ;))
>
>HUMANML -- MESSAGE OR HUMAN
>-----
>Len had mentioned a while back it may not be possible to convey
>intention directly.  And I am finding that it may very well be
>true--intention is not visible.  But so often in human communications,
>we would need to be able to simply convey a very specific intention,
>even though there are several layers that we may need to go through to
>ultimately demonstrate it.
>
>I asked myself if we are describing a communication "message" or a
>"human"?  As we have approached HumanML, it is certainly the later.  We
>settled long ago that we best start with the human first, at the base of
>HumanML, and then address the specifics of the communication message
>within the description of a human--a more ambitious approach, but
>certainly more fully rounded.
>
>However, before our Schema submission to OASIS, we probably should flesh
>out any issues we may have with the other perspective.  In thinking
>about how to incorporate intention within the Base Schema, I found that
>there may be situations where we may want to identify only the
>communications "message" itself, and not necessarily the "human".
>
>COMMUNICATION IDENTIFIERS
>-------
>The way this would work is with an additional attribute, which I propose
>for now be called HuMLCommIdentifierAtts.  This attribute would cleanly
>allow us to provide a container for intention to be used by most of the
>current base elements, without necessarily addressing the philosophical
>question of "intentional" vs. "unintentional" communication, which finds
>itself a common problem among several of the elements within our Base
>Schema, and which we currently have no way of currently addressing.
>Nonetheless, it is crucial to have a container for intention available
>if we hope to alleviate misunderstanding.
>
>Just like identifying a human being, there are several means of
>identifying a "message", but not necessarily any one identifier is
>sufficient.  This dovetails with our earlier discussion in our last TC
>meeting in which we talked about straight intentions vs. derived
>intentions.  In some situations, the intention is a given -- a specific
>label such as "to guarantee retaliation".  In other cases, it may need
>to be derived based on the signs expressed.
>
>I'm shaking my head out now rather than later. 
>
>Intention is a fundamental concept which has to be accounted for in the
>Base Schema, especially for Diplomatic Communications.  Although its
>painfully clear to be otherwise, formal diplomatic communications is
>usually *supposed* to be an "unbiased discussion" free of human
>contextual influences (i.e. biases).  Since we are representing extant
>systems (at least how they are supposed to work), we would necessarily
>have to account for situations of abstracted messages as well.
>
>DATA TYPE
>-----
>As I alluded to above, the data type for this element should not be
>Boolean (i.e. intentional or non-intentional).  Rather, it would be an
>enumerated list of possible intentions.  Although it makes intuitive
>sense for me to include intention as an attribute set referenced by
>several elements, the big limitations is that such a list is unavoidably
>flat, by the very nature of XML.  And intentions are NOT so cleanly
>broken down.  From my understanding for this to work, extensible
>attribute sets will thus have to be referenced within the Primary Base
>Schema for additional attribute sets.  I'd like to hear what limitations
>this may or may not result in.
>
>CONCLUSION
>-----
>Ultimately, the HuMLCommIdentifier attribute provides a mechanism to
>identify the message itself in cases where only that is relevant. 
>
>What about situations where the intention may not be clear, and may need
>to be determined based on an analysis of the signs conveyed?  Well, the
>HuMLCommIdentifier attribute would only be required if HuMLIdentifier
>were not present--it could otherwise be an optional attribute.
>
>(As a note:  the original plan was actually to call this effort CommML.
>However, HumanML more fully seemed encompassed the purpose of the
>effort.)
>
>TIMEFRAME
>----
>Rex of course is really looking to get this Schema Draft completed by
>the end of this month.  Although we officially until December 1st, 2002
>to submit our draft to OASIS, we also have to take into account the
>practical matters of timing.  Thus, it is important to flesh out any
>concerns as we have them now.
>
>-----
>Ranjeeth Kumar Thunga
>
>
>I'm snipping the content from earlier posts on "Base Schema - Intention"
>
>
><snip>
>A codelist is just a sign set.  I would rewrite that as
>
>  ->  intention ---> Select(sign+) ---> encodeForTransmission
>  |  ---> transmit ---> decodeFromTransmission ---> Select(sign+) --->
>intention ->|  |
>|
>
>|________________________________<______________________________________
>_________|
>
>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.
>
>len
>
>-----Original Message-----
>From: Ranjeeth Kumar Thunga [mailto:rkthunga@interposting.com]
>
>Also, to summarize what I intended during our TC conference about
>intention:
>
>I.
>Based on our conversation, this is how I see the process you are
>describing:
>
>intention --> codelist --- transmission ---> decipher codelist -->
>extract intention
>
>Very important to make the entire code of transmission clear in this
>regard of course.
>
>
>-------------
>II.
>However, what I was trying to express during the TC telecon was that I
>see an additional process for conveying intention, much more
>fundamentally:
>
>intention --> transmission --> intention
>
>This I would be at the same level as Emotion or Thought, and I would use
>the same arguments to embody this within the Base Schema that you
>mentioned in your previous posts on emotion Len in terms of its
>fundamentality in describing ourselves and our perceptions. 
>
></snip>
>
>
>
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.384 / Virus Database: 216 - Release Date: 8/21/2002
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com