Re: [humanmarkup-comment] Base Schema-HumlCommIdentifierAtts(attribute)

[Ranjeeth Kumar Thunga <rkthunga@interposting.com>]

Title: Message

I've kinda broken up the discussion...however, this particular thread will be focused on identifying intent (vs. simply describing them).

 

IDENTIFYING INTENTS

======

My current thoughts feel we may still need to have such a CommIdentifier (or interpretorID?), although the definition may not have been exactly what I stated a couple of days ago.  Although there is no way we can externally verify intent (or emotion, or thought), we can still make explicit conclusions given what we know, even if they are wrong, incomplete, or different. 

 

As you alluded to Rex, there are two intents:  asserted intent, and inferred intent.  Although we may never reach parity between asserted intent and inferred intent, we may necessarily have to have separate containers for these values (distinguished by different interpretorID's perhaps?)

 

This also applies to belief, culture, and emotions....there is asserted and inferred aspect to each of these as well.  I think this was discussed a while back, but it's worth bringing up again because I would like to refresh myself on how we could address this.

 

APPLICATION IDEAS

=====

BTW, I am basing my arguments on applications I can envision:

-I would like to explicitly detail how the inferred conclusion about my counterpart's intent compares with his/her stated intent.

-As an application designer, I would like to develop an application based on HumanML that will allow me to input my intention and generate a report that clearly states my intention (simply a field in a database in this case).

-As a simulation designer, I would like to input a value for my intention that will generate the set of signs representing my intent in such a way that I am not being misinterpreted by different cultures.

-As a message processor, I would like to be able to delegate incoming communication streams based only on the original intent of the message.

 

OTHER POINTS ABOUT INTENT

========

Rex:  Agreed.  A value for intention would necessarily have to be optional.  We can't assert intent when it isn't necessarily so.

 

Len:  I may be overlapping intent with sign/signal, but I don't think I am...but do let me know. 

 

Do you think "message" may be more appropriate than "intent" as capturing the fundamental aspect of communication?

 

 

Ranjeeth Kumar Thunga

 

 I believe I have said before that we can only and MUST accept any assertion of intent at face value and compare it to the actions of the agent which makes the assertion. I have never been comfortable with the idea of attempting to codify it. Just for the record, I think we will lose credibility if we insist on attributing intention anywhere it is not asserted. There is no question that there are intentional and unintentional signals/communications, but I do not believe we can adequately or correctly distinguish that to any reasonable degree of certainty except to say, with a big disclaimer, "The intent(ion) APPEARS to be...BASED on...."

 

A message is a signal composed of signs. Beyond that, IMHO, there is likely to be little agreement.

Also, just so no one gets confused, Intention is not included in the current straw man toolkit schema.

So the question is whether or not to include it in the Base Schema, so I suggest we add it to the list of new elements to consider, in this case two elements, intention which I would prefer to shorten to intent and humlCommunicationIdentifierAtts or humlSignalIdentifierAtts or something else.

Ciao,

Rex

> (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

---
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