Re: HM.VR_AI

[Rob Nixon <robnixon@execpc.com>]

Ranjeeth,

Yes, I agree.  It's important to use element/attributes that are human readable ( and not Borg only readable ).  The numeric values would happen under the hood...    It could be that we would have "general" emotional descriptors that act as a more global description like <emotional state="ecstacy"> that would contain an implicit <smile width="wide"> (and <eyes="closed"> .  Setting the <smile width="smirk"> would in this case over ride the implicit <smile width="wide">.

I could foresee a "stream" of complex changing "emotional" attributes.... that we may wish to capture, for example, where you see <emotional state="suprise":[2sec],"concern":[5sec],"fright":[10sec]>   (in pseudo code) this incorporates chromemics into the state stream.  It may be that we define a series of single state names that implicitly contain these transitional lists.

Rob

Ranjeeth Kumar Thunga wrote:

BTW, thanks very much Rob for this proposal document.  This can help us piece together lots of the information we've been discussing related to VR and AI topics. What I feel as an important litmus test to 'where HumanML' belongs amongst other processing and rendering languages is that the element/attribute values are to human readable. For example, <happy level=".434"/> would not be acceptable, whereas <happy level="ecstacy"> might be.  Or <smile width="53%"/> may not be acceptable, but <smile width="5in"/> would be, or perhaps <smile width="wide"/>. This would very importantly apply to proxemics and chromemics. This ensures that HumanML values are in fact, what we as humans use, matches its stated purpose of not being an interface on the 'human' layer, not layers below.   Regardless, mappings between machine sensible markup, and human sensible markup, could be formally and explicitly described in code, or either custom or standard XSLT.  Ranjeeth Kumar Thunga