[humanmarkup-comment] Base Schema - Intention

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

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