----- Original Message -----
Sent: Tuesday, October 09, 2001 10:57
AM
Subject: RE: HM.VR_AI: Goals and Overview
: HumanML_VR_AI Facilitator
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
... 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.