← Prev in month
← Prev in thread
[humanmarkup] PBS-Doc-intent
Title: 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>
← Prev in month
← Prev in thread