RE: [humanmarkup-comment] HM.diplomatic_communications.requiremen ts

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

First, cultures, media types, ideologies, etc. are domains of codes. 

One can define the domain in terms of its codes.  Code systems

are synonymous with vocabularies.

Codes have sign systems that have both signs and rules for combining

the signs correctly.   The rules include structural rules (grammar, syntax)

and linguistic rules (which combinations of signs make "sense" or

convey a useful relationship).

 

One has to note that analysis of communication behavior, that is to infer intent, requires

analysis of the source's decisions of code choices, perhaps within the framework of

the communication protocol, or in short, why was a particular code or sign 

chosen among others.  A coding protocol sets expectations and the

the codes used should not violate expectations.  If they do, then it is time to

evaluate and perhaps, renegotiate.   At the very least, a surprise should be

responded to with "What?" unless conveying surprise is part of the

code.  Otherwise, surprise creates semantic noise.  

 

Aspects of code use that can create semantic noise are such things as:

 

1.  Competence.  Is the code user capable of using the code correctly

(according to the rules for the code).   This is both selecting the

correct code and interpreting a code correctly.

 

2.  Emphasis.  Is the code emphasizing the right part of the message.

 

3.  Attitude toward other party(ies).  Does the attitude of the user include such preconceptions

as dominance over the receiver or vice versa?

 

4.  Attitude toward message.  Perceived value of message.

 

First you need the codes themselves.   The use of HumanML should enable

the formal construction of these codes with container domains that can

be invoked to create the right "inflection" for the message as well as

aid in interpretation and analysis.

 

len

From: Joseph Norris [mailto:jwnorris@humanmarkup.org]

Dear Ranjeeth and Everyone,

 

I think should start DipCon work by drafting a formal requirements document. The rationale for this is twofold: 1) we can jumpstart new research and collate older work and 2) we can assure that the needs of DipCon work are taken into consideration.

 

Ranjeeth's discussion about the complexities of processing, tagging, and interpreting intentions is a good example of how we need to concurrently harmonize expectations of the main body of current research (eg Base Schema) with the future needs of DipCon.