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

[Rex Brooks <rexb@starbourne.com>]

Title: RE: HM.VR_AI: Goals and Overview : HumanML_VR_AI Facil

Kurt, this is excellent. Now if only I could have received this before I sent my last missive...

Oh well.

Ciao,

Rex

At 4:29 PM -0500 10/8/01, Bullard, Claude L (Len) wrote:

> A union is a good solution. 
> Excellent.
>  
> len
> > -----Original Message-----
> > From: Kurt Cagle [mailto:kurt@kurtcagle.net]
> > Sent: Monday, October 08, 2001 4:11 PM
> > To: humanmarkup-comment@lists.oasis-open.org
> > Subject: Re: HM.VR_AI: Goals and Overview : HumanML_VR_AI
> > Facilitator
> > If I may make a suggestion
> > here ...
> >  
> > It is not uncommon for
> > schemas to define a union of two or more differing types, one a set of
> > enumerations, the other a numerical value. Thus you could
> > have:
> >  
> > <happy
> > level="0.245"/> and <happy
> > level="amused"/>
> >  
> > The specific token set for
> > <happy> would then run something like:
> >  
> > none|amused|excited|ecstatic|[0,1]
> >  
> > It would then be the
> > responsibility of the implementer to set numerical equivalences for
> > the named tokens. This is typical of other specifications such as
> > CSS.
> >  
> > -- Kurt
> >  
> >  
> > > ----- Original Message -----
> > > From: Rex
> > > Brooks
> > > To: Ranjeeth Kumar Thunga ; OASIS
> > > Comment
> > > Sent: Monday, October 08, 2001 1:45 PM
> > > 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.
> > >
> > > Ciao,
> > > Rex
> > >
> > > At 4:31 PM -0400 10/8/01, 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
> > > >  
> > > > ----- Original Message -----
> > > > > From: Rex
> > > > > Brooks
> > > > > To: Bullard,
> > > > > Claude L (Len) ; rnixon@qdyn.com
> > > > > Cc: OASIS
> > > > > Comment
> > > > > Sent: Friday, October 05, 2001 7:02 PM
> > > > > Subject: RE: HM.VR_AI: Goals and Overview :
> > > > > HumanML_VR_AI Facilitator
> > > > >
> > > > > Sorry, part of that was my contribution and the two parts
> > > > > of sentence didn't marry up completely. the structured approach refers
> > > > > to our use of xml and rdf schemata in our primary work, and our
> > > > > ongoing investigation of EMOTE work and Project Oz and Perlin's work,
> > > > > and now Rob's work in AI such that they tell us what requirements they
> > > > > need and we see if we can accommodate it or at least not create
> > > > > outright contradictory vocabularies. These bridges are the middleware
> > > > > which will use HumanML to do work with the lowerlevel languages like
> > > > > X3D/h-anim with and apart from MPEG-4 and SMIL and SOAP and
> > > > > OIL.
> > > > >
> > > > >
> > > > > Is that a little more clear?
> > > > >
> > > > > Ciao,
> > > > > Rex
> > > > >
> > > > > At 2:56 PM -0500 10/5/01, Bullard, Claude L (Len)
> > > > > wrote:
> > > > > > I don't understand the following. Please
> > > > > > clarify:
> > > > > >  
> > > > > > "To be prepared for this, we are
> > > > > > establishing a structured approach to provide for making HumanML
> > > > > > readily useful for applications that bridge the "real" and
> > > > > > "virtual" worlds can experience a potential imbalance in
> > > > > > available attributes, and it may be necessary to provide a mechanism
> > > > > > to adjust the mapping of attributes from the virtual to the real.
> > > > > > "
> > > > > >  
> > > > > > Also note that both chronemics and
> > > > > > proxemics have scale issues.    Personal real time and
> > > > > > historical time have their analogues in spatial dimensions which
> > > > > > include
> > > > > > both personal space and geographic space. 
> > > > > > In the case of proxemics, I anticipate the use of concepts and data
> > > > > > objects from the Geometry Modeling Language
> > > > > > for position-dependent services involving
> > > > > > geometric space.
> > > > > >  
> > > > > > len
> > > > > > >  
> > > > >
> > > > >
> > > > > --
> > > > > Rex
> > > > > Brooks
> > > > > GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> > > > > W3Address: http://www.starbourne.com
> > > > > Email: rexb@starbourne.com
> > > > > Tel:
> > > > > 510-849-2309
> > > > > Fax: By Request
> > >
> > >
> > > --
> > > Rex
> > > Brooks
> > > GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> > > W3Address: http://www.starbourne.com
> > > Email:
> > > rexb@starbourne.com
> > > Tel:
> > > 510-849-2309
> > > Fax: By Request

-- 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com

Tel: 510-849-2309
Fax: By Request