Re: FW: [humanmarkup-comment] Base Schema - Intention

[Rex Brooks <rexb@starbourne.com>]

I think intent is better used as an element to set up the foundation 
for the derived elements in the Secondary Base Schema and that fully 
enumerated lists belong in Diplomatic Communications schemata and 
other Secondary application-area specific schemata.

My reasoning has little to do with intent or any other element and is 
based on simplicity being necessary in the Primary Base Schema, or 
else it serves no purpose to have it arranged like this and we might 
as well set it up so that we only have one schema to which we just 
add new elements and attributes as it seems called for. If that is 
what everyone wants, that is fine with me, but I don't think it makes 
as much sense as having a small primary base, a slightly larger, more 
enumerated, but largely derived secondary base for such things as 
types of emotion, types of intent etc, and building on those two as a 
foundation for derivations which can go their own ways from there...

The attributes which Len has in the straw man strike me as basic and 
fundamental and truly global and are mostly there to establish the 
datatyping for strings, booleans, and later for name-value pairings. 
I don't think intent falls into that category. None of the global 
attributes refers to any other element as part of its definition, nor 
does it require using some invented set of somethings to describe it 
such as we would need to create for intents of messages. All of the 
current global attributes are easily understandable, though they can 
vary due to language and character sets for well-understood and 
accepted concepts like name, address, date of birth, etc.

I think intent should be in the primary base schema with the smallest 
possible description being purpose for an action, of which 
communication (messages/signals) is the action we are most concerned 
with.

XML is plagued with this largely unnecessary division between element 
and attribute but we are stuck with it. My opinion is that if we can 
elminate attributes as much as possible it will lead to a cleaner, 
more efficient and more reliable set of schemata. It will just work 
better because it will require less parsing and therefore be 
susceptible to less errors and less value judgments such as: what is 
the intent of this statement or that gesture?

I think we are just asking for trouble if we do that.

Most especially I do not think we want any elements in our primary 
base schema that need to be modified much if at all by other 
elements. With intent having enumerations we set up a case where we 
could be seen as requiring that some kind of determination be 
possible or desireable for every communication as to its possible, 
(heaven forbid we ask for actual), intent.

If we don't have specific cultures or emotions in the primary base 
schema, how can we have full flown cultural social context 
determining any portion of intent?

So, to summarize, I am in favor of having intent as part of the 
Primary Base Schema, but not as an attribute to describe types of 
communications, such as threat, apology, question, statement, etc. I 
think that is best done in the Secondary Base Schema and with all of 
these being elements, not attributes. For me, attributes should be 
confined to things like name, address, eye color etc. We already have 
punctuation for written language and Voice XML for vocal 
communications, and the most we should do is incorporate an accepted 
waveform identification for emotion states carried in vocalizations.

I am of course, happy to follow whatever the consensus is. I can 
easily accept it. And I hope Rob picked up that it needs to added to 
the list of new elements to take up after we finish the first run 
through.

Ciao,
Rex

At 5:13 PM -0400 9/8/02, Ranjeeth Kumar Thunga wrote:
>As a note, as Rex clarified earlier, Intent(ion) is under consideration
>for a Primary Base Schema element and is to be added to our list of
>elements/attributes to consider.)
>
>Also, I have another post regarding HumlCommIdentifierAtts, which after
>a couple of days of marinating in my mind I feel is related once again.
>However, I believe a separate discussion thread, relating to different
>types of intention, and the different semiotes involved.
>
>ENUMERATED LIST WITHIN BASE SCHEMA?
>==================================
>I was thinking this as mentioning that our enumerated lists don't belong
>in our PBS...I understand how less is more at this stage.
>
>Nonetheless, intent seems best as a global attribute that defines many
>other elements.  Intent is the most fundamental unit of a communication
>message (NOTE: I am not saying the most atomic unit of a human).  That's
>why I left it open to hear of other implications of including enumerated
>attribute values within the Base Schema (as Len had done for global
>attributes, such as bodyparts, for example).
>
>INTENT vs. INTENTION
>====================
>"Intent" is better than "intention"..agreed.
>
>
>INTENT W/ CULTURAL/SOCIAL CONTEXT
>==========================
>I agree that on a level of describing reality as it is, intention would
>be best constrained by cultural/social contexts.  Your examples makes
>total sense, because it involves the forced discipline of ensuring that
>cultural context is always taken into account. 
>
>This accountability could probably find itself in a Best Practices
>Document perhaps?  But I don't think we should enforce it within our
>schema design.  The reason is, I think that application designers would
>very often want to simply capture intent, completely devoid of any
>context.  From an AI standpoint, there may not be any preexisting
>cultural/social context, although there still may be a clear intent for
>a particular message.
>
>However, we may have to treat derived and asserted intent separately,
>and have separate containers for the values for each.  That brings up
>another point, which I'll bring up in a following post.
>
>ELEMENT vs. ATTRIBUTE
>=====================
>As for whether it should be an element or an attribute...it makes
>intuitive sense for me that it is an attribute, for me, although I'd
>like to hear reasons otherwise.  My thoughts are that intent doesn't
>describe a person like the other elements, it describes a communication
>message and how that message manifests within other elements.
>
>-----
>Ranjeeth Kumar Thunga
>
>
>
>
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Saturday, September 07, 2002 10:52 AM
>To: Ranjeeth Kumar Thunga; humanmarkup-comment@lists.oasis-open.org
>Subject: Re: [humanmarkup-comment] Base Schema - Intention
>
>
>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.
>
>Two intents
>
>
>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
>
>---
>Incoming 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
>
>
>---
>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
>
>
>---
>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