OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [humanmarkup] Re: PBS-Doc-intent(commentary)


Title: [humanmarkup] Re: PBS-Doc-intent(commentary)
This is all fine and there is nothing in the current description of the complexType  intent that disallows any of these conditions. As of now the primary or primitive has the <xs:attribute ref="intensity"?> which takes our 0-1 decimal range datatype, and also has the  attributeGroups humlIdentifierAtts, humlCommAtts and humlTemporalAtts. No elements within the type have been specified, since that is the work of the Secondary Base Schema. We have what might be a somewhat undesireable mix of more and less specified complexTypes a few global attributes and one specific datatypes. It is interesting that you chose employment in this example because that is the one element of our Individual Human and Identity Section that I will be advising us to provide a primitive for, but so far, outside of belief and intent, we have most the fields we need with base primitives covered.

Your timing is pretty good too. I just finished the raw first pass and so you haven't actually posted too soon, even though I haven't released the schema yet. I have gotten through that stage. So don't toss this out of your out box yet, you may want to bring it back up in the next few days as we go through tweaking out a working first draft we can release and announce. You've only done what I know several others have been itching to do.

Maņana,
Rex

At 4:56 PM -0700 10/23/02, Kurt Cagle wrote:
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: humanmarkup@lists.oasis-open.org ; cognite@zianet.com ; clbullar@ingr.com ; kurt@kurtcagle.net ; mbatsis@netsmart.gr
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 <
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    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 <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