[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [humanmarkup] Re: PBS-Doc-intent(commentary)
I'm going to add my two cents worth on intent, because it also lays at the foundation of a new discipline of XML schema programming often called "Intentional Programming". In essence, intent is the set of motivational factors that initiate a specific action; when the intentional conditions are all met, the intent acts as a trigger for that action. As such, intent is fairly complex, because it relies upon monitoring of external conditions on a repeated basis. Consider for instance, the dilemma of the employee, and notice how the intent changes based upon multiple scenarios:
Stimulus->"Employee loses job due to lay-offs"
State ("Employment") => no
State ("BankAccount") => full
State ("EconomicConditions") => good
Intent => "Should Rest and Enjoy Life"
State ("Employment") => no
State ("BankAccount") => half-full
State ("EconomicConditions") => good
Intent => "Should Look For Job"
State ("Employment") => no
State ("BankAccount") => nearly empty
State ("EconomicConditions") => good
Intent => "Should Actively Look for Job"
State ("Employment") => no
State ("BankAccount") => full
State ("EconomicConditions") => bad
Intent => "Should Start Company"
State ("Employment") => yes
State ("BankAccount") => full
State ("EconomicConditions") => bad
Intent => "Should Work Harder"
etc.
Intent is a prelude to action and is usually the enumeration of a set of desired states -- the intent is "Should look for a job", or "Should change employment from no to yes". The actions then are the means that are taken to fulfill this change in state.
Because of this, I'd caution us on assuming that intent can be a simple string: instead, it is likely to be the enumeration of a set of goals, which are in turn defined as desired states.
-- Kurt
----- Original Message -----From: Rex BrooksTo: humanmarkup@lists.oasis-open.org ; cognite@zianet.com ; clbullar@ingr.com ; kurt@kurtcagle.net ; mbatsis@netsmart.grSent: Wednesday, October 23, 2002 4:34 PMSubject: PBS-Doc-intent
This is a bit of an odd ball, since the first entries happened after the later entries because there was a discussion arriving at the need to add intent to the PBS prior to finalizing the most basic definition for the PBS.
I added it to Human Internal States with thought and emotion.
I added a couple of refinements: Human intent is the state of mind and emotion, characterized by purpose and volition, with which a human acts or prepares to act.
Subject: [humanmarkup-comment] Base Schema - intent
From: Rex Brooks <rexb@starbourne.com>
To: humanmarkup-comment@lists.oasis-open.org, humanmarkup@lists.oasis-open.org
Date: Thu, 17 Oct 2002 07:00:04 -0700
Here is a first take on:
Base Schema - intent
This is an abstract complexType element which will take the attribute
humlIdentifierAtts since it can apply to actions other than
communication and can serve to identify a particular characteristic
of an human. It does not use other elements. It may be used by other
elements.
It is described/defined as Human Intent is the state of mind,
characterized by purpose and volition, with which an act is done.
We have had fairly lengthy discussions arriving at this element as
necessary in the Primary Base Schema, which I agree that it is. I am
fairly certain that it is defined narrowly enough here that many
shades of intentionality, culturally-based or not, and conscious or
not can be built on it. It is also equally applicable to momentary,
short term or long term goals, aims and objectives.
Ciao,
Rex
Subject: Re: [humanmarkup-comment] Base Schema - intent
From: cognite@zianet.com
To: :
Date: Thu, 17 Oct 2002 12:29:40 -0600
Suggesedt change of "state of mind" to "state of mind and emotion". General
does look ok.
Others' feedback on this?
Suggest that Easy-to-read format for entries seems to be needed,
judging from the UDDI tome with its term-by-term descriptions.
(REF: uddi-v3.00-published-20020719.htm from
http://uddi.org/pubs/uddi_v3..htm (which says, "Universal Description
Discovery & Integration (UDDI) is the definition of a set of services
supporting the description and discovery of (1) businesses, organizations,
and other Web services providers, (2) the Web services they make available,
and (3) the technical interfaces which may be used to access those
services." It is a consortium of MS, Sun, Nippon T&T, and SAP, which after
formulating stuff joined OASIS and published said spec in July. It is a
registry info access and info deposit setup.)
Term entry layout that is both computer-legible and visually clearwould be
nice.
The version proposed below puts header and filler on different lines (for
delimiting so readlines can be used.) and adds a little table. Term tables
could be gathered [using a script perhaps] into a composite table for the
schema. One column (labeled "COPYME" below) might be a literal to be
pulled by apps automatically. The table might well be pure text or could
include images/URLs-to-other-things. While UDDI has a little diagram for
each term which don't show well or save well in all browsers, it would be
more serviceable perhaps to use UML diagrams to show term structuring. A
UML diagram can be transformed to and from code but is
programming-language-neutral.
SC
------------------------------
INTENT
HUML Base Schema Primary term
Definition/Description:
Human Intent, <INTENT>, is the state of mind and emotion
characterized by purpose and volition, with which an act is done.
Discussion:This is an abstract complexType element.
It will take the attribute humlIdentifierAtts since it can apply to actions
other than
communication and can serve to identify a particular characteristic
of an human. As a Primary term, it does not use other elements, but it may
be used by other elements.
Table:
COPYME | SCHEMA LEVEL TERM SHORTFORM TYPE ARGS DEFNDESCR EXAMPLES DIAGRAMS REFS USERAPPS USERCOMMENTS
Hi Folks,
What follows is our discussion to date on intent, mixed in with humlCommAtts, so you will see this duplicated with a different subject line in support of that attribute, which, because I think we resolved that issue in the monthly telecon for Oct. yesterday, will be a very short post on its own. I will post a separate Base Schema - intent message shortly in the more or less standard format for these element discussions and we can continue that discussion, as we continue the discussion of Base Schema - belief.
Subject: RE: FW: [humanmarkup-comment] Base Schema - Intention
From: Ranjeeth Kumar Thunga <rkthunga@interposting.com>
To: humanmarkup-comment@lists.oasis-open.org
Date: Mon, 09 Sep 2002 00:27:42 -0400
All of this is very sensible--although I hope we can get more feedback,
I think your arguments are very sound Rex. I might have more to say
later.
DMML REFERENCE
==============
For now, I am listing the following effort which we may want to
harmonize with, which I've posted in the
past--http://xml.coverpages.org/dmml.html. I don't think they have been
very active in the last couple of years however, although they have done
a substantial amount of work.
Again, in relation to HumanML, I wanted to clearly distinguish between
speech actions and intent--they may appear to use the same codelists,
but in fact are on different levels of abstractions. I don't think DMML
makes the same distinctions, however.
Ranjeeth Kumar Thunga
Subject: FW: [humanmarkup-comment] Base Schema - Intention
From: Ranjeeth Kumar Thunga <rkthunga@interposting.com>
To: humanmarkup-comment@lists.oasis-open.org
Date: Sun, 08 Sep 2002 17:13:56 -0400
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 ourschema 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
Subject: Re: [humanmarkup-comment] Base Schema - Intention
From: Rex Brooks <rexb@starbourne.com>
To: Ranjeeth Kumar Thunga
<rkthunga@interposting.com>,humanmarkup-comment@lists.oasis-open.org
Date: Sat, 07 Sep 2002 07:51:36 -0700
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 orwhat 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 verycarefully.
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
Subject: Re: [humanmarkup-comment] Base Schema-HumlCommIdentifierAtts(attribute)
From: Rex Brooks <rexb@starbourne.com>
To: Ranjeeth Kumar Thunga
<rkthunga@interposting.com>,humanmarkup-comment@lists.oasis-open.org
Date: Sun, 08 Sep 2002 16:22:08 -0700
Title: Re: [humanmarkup-comment] Base Schema-HumlCommIdentifi
I think my previous post covered most of this. The only thing I will add is that we can do all of the applications
you mention without having an enumeration of datatypes or humlCommIdentifierAtts in the Primary Base
Schema. If we do decide to have humlCommIdentifierAtts we will have to be doubly careful to use only well
understood and accepted concepts like question, statement, etc which take boolean, string, or clearly
understood and verifiable integer/float values, for which we will not have trouble getting agreement in the
outside world.
As I occasionally mention in other TCs, we still have to sell this.
Ciao,
Rex
Subject: Re: [humanmarkup-comment] Base Schema-HumlCommIdentifierAtts(attribute)
From: Ranjeeth Kumar Thunga <rkthunga@interposting.com>
To: humanmarkup-comment@lists.oasis-open.org
Date: Sun, 08 Sep 2002 17:24:03 -0400
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 reportthat 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 thecommunications "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 thecurrent 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 thepractical 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>
--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC