[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [humanmarkup-comment] Base Schema-HumlCommIdentifierAtts (attribute)(was Base Schema - Intention)
(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> --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.384 / Virus Database: 216 - Release Date: 8/21/2002
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC