RE: HM.VR_AI: Goals and Overview : HumanML_VR_AI Facilitator

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

Yes.   That enables the linking and development of the code sets for each 

application.   It isn't exactly *completely* open to the interpretation of the developer.

The missing part is the abstract types of which type = Happiness would be a member.   That lets you

group these definitions for a common interpretation.   Perhaps we should look at the abstract types

and inquire if what we have is workable or adequate.  We have this today

 

<xsd:complexType name="emotion" abstract="true" >

<xsd:annotation>

<xsd:documentation xml:lang="en">

<xhtml:h2>Human Emotion</xhtml:h2>

<xhtml:p>A basic set of primitive human emotions.</xhtml:p>

</xsd:documentation>

<xsd:appinfo>NONE</xsd:appinfo>

</xsd:annotation>

<xsd:attribute ref="intensity" />

<xsd:attributeGroup ref="humlIdentifierAtts" />

</xsd:complexType>

and that is clearly underdefined but in the interest of doing only as much as is needed at any stage of

development, we left it like that until new requirements were presented..   Would the approach you are suggesting in which definitions via xlink to the schema

also enable the abstract context from which the referenced schemas themselves would be derived?   It seems it would.

 

Pesonally, for scale, I prefer a 0 to 1 value instead of 0 to 100 and floating point over integer.  VRML

works like and it allows for interpolation.    Consider a mapping of a scale into a material node that

sets RGB values.  In the draft we have the intensity attribute which was criticized as inadequate but so

far, I still don't have the arguments for that position. 

 

Grouping movement using

 

<xsd:complexType name="kinesic" abstract="true" >

<xsd:annotation>

<xsd:documentation xml:lang="en">

<xhtml:h2>Kinesic: Human Movements</xhtml:h2>

<xhtml:p>A vocabulary of body language. used to portray moods and emotions

and to emphasize or contradict what is being said. An example is an interview.</xhtml:p>

</xsd:documentation>

<xsd:appinfo>NONE</xsd:appinfo>

</xsd:annotation>

<xsd:attributeGroup ref="humlIdentifierAtts" />

<xsd:attribute ref="intensity" />

</xsd:complexType>

isn't fully developed.   Again, given the xlink, this core set of schema types should be accounted

for and we should ask how "thin or thick" we need these to be. 

 

len

-----Original Message-----
From: Kurt Cagle [mailto:kurt@kurtcagle.net]

...  the definition of happiness in any context is going to be extraordinarily difficult. It almost makes me wonder whether instead of arguing over level we should instead define some form of context:

 

<happiness level="ecstatic" xlink:def="http://www.hml.org/schemas/happiness/tokens"/>

 

where xlink:def would in turn point to a specific schema instance  <snip/> 

 

 

 This gives us a mechanism for bypassing all of the potential arguments about HumanML -- the element names and structure fall under the context of the HumanML, but the interpretation of these names become a matter for the application developer.