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

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

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


Subject: Re: HM.VR_AI: Goals and Overview : HumanML_VR_AI Facilitator


I should clarify that we will need support for  both a numeric (not Borg only)  value, AND human readable value.  But the values need to "mean" something tangible across all human cultures as Len mentions.

Rob

"Bullard, Claude L (Len)" wrote:

There could be cases where that is right and a numerical value is the easiest way to express the needed attribute.  In other cases (see previous post), an interpretable value such as "wry" is needed because the style of expressing the intent is unique to the object expressing it.   We see this all the time in geographic information systems that use a small set of geometric types to build up to features and these are then given local names.  The same problem exists in space/time coordinates where computers may rely on UTC but the user relies on Central Standard Daylight time plus 24 hour clock.    The configuration of the local receiving system to process the message received using a recognized code and a mapping to the local system meaning or rendering is fundamental.   The issue of course, is that the top level codes should mean the same thing in any place encountered.   That is why we use the abstract types to derive local types and a chain of descriptions for interpretation (a weak ontology is a thesaurus).len
-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Monday, October 08, 2001 3:46 PM
To: Ranjeeth Kumar Thunga; OASIS Comment
Subject: Re: HM.VR_AI: Goals and Overview : HumanML_VR_AI Facilitator
 
Oh For Joy, For Joy! A legitimate disagreement, and I couldn't disagree more. We absolutely must have numerical values as datatypes for many of our elements, particularly the complexClass(es) which will need to deal with a spectrum of values and % or cm or in are all human readable anyway. The simpleClass can be smile/not smile or expression/lack of expression, and that's one level. But smile to be useful for VR, for instance, has to be valued or weighted as to how much of a smile it is to be portrayed as if it is to translated to middleware thence to X3D or any other 3D file format. BTW, it's about time we started having this kind of discussion.


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


Powered by eList eXpress LLC