Next in thread →
Next in month →
[humanmarkup] Re: PBS-Doc-intent
Title: PBS-Doc-intent
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 Brooks
To:
; ;
; ;
Sent: Wednesday, October 23, 2002 4:34
PM
Subject: 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 <>
To: ,
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:
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
DEFN
DESCR
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
<>
To:
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
<>
To:
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
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
Subject: Re: [humanmarkup-comment] Base Schema -
Intention
From: Rex Brooks
<>
To: Ranjeeth Kumar
Thunga
<>,
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
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
Subject: Re: [humanmarkup-comment] Base
Schema-HumlCommIdentifierAtts(attribute)
From: Rex Brooks
<>
To: Ranjeeth Kumar
Thunga
<>,
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
<>
To:
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
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:]
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>
Next in thread →
Next in month →