humanmarkup message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [humanmarkup] Preliminary Base Schema - intent discussions
- From: Rex Brooks <rexb@starbourne.com>
- To: humanmarkup-comment@lists.oasis-open.org, humanmarkup@lists.oasis-open.org
- Date: Thu, 17 Oct 2002 06:23:59 -0700
Title: Preliminary Base Schema - intent
discussions
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 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 <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 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 <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 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>
--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC