I thought it would be a good idea to make some things
clear about my postings that took place last week.
First of all, i'm sorry if it seems that get too
personal and exited (that goes mostly to Len), but
believe me, i have the best intentions. I do respect
everyones opinion although i may not agree with it.
The reason for all this is my beliefs on what we're
trying to accomplish here, meaning that whatever kind
of methodology coming from this list could be usefull
for a variety of things.
I really think we can make a difference here, in many
areas. Maybe some of us will focus their efforts in
specific things but then again thats the whole module
idea.
Um, thats all :-)
Now why do we have this pause today? I've seen no new
messages...


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/

Ok i'll stop been the practical idiot (for now).
Before we go on with our first module though, i have
to agree with Sean:
>      :smile :gestureOf :happiness .
>
> Clears that up. Emotions are universal throughout
> humankind, whereas
> gestures to portray those emotions aren't. Gestures,
> therefore, are a sub
> component module of emotions, perhaps

Exactly. IMHO, the above relationship becomes solid
just by having the emotion in it. If we try something
like:
:smile :gestureOf :Manos
We don't know why i'm lauphing. It doesn't even make a
usable sence for us.
At first I thought it was better to built a module
based on emotions instead of gestures (gestures seemed
too media dependent at first but i thought it over and
saw i was mistaken) , but maybe it's a good idea to
try and make both at the same time. I'm sure one
module will help making the other.
Finally, please consider making everything without
thinking of specific rendering. We should provide a
data wrapper not an application server for
presentation. Thinking of presentation cases makes as
loose our focus i think.



__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/

At 11:21 AM 16/02/2001 -0600, you wrote:
>That is a behavior. It is perfectly straightforward create the
>markup with an X3D avatar.  It isn't an annotation.

Yes. We must be careful to differentiate between ordinary actions that have
little emotional component and expressions of emotion or intention.


>"My darling, I love you lots", is just text.
>The rendering markup might be done with an ADSR
>markup.  The emotional markup? Well, what
>do you mean by that?  Or, what do you want
>the physical representation to DO with that
>and really, which physical representation.

Actually this one is a lovely example of something that could be enhanced
with humanML.
<sarcasm>"My darling, I love you lots"</sarcasm>
<adoration>"My darling, I love you lots"</adoration>
<bored>"My darling, I love you lots"</bored>
couldn't be more different.

Cheers,
          - Miriam

Yup i know about avatars (been in cybertown!) and i
really love manga (do they still cut pieces of these
before bringing them in europe?).

Your idea sounds great at first glance, but at this
point it has the folloing problems:
First of all, in the best possible situation, all you
can do is bringing real life communication problems
(based in different interpritations of a gesture) into
cyberworld. The best thing is just incorporate a very
small set of simple gestures to be triggered by words
like "bye" (waves hand) and the like.

Secondly, people aren't ready for this. VR i mean.

...the worst thing in humanity's history, was
the day evolution adopted money for it's motor,
instead of common good.

I saw the pics, seem like the best set of gestures to
use for avatars. Same as smileys.

Beyond that point
though, things get mixed up. For example,
>[:^)
means "too much TV" for me (from the head antena) but
"alien" for someone else. We can't clean this up at
this point :-(

> We'll start off with gestures (10 simple facial gestures):
>    smile [...]
>    raise eyebrows [...]

This is a good start. I suppose people may interpret facial gestures
differently, so it might be good to tie them up in the context with which
they will be used; like Len's little diagrams. I would have thought a smile
is pretty universal, but even that might not be. Still:-

      :smile :gestureOf :happiness .

Clears that up. Emotions are universal throughout humankind, whereas
gestures to portray those emotions aren't. Gestures, therefore, are a sub
component module of emotions, perhaps (feel free to debate that, it's an
important thing to get settled at this stage, IMHO).

Once again, this is a good effort. We need single names, and some type of
prose description of them... the porting to other langauges can then
follow. Thus, "raise eyebrows" becomes "raiseEyebrows", and has some form
of formal definition related to emotions. Then you can incorporate it into
a namespace with multiple schema implementations.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
[ :name "Sean B. Palmer" ] :hasHomepage <http://infomesh.net/sbp/> .

>And therefore, "the call is from pragmatism... will you accept the
>charges?". If HumanML is not focussed and structured from the very
>beginning, some will abandon it before it is even started: the
>principal
>thing you want to look towards doing is creating something of
>substance. An
>element set would be a good thing to work on.

You are right.  We must think in concrete something of substance, in
a modularized fashion.  The deeper interrelations can be dealt in
future discussion.

We'll start off with gestures (10 simple facial gestures):
    smile
    wink
    raise eyebrows
    laugh
    gape
    smirk
    roll eyes
    blink
    avert gaze
    stick tongue out

> Additionally, the subtle conveyance of emotion and expression
> is crucial to the communication process for various people.

And therefore, "the call is from pragmatism... will you accept the
charges?". If HumanML is not focussed and structured from the very
beginning, some will abandon it before it is even started: the principal
thing you want to look towards doing is creating something of substance. An
element set would be a good thing to work on.

Expression of data is what XML is all about. This is an element set that
could be integrated into many XML langauges: i.e. as an external module.
Therefore, modularize it, and provide multiple interoperable
implementations; you can then let the PR speak for itself.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
[ :name "Sean B. Palmer" ] :hasHomepage <http://infomesh.net/sbp/> .

Manos:  I think we may be grossly underestimating the importance of
emotion subtleties.  Certainly explaining or clarifying the logic of
a human communications string is very important.  However, a
fundamental reason for interpersonal conflict is because emotions and
expressions are not clearly or fully expressed between parties.
Certainly read Miriam English's posting for illustrations of
intercultural problems from subtle differences in our gestures.

Additionally, the subtle conveyance of emotion and expression is
crucial to the communication process for various people.  This is of
of *fundamental* benefit to the artist, writer, or (3d renderer) who
attempts to convey very specific moods and feelings.  Human
communication spans logic, thought, clarity, and emotion.

Len:  I see what you are saying makes sense.  The scope can easily
run away from us.  To clarify the scope of your individual interest
(correct me if I am wrong):

-----------------------------------------------------------
Expressions/Gestures, Emotions, Higher Level Emotions and Repertoires
:  Span your (immediate) needs and interests

-----------------------------------------------------------
Deeper human qualities, communication constructs, scenarios
:  Do not span your (immediate) needs and interests
-----------------------------------------------------------

I would very much like to see this continued on within the
humanmarkup forum, although we may have both reductionist and
holistic approaches within. Certainly there could be an 'emotion'
conceptual container, that includes all of the components of gestures
and lower-level emotions.  This could be utilized in a manner of
containers similar to:


(Meeting (Introduction (Emotion (astonishment (surprise (fear |
joy))))))


The scope is potentially large, but we can tackle things ONE (or TWO)
steps at at time.  With various sets of namespaces framed around
human expression, we can make meaningful achievements that are both
independent and interdependent.


Regards,
Ranjeeth Kumar Thunga
rkthunga@...

Are you familiar with an old Indian story about
a king who receives moksha and determines that
he can now cure all human ailments, clear up
all misunderstandings and begins this project?
In a dream, a god reveals to him an army of
marching ants and as each wave marches past,
the numbers are multiplied by the numbers in
each wave.   Seeing clearly the task he set for
himself, he understood that his enlightenment
was himself, and could not be applied to all
other beings.

I am afraid this scope is greater than can
be measured.   As I mentioned to Manos, you
also have to contend with all of the other
commuication protocols being advanced in
XML.  XML itself does not care how meta
or specific one creates a language;  that is
why some contend there is no meaning to
metadata.  But there is.  It is quite
specific.  Metadata is applied to the
local data to provide additional information
for a processor.  It is apart from the
content or data typically because the use
for it is different.  Some say, orthogonal.

For me, the emoticons are important because
I can see a clear way to use them in multiple
contexts as metadata.  Understanding the application
of XML vocabularies in terms of transforms is
useful here.   Creating protocols that let
others know when to sit or stand in a meeting
is an interesting application.

I preseted emotional markup examples as a clear
if only exemplary means to go from a conceptual
model to a physical presentation.  This is a vital
design problem.

Let us go a little longer on this exploration together.
If it appears to diverge too far from my own interests,
I will leave it to those whose interests are converging
and wish them well.


Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h

The HumanMarkup Endeavor's fundamental purpose is to reduce human
misunderstanding and to enrich human communication.

All our efforts fall along this (ROUGH) spectrum:

individual expressions-->groups of expressions-->emotions-->higher
level containers/repertoires-->deep human constructs/traits----
>formal communication constructs---->scenarios


At this stage, NONE of this is defined or standardized.  ALL of this
falls under the HumanMarkup endeavor, as long as:
1) HUMAN communication is enriched and/or
2) HUMAN misunderstandings are reduced.

(and I'll mention, getting feedback on the entire spectrum is good to
hear--of course, this 'spectrum' is not standard either ;)

>
> This does not mean that we cannot structure
> formal communications using HumanML.  It is
> just that HumanML is designed to express the
> human aspects of that communication.  Formal
> business protocols (meeting behaviors, introductions,
> presentations, etc) are languages that can
> use HumanML.  HumanML should not attempt to
> define these because they will vary enormously
> by locale and custom.  We should not attempt
> to enforce human custom; we should enable
> human customs to be marked then rendered.

Defining formal communications settings is in line with the mission
(to to reduce misunderstanding) and fundamental for discussion.  I
certainly can empathize with your view this top-down approach as
trying to enforce a particular custom.  However, this can be
diminished if we allow for transformations and plug-ins (setting
substitution groups) (scenario plug-ins?) for different settings from
different cultures.

Nonetheless, this does fall into a different scope.

The reason these need to be addressed is that human communication is
a dynamic process, dependent very much on the setting.  It isn't only
an expression, but a set of numerous 'request/responses' between
parties.  While the initial standards may only include a few
standard 'request/response' pairs, these alone can alleviate so much
misunderstanding.

Some benefits from defining formal communication settings:
-members will know what type of response they are asked for
-members will know whose turn it is to speak
-members will know how long their responses should be
-members may want to 'bluff' their emotions during political
negotiations only

In fact, we can substantially benefit from the analogy of XML systems
messaging, currently utilized for automated business to business
transactions.  In current XML e-commerce transaction systems, for
example, specific request/response sequence are formalized very
precisely, ensuring that communication between different systems is
100%.  As we can see, human communication is currently ar more vague
and prone to mistakes than systems communication, and can benefit
much from utilizing such paradigms.

It is very interesting to have your perspective Len.  So far, I have
conceptualized this project on a different level, without attending
to the numerous subtle emotional and expressional compoents within.
However, ultimately, this all falls under the same 'big' umbrella.

---------------
---------------
---------------
Just thinking

Question
Who really is 'emotional standards body'?

The Bhagvad-Gita?
The Dhammapada?
The Bible?
The Psychology Reference Manual DSM-IV?

Answer:
No!  is the humanmarkup group :)

I'm kidding...certainly we have to allow substitution groups for
various paradigms of human expression, based on different beliefs, as
we discussed earlier

--- "Bullard, Claude L (Len)" <clbullar@...>
wrote:
> I see.  You want to define business document
> protocols.  Umm... this isn't the right place to
> do that.  See ebXML, UDDI, etc.  All the elements
> needed to protect your relatives are being
> defined by those parties.

I see you do not get my point the way I intended. This
isn't about bussiness document protocols as you call
them. It's about human markup alright though. Check
the examples at humanmarkup.org, you will find the
simplest use for HumanML: a species of lightweight
datamining in a document.
Thats the kind of simplistic usage that should form
our bases, it's inevitable. And these basic
applications fit bussiness transactions as well as
anything else, thats why I like to refer to them as
basics and thats why a business related example was as
good as any other. My mother served as an example too
i have to add... ebXML? I don't think so.

> I thought this was about Human markup.  The
> examples I was given initially included such
> things as the emoticons.  The discussion to
> date is about that, not contract language
> for business objects in transaction servers.

Agreed. But try making an endeavor like this one
viable, by telling it functions the same way as
emoticons. Of cource you can have a basic module that
covers emotions and it should be considered a "basic"
yes, but this wont promote HumanML the way it
deserves, while the same module covers nothing but a
smallest possible portion of what HumanML can be.
Past that, let me repeat myself again: Our purpose for
starters is to *promote* this XML application we are
trying to define, and we will need real world examples
that are based in areas able to take advantage of our
efforts.

> BTW:  you can't make a business contract simpler
> than the legal terms for the domain of the
> transaction.  You will discover the ontology
> already exists and is authoritatively attested.
> If you don't get a pro, you are doing the same
> thing as attempting to be your own lawyer in a
> court case.   The judge will admonish you not
> to do that for your own good.

Ok, it wasn't the best example, but let's stick to it
for a while:
Thats the reason we need experts from areas outside
our expertise. Besides, who sais metadata have to be
so binary? "Yes|No"? I think something like 'related
case: the grand fraud of house titles' serves the
metadata role as well as "true|faulse".

> A markup language for human actions has to be
> conscripted to the rendering of the actions.

Who said anything about actions? This is about data,
ok, actions can be data, agreed, but this is about
communication enchachment and more.

> Ranjeeth, what are we attempting to design?

With all respect to our fearless leader, this list was
created to "define" an answer to your question.
Manos

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/

I see.  You want to define business document
protocols.  Umm... this isn't the right place to
do that.  See ebXML, UDDI, etc.  All the elements
needed to protect your relatives are being
defined by those parties.

I thought this was about Human markup.  The
examples I was given initially included such
things as the emoticons.  The discussion to
date is about that, not contract language
for business objects in transaction servers.

BTW:  you can't make a business contract simpler
than the legal terms for the domain of the
transaction.  You will discover the ontology
already exists and is authoritatively attested.
If you don't get a pro, you are doing the same
thing as attempting to be your own lawyer in a
court case.   The judge will admonish you not
to do that for your own good.

A markup language for human actions has to be
conscripted to the rendering of the actions.

Ranjeeth, what are we attempting to design?

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Batsis Manolis [mailto:xcircuit@...]

When my mother gets a proposition to sell her house to
someone and reads the contract, she should be able to
find her or the other parties obligations without the
mumbo jumbo. She should also be able to find metadata
or links to explanations to this mumbo jumbo. She
should be confident that she won't be a victim of
fraud.
Thats the simple applications and schemantics we
should define and believe me, even this kind of basics
are of an unimaginable number.

Hopefully *without* diminishing from the exciting discussion ;), I
would like to make transparent our direction, and to evoke feedback,
as we begin the humanmarkup endeavor.

--------
1) PROMOTION

This Yahoo group will serve as the general discussion board, and all
parties are invited.  Certainly everyone interested in developing
this very important endeavor are welcome.  (i.e. pass the word to
your colleagues.)

The plan is to pursue an additional relationship with OASIS to
establish a Discussion List and Technical Committee within.  Starting
today, I begun soliciting support from OASIS members (3 minimum
needed to begin the process).  The primary motive for pursuing this
direction is to establish support and aid in promotion for this
endeavor.

I will also begin to post in different an announcement in other
groups (starting within WAI IG).  There was concern about 'over-
promoting' the endeavor before our infrastructure was established.
However, it was made clear that contributing parties are more likely
to be interested at an early stage.

2) WEBSITE

We have a website called humanmarkup.org, which will serve as our
general information and promotion site.  It provides some
introductory statements and examples.  Although I have been in the
Internet field for a while on the back-end, this is my first hands-on
web design.  Thus, forgive my 'spaghetti HTML'. ;)

I will be making modifications on a continuing basis.  A couple of
colleagues in the US and India (and one in Greece ;)) have expressed
interest in site maintenance and upgrade.    This is the group's
site...please feel free to contribute ideas or skills.

3) CONTRIBUTIONS

Although I am officially the founder, I may end up not being the lead
contributor.  Everyone feel free to speak on behalf of this endeavor--
as long as the words 'XML' and 'Human' are used in your description,
that should be cover it ;).  Certainly feel free to contact parties
that may have a deep interest...yes the scope is very broad, but ALL
of it is unexplored territory.

I have been in contact with various professionals in different areas
(focusing on parties with an understanding of human conflict and
misunderstanding) and received different levels of responsiveness.

It is a new concept for almost everyone, and difficult for many to
establish a 'mental link' between human expression and XML.  However,
so many of the analogies can be made between current XML system-to-
system communication that can greatly enhance to human-to-human
communications (as Sanjiv Devraj helped me see--who btw came up with
the name 'humanmarkup' ;)).

Parties that are important to have in the loop are experts in various
domains of human communcations, human expression, and XML.  I will
continue to establish relations with these parties and continue
outreach as well.

--------
Do provide steering feedback and direction, from your vantage points.

-------
Regards,

Ranjeeth Kumar Thunga
rkthunga@...

--- "Bullard, Claude L (Len)" <clbullar@...>
wrote:
> That is a behavior. It is perfectly straightforward
> create the
> markup with an X3D avatar.  It isn't an annotation.
> It is a result of a tranformation into a physical
> rendering.
> XML can do that fine.    We only have to go from
> annotation
> to the rendering.
>
I'm sorry friend but what does behavior mean?
From my point of view, a behavior is a certain
reaction
  to an also specific event. Thats a behavior.
Past that, I think we are loosing the point here. We
should forget rendering. Forget media. These will be
served by HumanML applications. It's not our job.
Period.
What we should do is define what needs definition.
At the same time, we have to forget "possible usage
cases". We need simple real life usability even
*outside* our beloved WWW for a change. Again i have
to become the practical idiot. We need something
viable.
No i can't design metadata that will help interpreting
a novel to cartoon or avatars. It's not what this is
about.
What i can do is this:
When my mother gets a proposition to sell her house to
someone and reads the contract, she should be able to
find her or the other parties obligations without the
mumbo jumbo. She should also be able to find metadata
or links to explanations to this mumbo jumbo. She
should be confident that she won't be a victim of
fraud.
Thats the simple applications and schemantics we
should define and believe me, even this kind of basics
are of an unimaginable number.

--- "Bullard, Claude L (Len)" <clbullar@...>
wrote:
> That is a behavior. It is perfectly straightforward
> create the
> markup with an X3D avatar.  It isn't an annotation.
> It is a result of a tranformation into a physical
> rendering.
> XML can do that fine.    We only have to go from
> annotation
> to the rendering.
>
> The transform requires the author to
> understand/interpret
> that "try to grab" means the avatar makes the motion
>
> and misses (interpretable because the av may be
> uncoordinated for the other av dodges).  The
> text bits are just text-to-voice if audio.  It is
> likely the markup person skips HumanML unless
> HumanML includes <grab>.  I think that overkill
> but that is something to consider.
>
> "My darling, I love you lots", is just text.
> The rendering markup might be done with an ADSR
> markup.  The emotional markup? Well, what
> do you mean by that?  Or, what do you want
> the physical representation to DO with that
> and really, which physical representation.
>
> Conceptual to concrete.  The concepts have
> to be independent of the physical rendering,
> but they must be mappable/transformable into
> a physical rendering or simply be abstractions.
>
> Len
> http://www.mp3.com/LenBullard
>
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h
>
>
> -----Original Message-----
> From: Sean B. Palmer [mailto:sean@...]
>
> To iterate that point, there is a definite scope to
> what can be "brought
> into cyberworld for use by avatars" with
> annotations, and what can't. For
> example, there was a suggestion about using HumanML
> to mark up the script
> of a cartoon. Fair enough, but I want to extend that
> to marking up the
> lyrics of a song I just listened to [1]. Some bits
> are easy enough to think
> of a suitable annotation for:-
>
>      My darling, je vous aime beaucoup.
>
> But we must realise that some aren't:-
>
>      [...] he tried to grab the womans hand, and
> said "here's a ring,
>      it cost a grand", she said "that ain't enough".
>
> Mark that up with XML elements? Please?! As Manos
> points out, some things
> are enhanced by annotations (which is basically what
> HumanML is), and some
> aren't. We must not confuse annotating the things
> that need further
> explanation with those that don't, and furthermore
> the ones that are
> impossible.
>
> [1] Black Diamond Bay, by Bob Dylan.
>


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/

We haven't even started and we really have a big
problem.
Because of the many different levels of abstraction,
it's difficult to define a kind of "generic" HumanML
from it's applications (as WML is an XML application)
For example your
(astonishment (surprise (fear | joy)))
seems generic, but
(joy (smile | eyesWiden | etc))
surely is not, it is aimed in visual media.
Then again, even the first example, is aimed in
sentimental definitions. Whitch brings me to the next
problem.
This endeavor will have to remain in balance to stay
alive and hopefully made it to standarisation.
Many of our base modules should be aimed onto markets
that have the power to support us as a standard.
Although this isn't the perfect situation, i'm sure we
all preffer widespreading humanML through blue collars
trying to use our initiative to make their lives
easier (e.g. by reducing the amount of time they spend
reading bla bla data. They will just find the info
they care about, while eliminating "blured" meanings
-with metadata usage- avoiding visits to court)
instead of spending endless hours to humanmlise a
theatrical play, or trying to explain it's writer how
to do it. Do i sound confusing? I just tried to read
my own writings.
At the same time we have to make two things: Make
HumanML viable and usable by intersted parties that
will support it, while trying to make something good
for the world. Believe me even the stuff we'll use for
the blue collar's stuff will reduce fraud. Isn't that
agood thing?
Then again, we can sit here arguing and wondering if
(joy (surprise (fear | joy)))
-BTW it doesn't seem right to me- is more suitable
than
(happyness (joy(something|something)))
Just my thoughts.
Manos


--- "Bullard, Claude L (Len)" <clbullar@...>
wrote:
> To stay out of the weeds and focus
> (it would be nice not to have to
> play Survivor to get this done), we
> need to first divide the work into
> conceptual and concrete models.  Also,
> we need to limit our model domain.
>
> 1.  The domain is Human Markup.  This
> limits the expressivity to what humans
> do.  No metaphorical relationships
> such as "the happy organization".  If
> we layer this correctly, that will fall
> out and become possible but only by
> aggregation in other namespaces.  This
> makes it easy to work the gestural
> markup design by limiting it to
> gestures humans can make, that is,
> smile, frown, wave, speak, and so forth.
> This means the concrete objects are
> renderable and only have to be referenced
> back to the markup or included as a result
> of a transform operation to enable the
> final application to work efficiently in
> its own language (eg, there is no smile
> element in X3D or SVG and there never will be).
>
> 2.  This means that on the extreme end
> of the conceptual model are the emotions
> or intentions and that these are also
> reusable in higher conceptual models.   We
> can define some emotions as high level
> concepts of more primitive emotions.
> For example,
>
> (astonishment (surprise (fear | joy)))
>
> and so on.  Whether we do this by containment
> of XLink or RDF, is fine.  Schemas are easier.
>
> We can define an emotion
> as a conceptual or container object for a
> set of gestures if we decide that is useful.
>
> (joy (smile | eyesWiden | etc))
>
> and this is transformed into a rendering.
>
> So conceptual to concrete gets us the transform
> path for querying the conceptual model for
> values to pass into the transform to the final
> rendering.  This lets us model the emotional
> progressions or states independent of the
> actual rendering language and rendered object.
>
> We do have the problems of customs and locale.
> This is solvable using abstract types and
> substitution groups, thus, making the language
> extensible.
>
> The emotion elements may be abstract
> elements, non-instantiable because they do
> not affect the rendering.  (Just one approach).
> This would enable us to define substitution
> groups for emotions in terms of variations
> of gestural combinations.   It also allows
> us to get these combinations by loading the
> schema and querying it instead of querying
> the instance.  On the other hand, if we
> want to use transforms on instances, we
> would need these to use the substitution
> group but not be abstract.   Some case
> tests here will be needed to choose the right
> approach.
>
> This does not mean that we cannot structure
> formal communications using HumanML.  It is
> just that HumanML is designed to express the
> human aspects of that communication.  Formal
> business protocols (meeting behaviors,
> introductions,
> presentations, etc) are languages that can
> use HumanML.  HumanML should not attempt to
> define these because they will vary enormously
> by locale and custom.  We should not attempt
> to enforce human custom; we should enable
> human customs to be marked then rendered.
> The humans do the rest.
>
> Len
> http://www.mp3.com/LenBullard
>
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h
>
>

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/

That is a behavior. It is perfectly straightforward create the
markup with an X3D avatar.  It isn't an annotation.
It is a result of a tranformation into a physical rendering.
XML can do that fine.    We only have to go from annotation
to the rendering.

The transform requires the author to understand/interpret
that "try to grab" means the avatar makes the motion
and misses (interpretable because the av may be
uncoordinated for the other av dodges).  The
text bits are just text-to-voice if audio.  It is
likely the markup person skips HumanML unless
HumanML includes <grab>.  I think that overkill
but that is something to consider.

"My darling, I love you lots", is just text.
The rendering markup might be done with an ADSR
markup.  The emotional markup? Well, what
do you mean by that?  Or, what do you want
the physical representation to DO with that
and really, which physical representation.

Conceptual to concrete.  The concepts have
to be independent of the physical rendering,
but they must be mappable/transformable into
a physical rendering or simply be abstractions.

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Sean B. Palmer [mailto:sean@...]

To iterate that point, there is a definite scope to what can be "brought
into cyberworld for use by avatars" with annotations, and what can't. For
example, there was a suggestion about using HumanML to mark up the script
of a cartoon. Fair enough, but I want to extend that to marking up the
lyrics of a song I just listened to [1]. Some bits are easy enough to think
of a suitable annotation for:-

      My darling, je vous aime beaucoup.

But we must realise that some aren't:-

      [...] he tried to grab the womans hand, and said "here's a ring,
      it cost a grand", she said "that ain't enough".

Mark that up with XML elements? Please?! As Manos points out, some things
are enhanced by annotations (which is basically what HumanML is), and some
aren't. We must not confuse annotating the things that need further
explanation with those that don't, and furthermore the ones that are
impossible.

[1] Black Diamond Bay, by Bob Dylan.

> in the best possible situation, all you can do is bringing
> real life communication problems (based in different
> interpritations of a gesture) into cyberworld.

To iterate that point, there is a definite scope to what can be "brought
into cyberworld for use by avatars" with annotations, and what can't. For
example, there was a suggestion about using HumanML to mark up the script
of a cartoon. Fair enough, but I want to extend that to marking up the
lyrics of a song I just listened to [1]. Some bits are easy enough to think
of a suitable annotation for:-

      My darling, je vous aime beaucoup.

But we must realise that some aren't:-

      [...] he tried to grab the womans hand, and said "here's a ring,
      it cost a grand", she said "that ain't enough".

Mark that up with XML elements? Please?! As Manos points out, some things
are enhanced by annotations (which is basically what HumanML is), and some
aren't. We must not confuse annotating the things that need further
explanation with those that don't, and furthermore the ones that are
impossible.

[1] Black Diamond Bay, by Bob Dylan.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
[ :name "Sean B. Palmer" ] :hasHomepage <http://infomesh.net/sbp/> .

To stay out of the weeds and focus
(it would be nice not to have to
play Survivor to get this done), we
need to first divide the work into
conceptual and concrete models.  Also,
we need to limit our model domain.

1.  The domain is Human Markup.  This
limits the expressivity to what humans
do.  No metaphorical relationships
such as "the happy organization".  If
we layer this correctly, that will fall
out and become possible but only by
aggregation in other namespaces.  This
makes it easy to work the gestural
markup design by limiting it to
gestures humans can make, that is,
smile, frown, wave, speak, and so forth.
This means the concrete objects are
renderable and only have to be referenced
back to the markup or included as a result
of a transform operation to enable the
final application to work efficiently in
its own language (eg, there is no smile
element in X3D or SVG and there never will be).

2.  This means that on the extreme end
of the conceptual model are the emotions
or intentions and that these are also
reusable in higher conceptual models.   We
can define some emotions as high level
concepts of more primitive emotions.
For example,

(astonishment (surprise (fear | joy)))

and so on.  Whether we do this by containment
of XLink or RDF, is fine.  Schemas are easier.

We can define an emotion
as a conceptual or container object for a
set of gestures if we decide that is useful.

(joy (smile | eyesWiden | etc))

and this is transformed into a rendering.

So conceptual to concrete gets us the transform
path for querying the conceptual model for
values to pass into the transform to the final
rendering.  This lets us model the emotional
progressions or states independent of the
actual rendering language and rendered object.

We do have the problems of customs and locale.
This is solvable using abstract types and
substitution groups, thus, making the language
extensible.

The emotion elements may be abstract
elements, non-instantiable because they do
not affect the rendering.  (Just one approach).
This would enable us to define substitution
groups for emotions in terms of variations
of gestural combinations.   It also allows
us to get these combinations by loading the
schema and querying it instead of querying
the instance.  On the other hand, if we
want to use transforms on instances, we
would need these to use the substitution
group but not be abstract.   Some case
tests here will be needed to choose the right
approach.

This does not mean that we cannot structure
formal communications using HumanML.  It is
just that HumanML is designed to express the
human aspects of that communication.  Formal
business protocols (meeting behaviors, introductions,
presentations, etc) are languages that can
use HumanML.  HumanML should not attempt to
define these because they will vary enormously
by locale and custom.  We should not attempt
to enforce human custom; we should enable
human customs to be marked then rendered.
The humans do the rest.

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h

Yup i know about avatars (been in cybertown!) and i
really love manga (do they still cut pieces of these
before bringing them in europe?).
Your idea sounds great at first glance, but at this
point it has the folloing problems:
First of all, in the best possible situation, all you
can do is bringing real life communication problems
(based in different interpritations of a gesture) into
cyberworld. The best thing is just incorporate a very
small set of simple gestures to be triggered by words
like "bye" (waves hand) and the like.
Secondly, people aren't ready for this. VR i mean.
Really, they'll just get addicted with a not good
enough technology. Hehe, haven't we already?
Here i want to make a note: i have nothing against
you, don't get me wrong. I'm even sure you have the
best intentions and i loved the way you thought about
this. But the worst thing in humanity's history, was
the day evolution adopted money for it's motor,
instead of common good.
We should try bringing this up one step at a time,
this will help the both technology and people get
mature.
I saw the pics, seem like the best set of gestures to
use for avatars. Same as smileys. Beyond that point
though, things get mixed up. For example,
>[:^)
means "too much TV" for me (from the head antena) but
"alien" for someone else. We can't clean this up at
this point :-(
Last but not least, we all believe HumanML can benefit
from "smiley-like" stuff. And on the "i'm no expert"
frase i can only say this: Who is?
Kindest regards,
Manos

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/

> Manos' question "what is this for?" cuts right to the core of the
> problem I think.

This is roughly equivalent to asking what the scope of the langauge is. I
suppose that the answer is that there isn't one, or more accurately, that
there is a pratical scope, but not a theoretical one. We must be sure that
prgmatism does not get bumped out of the equation - HumanML is *for*
something, but at the same time, we can use our philisophical debates "what
is emotion, how do we represent this best in XML?" to make sure that people
do not implement improperly.

> English seem cold to italians because they stand far apart,
> whereas the english think the italians are being discomfortingly
> over-familiar, invading their personal space.... and so on...

I've heard this is a problem for English businessmen in Japan, where the
"personal comfort zone" is especially small. That that is physical
communication, not written. The whole point is that there is a cultural
eason that the Japanese stand a few inches apart, whereas the English are
uncorfortable within a mile of the nearest human being. That is what we
*need* HumanML for: to point out the differences w.r.t. the reasons.

> Even parents have difficulty communicating with their children...

Everyone has trouble communicating with everyone else... even themselves,
I'm pretty sure. Can you honestly look through all of your previous
correspondance and know precisely what it is you were going on about?
99.999% of the time you can, but opinions change (thankfully, or we'd never
learn), and sometimes it is hard to understand what one has said. Would it
not be earier if there was some way of marking up what your mood was when
you wrote a message?

      I hate you.
      I hate you!
      I hate you :-)

The top one is ambiguous. The second is also ambiguous, but just with more
emphasis. The last appears to be in jest. Emoticons, human symbols of
expression, are very important because the written word is but a fraction
of the ways in which we communicate. Diversifying our written word is an
essential task.

> If we can succeed in making some kind of expression/gesture
> scripting of, say, a Bugs Bunny cartoon, then we would be
> getting somewhere I think.

That would be both fun, and a good test of the langauge. I suppose I'd
suggest using a Simpsons episode because 1) I love The Simpsons, 2) There
is an awful lot of range in the acting... it is difficult to analyze
perfectly, such is the elegance of the scripting.

> I have had the experience of watching Manga cartoons and
> been unable to interpret a particular expression, wondering what the
> japanese artist meant by that.

Exactly.

> I hope my ramble made some kind of sense... :-)

No, it was rubbish.
Am I joking or being sarcastic, or what?  By the time this is through, we
should have some kind of answer.

For the record:-

<philisophical_point>No, it was rubbish.</philisophical_point>

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
[ :name "Sean B. Palmer" ] :hasHomepage <http://infomesh.net/sbp/> .

> Oh yes, RDF. I was thinking about that, it may prove to be
> extremely usefull in defining mappings between similar
> expressions in different languages. I'm talking about a module
> that will help the very poor (even nowdays) automated translation
> sector.

Actually, I mentioned on RDF IG about using RDF for translating an error
that BanBri had made. That could be applied to automatic translation, but
it's one of those things that is permenently six months away...

Still, mappings between emotions, thoughts, and feelings should be
possible, but I agree that it is the biggest topic, and perhaps one best
left alone for now.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
[ :name "Sean B. Palmer" ] :hasHomepage <http://infomesh.net/sbp/> .

--- "Sean B. Palmer" <sean@...> wrote:
> > Thats why we shouldn't define the "areas" i
> mentioned thinking
> > in one flat level. I hope I'd making sense.
>
> Absolutely. We were both pointing out different
> facets of the same type of
> interoperability... in other words, you say that
> metadata not be
> constrained to being linear (if I understand you
> correctly), and I say that

Absolutely.

> there is no dichotomy between metadata and data (but
> at the same time,
> there is). Same thing really.

Again we have the same view :-)

> The whole world is not going to be using
> "triples", or even XML... but they are going to be
> using names, and they
> are going to be using URLs. We can monopolize on
> that fact with HumanML.

Oh yes, RDF. I was thinking about that, it may prove
to be extremely usefull in defining mappings between
similar expressions in different languages. I'm
talking about a module that will help the very poor
(even nowdays) automated translation sector. From what
i've seen (i've never used RDF) the damn thing just
doesn't stabilise, or at least that is the picture i
get.


>
> > IMHO, "humanmarkup" should be divided into modules
> > after some work takes place.
>
> Yes, I very much agree with you here. Ranjeeth has
> already broken up some
> of the elements that he has been working on into
> groups, and I expect more
> divisions of that to come. The thing to concentrate
> on is not the elements
> themselves (I call them elements, but perhaps a
> better word would be
> "term"), but the relationships between them. I often
> call that
> "ontologies", but Len uses the word in a different
> sense to I, so perhaps
> I'd better stick with the word "relationships" on
> this list. :-)

Big subject, i'll leave it alone for now...

> > I was really glad to see your post in this list. I
> have
> > been reading your posts elsewhere for sometime.
>
> It's nice to know that at least somebody reads them!
> I was glad to see
> another friendly name here too (I think we chatted
> on www-style before
> now).
>
  I believe you are right.

Regards,
Manos

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/

Hi everybody,

I am no expert, and I am only in this because it may give me some ideas on
how to incorporate useful expressions and gestures into the simple language
I am trying to put together to describe avatar actions. (An avatar is the
body you wear in virtual reality.)

Manos' question "what is this for?" cuts right to the core of the problem I
think.

Ranjeeth was saying that it would be cool to develop a language that all
people could use to find common ground for non-verbal communication. The
idea being to supplement the words we already have, and make them more
effective.

This is a heck of a problem because of the different customs that various
cultures have. Like most of us here I have heard of some examples of how
miscommunication can occur BECAUSE of different interpretations of
non-verbal communication: westerners can think some asians are being
evasive because they won't look them in the eye, while those asians think
the westerners are being too confrontational and rude seeming to want to
stare them down. English seem cold to italians because they stand far
apart, whereas the english think the italians are being discomfortingly
over-familiar, invading their personal space.... and so on...

Actions don't always help communication -- they can worsen it.

But all of us have had the problem where something we said in text was
misunderstood because the written words didn't carry the writer's tone,
expression and gestures.

Actions can, in many cases, add a lot to what is said... we just have to
find some kind of common ground that is not contaminated with cultural
bias... or perhaps find some way of writing the bias in, so that a person
talking to someone of another culture has their actions translated to
something appropriate for the person of the other culture.

The most capable people for that task would be people who have a foot in
more than one culture -- people who speak more than one language. They may
have some ability to translate what is polite or concerned or rude or
supercilious behavior.

However it is not even that simple --  within just one culture there can be
an incredible array of different understandings of what is polite behavior.
Even parents have difficulty communicating with their children...

It occurs to me that one way to find some common ground is in looking at
caricatures. Cartoons seem to amplify the essence of emotions. If we can
succeed in making some kind of expression/gesture scripting of, say, a Bugs
Bunny cartoon, then we would be getting somewhere I think.

Of course even cartoons with their caricatured emotions don't completely
solve the problem. I have had the experience of watching Manga cartoons and
been unable to interpret a particular expression, wondering what the
japanese artist meant by that. Translation to different cultural contexts
will still be important. However, on the whole, cartoons seem to reduce
actions and expressions to their most fundamental level, and may be a good
place to start.

I have put a page of drawings by Preston Blair (one of my favorite
cartoonists) up here:
http://members.optushome.com.au/miriame/expressions.html

It might prompt thoughts from someone else on this matter.

I hope my ramble made some kind of sense... :-)

Cheers,

          - Miriam



Q. What is the similarity between an elephant and a grape?
A. They are both purple... except for the elephant.
---------=---------=---------=---------=---------=---------=------
http://werple.net.au/~miriam
http://members.optushome.com.au/miriame
Virtual Reality Association  http://www.vr.org.au
Part of the development team for http://escape3d.com

> Thats why we shouldn't define the "areas" i mentioned thinking
> in one flat level. I hope I'd making sense.

Absolutely. We were both pointing out different facets of the same type of
interoperability... in other words, you say that metadata not be
constrained to being linear (if I understand you correctly), and I say that
there is no dichotomy between metadata and data (but at the same time,
there is). Same thing really. The whole world is not going to be using
"triples", or even XML... but they are going to be using names, and they
are going to be using URLs. We can monopolize on that fact with HumanML.

> IMHO, "humanmarkup" should be divided into modules
> after some work takes place.

Yes, I very much agree with you here. Ranjeeth has already broken up some
of the elements that he has been working on into groups, and I expect more
divisions of that to come. The thing to concentrate on is not the elements
themselves (I call them elements, but perhaps a better word would be
"term"), but the relationships between them. I often call that
"ontologies", but Len uses the word in a different sense to I, so perhaps
I'd better stick with the word "relationships" on this list. :-)

> I was really glad to see your post in this list. I have
> been reading your posts elsewhere for sometime.

It's nice to know that at least somebody reads them! I was glad to see
another friendly name here too (I think we chatted on www-style before
now).

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
[ :name "Sean B. Palmer" ] :hasHomepage <http://infomesh.net/sbp/> .

--- "Sean B. Palmer" <sean@...> wrote:
> ... and you can quite easily encode a small
> proportion of universal human
> knowledge into a namespace, and ask people to use it
> (Dublin Core have been
> doing this for years).

I believe this is the common intention.

> Also, I believe that the distinction between data
> and metadata is an undue
> dichotomy here. It is neither metadata nor metadata,
> but both at the same
> time.

Perfectly understandable. Thats why we shouldn't
define the "areas" i mentioned thinking in one flat
level. I hope I'd making sense.

> > <Contract
> > xmlns="urn:human-markup.org/contract"
> > xmlns:insurance="urn:human-markup.org/insurance"
>
> Could we not use an HTTP URI (or any URL) for the
> HumanML namespaces, in
> case someone/something actually wants to find out
> what these things mean...
> URNs aren't great for storing data :-)
>

Of course thats the logical and only usable case. I
just typed URNs for no reason at all :-)

I've been thinking that the only way to go is, provide
some schema development covering basic elements of
communication and some others covering areas of our
expertise. That way we can define some guidelines and
call for further independent input. This is too big
for our number to handle all the way. Besides, as you
said (or more suitably, what comes from your comments)
we shouldn't and I find myself sharing your view.
We should provide something everyone can tailor to his
needs while making sure everyones (meta)data works
with anybody else's.

IMHO, "humanmarkup" should be divided into modules
after some work takes place.
The only thing we don't have to think of is
presentation. The technology is already there for
everyone to use, for example CSS has enough power to
handle this.

I was really glad to see your post in this list. I
have been reading your posts elsewhere for sometime.

Kindest regards,
Manos

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/

From: Batsis Manolis <xcircuit@...>:-

> we cannot design and stadnarize metadata suitable for every one

And nor should it be our intention of doing so. However, XML architecture
for the most part consists of basic markup data encoded to its rigourous
BNF. Elements, attributes and namespaces are what XML primarily consists
of: and you can quite easily encode a small proportion of universal human
knowledge into a namespace, and ask people to use it (Dublin Core have been
doing this for years).

Also, I believe that the distinction between data and metadata is an undue
dichotomy here. It is neither metadata nor metadata, but both at the same
time.

> <Contract
> xmlns="urn:human-markup.org/contract"
> xmlns:insurance="urn:human-markup.org/insurance"

Could we not use an HTTP URI (or any URL) for the HumanML namespaces, in
case someone/something acutally wants to find out what these things mean...
URNs aren't great for storing data :-)

BTW: "schemantics" - great new word!

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
[ :name "Sean B. Palmer" ] :hasHomepage <http://infomesh.net/sbp/> .

I believe that we cannot do everything at once. We
have to brake this into small pieces, meaning that, we
cannot design and stadnarize metadata suitable for
every one.
Although the reason i joined this endeavor is the
principal purpose of humanmarkup.org, things don't
work this way. Most of us are lookin at the forest but
this time, we should land and take a closer look at
each tree.
What i mean is, beside of some basics suitable for
most areas, each one should have it's own schemantics,
depending on a really big unpredictable variety of
factors.
Now to define "area", i simply mean a market area, or
a praxis area or whatever. Areas should be devided
into different levels.
For example, it sure is a lot clearer and easy to
define a set for metadata suitable for contracts. All
contracts should have the same basic namespace, while
using additional namespaces for every occasion.
Thus, a contract, depending on the "area" it is about
should end up using the essential additional
rescources:

<Contract
xmlns="urn:human-markup.org/contract"
xmlns:insurance="urn:human-markup.org/insurance"


Or whatever. The problem is, defining these areas and
their structure, while trying to define a basic set of
schemantics for each kind of usage such us a contract,
a speach, a memo etc.
This will allow as to build usability based on use,
while covering every possibility simply by calling
additional sets.
The difficult part is to design these additional sets
because we need experts from each field to do that.
In the end, it all comes down to "what is this for?"
and we should be able to give a really good answer
like "everything possible current or future
communication" to standarize HumanML.
Sorry if i sound confusing, i had only a couple of
minutes to write this, while my english arekind of
rusty to say the least :-)
Just my thoughts, please do give some comments.
Manos

--- "Bullard, Claude L (Len)" <clbullar@...>
wrote:
> We need to be able to use emotional or expressive
> markup in many different contexts.  While the
> surface idea is easy, this could be one of the
> most challenging markup languages ever devised
> because it must enable enormous freedom of
> interpretive rendering, yet operate reliably.
> Further, it should be a simple framework.
>
> Challenging indeed.  Noodling here...
>
> IMO, this is an issue of appropriate layers of
> abstraction to
> use and reuse the markup.   We may find, for
> example,
> that concepts such as a unit of comunication can be
> named, but may actually contain the same kinds of
> tags as are in SMIL; pars, seqs, etc.    The problem
>
> of integration is the overlapping semantics among
> the different MLs at this time.  At some point,
> we may want to carve off a manageable piece
> to work on (bray's minimal victory approach) but
> for now, we should consider all the aspects of this.
>
>
> The rendering activated by the emotion has to
> be independent of the emotional description.
> At this time, it is a challenge to conceive of
> emotions
> at levels deeper than say RDF might enable
> one to describe: that is, as a named relationship.
>
>
> For humans, emotions are emergent, that is, an event
> or set
> of events may cause a given agent to experience an
> emotion and
> the emotional experience gives rise to some
> set of rendered gestures (a smile, a frown).
> But modeling internal human states is very
> challenging, perhaps, too challenging to be
> done by consensus.   Describing some set of gestural
>
> events is reasonably easy.
>
> We can mark text for interpretation, but
> the actual mapping back to the rendering
> depends on the repetoire of the actor.
>
> What is a good interpretive example?  Anyone
> have a favorite poem, speech, etc. that
> they want to markup emotionally?  Playwrights
> do this.
>
> It is easy to do with music because music has an
> interpretive markup vocabulary.   Note that it
> can be broken down into four components for
> synthesis of individual notes regardless of
> instrument or scale:  Attack Decay Sustain Release
> (ADSR)
> and these translate directly into the MIDI
> rendering as the components of the waveform.
> The actual sonority depends on the
> device (number of oscillators, etc.).
>
> Written over the music, the composer may put some
> phrase such as "slow and elegant" for an entire
> piece leaving it to the player to match that to
> some internal repetoire (chops) to express that
> instruction,
> really, just a hint.
>
> Indian musicians have more formal means.  The
> raga (a scale for this discussion) is combined
> with a component of the timing of entrances and
> cycles
> (roughly, the Tal which a western musician
> translates
> into a time signature)
> with understandings for syncopation.  These are
> bound
> to a bhava or mood (for example, contemplative,
> languid, sometimes denoted with a reference to a
> scene).  Different bhavas can be used and can depend
>
> on other contexts such as the time of day of the
> performance to further shade thebhava.   This music
> is highly improvisational but these three frameworks
>
> are sufficient to enable attentive players to
> play coherently and quite expressively.  Students
> of Shankar note that he often introduces the raga
> by name, bhava and tal, saying something like,
> "the raga is bharaivi, played in a tin tal.  It is
> a morning raga, contemplative and just a little sad"
>
> or somthing like that.
>
> Somewhere on the web, I once found a description of
> the many bhavas.  We may find that instructive as a
> place to begin.  I believe more complex emotions
> (eg, exasperation, astonishment, etc) can be created
>
> from compounds of these.
>
> I hope this doesn't confuse anyone or that I have
> misstated.  The notion is that contexts have a role
> here.  Time, scale, and mood are used in much music
> to denote the interpretive bounds the composer
> intends
> for the piece.  We may find it useful to reduce our
> task to a simple framework such as this to enable
> the greater freedom of expression while enabling
> the interpretive bound of the author to be realized.
>
> Digital performers must also have a freedom to use
> the repetoire created for them, perhaps even to
> improvise within their capability, yet to express
> that which their creators desire.
>
> Len
>
> http://www.mp3.com/LenBullard
>
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h
>
>
> -----Original Message-----
> From: Ranjeeth Kumar Thunga
> [mailto:rkthunga@...]
> Sent: Thursday, February 15, 2001 4:01 PM
> To: humanmarkup@yahoogroups.com
> Subject: [humanmarkup] Re: Out of the Gate
>
>
> It is apparent that different namespaces are crucial
> for representing
> different aspects of human traits.
>
> Based on our earlier discussions, and this thread,
> this is a possible
> breakdown of humanmarkup:
>
> Gestures
>         wave, smile, lit eyes
> Emotions
>         happiness
>
> Unit of communication
>         introduction
>
> Deep human qualities/traits
>         friendliness
>
> Communication settings
>         one-on-one face-to-face
>
> Repertoires (unique combination of the above)
>         greeting
>
> (and any other suggestions that you may have)
>
> The manner in which these interactions may become
> rather complex, as
> Len made clear in his writings.  However, I'm sure
> both Len & Miriam
> have done some thought on this ;), and can
> contribute the necessary
> insight.
>


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/

We need to be able to use emotional or expressive
markup in many different contexts.  While the
surface idea is easy, this could be one of the
most challenging markup languages ever devised
because it must enable enormous freedom of
interpretive rendering, yet operate reliably.
Further, it should be a simple framework.

Challenging indeed.  Noodling here...

IMO, this is an issue of appropriate layers of abstraction to
use and reuse the markup.   We may find, for example,
that concepts such as a unit of comunication can be
named, but may actually contain the same kinds of
tags as are in SMIL; pars, seqs, etc.    The problem
of integration is the overlapping semantics among
the different MLs at this time.  At some point,
we may want to carve off a manageable piece
to work on (bray's minimal victory approach) but
for now, we should consider all the aspects of this.

The rendering activated by the emotion has to
be independent of the emotional description.
At this time, it is a challenge to conceive of emotions
at levels deeper than say RDF might enable
one to describe: that is, as a named relationship.

For humans, emotions are emergent, that is, an event or set
of events may cause a given agent to experience an emotion and
the emotional experience gives rise to some
set of rendered gestures (a smile, a frown).
But modeling internal human states is very
challenging, perhaps, too challenging to be
done by consensus.   Describing some set of gestural
events is reasonably easy.

We can mark text for interpretation, but
the actual mapping back to the rendering
depends on the repetoire of the actor.

What is a good interpretive example?  Anyone
have a favorite poem, speech, etc. that
they want to markup emotionally?  Playwrights
do this.

It is easy to do with music because music has an
interpretive markup vocabulary.   Note that it
can be broken down into four components for
synthesis of individual notes regardless of
instrument or scale:  Attack Decay Sustain Release (ADSR)
and these translate directly into the MIDI
rendering as the components of the waveform.
The actual sonority depends on the
device (number of oscillators, etc.).

Written over the music, the composer may put some
phrase such as "slow and elegant" for an entire
piece leaving it to the player to match that to
some internal repetoire (chops) to express that instruction,
really, just a hint.

Indian musicians have more formal means.  The
raga (a scale for this discussion) is combined
with a component of the timing of entrances and cycles
(roughly, the Tal which a western musician translates
into a time signature)
with understandings for syncopation.  These are bound
to a bhava or mood (for example, contemplative,
languid, sometimes denoted with a reference to a
scene).  Different bhavas can be used and can depend
on other contexts such as the time of day of the
performance to further shade thebhava.   This music
is highly improvisational but these three frameworks
are sufficient to enable attentive players to
play coherently and quite expressively.  Students
of Shankar note that he often introduces the raga
by name, bhava and tal, saying something like,
"the raga is bharaivi, played in a tin tal.  It is
a morning raga, contemplative and just a little sad"
or somthing like that.

Somewhere on the web, I once found a description of
the many bhavas.  We may find that instructive as a
place to begin.  I believe more complex emotions
(eg, exasperation, astonishment, etc) can be created
from compounds of these.

I hope this doesn't confuse anyone or that I have
misstated.  The notion is that contexts have a role
here.  Time, scale, and mood are used in much music
to denote the interpretive bounds the composer intends
for the piece.  We may find it useful to reduce our
task to a simple framework such as this to enable
the greater freedom of expression while enabling
the interpretive bound of the author to be realized.
Digital performers must also have a freedom to use
the repetoire created for them, perhaps even to
improvise within their capability, yet to express
that which their creators desire.

Len

http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Ranjeeth Kumar Thunga [mailto:rkthunga@...]
Sent: Thursday, February 15, 2001 4:01 PM
To: humanmarkup@yahoogroups.com
Subject: [humanmarkup] Re: Out of the Gate


It is apparent that different namespaces are crucial for representing
different aspects of human traits.

Based on our earlier discussions, and this thread, this is a possible
breakdown of humanmarkup:

Gestures
         wave, smile, lit eyes
Emotions
         happiness

Unit of communication
         introduction

Deep human qualities/traits
         friendliness

Communication settings
         one-on-one face-to-face

Repertoires (unique combination of the above)
         greeting

(and any other suggestions that you may have)

The manner in which these interactions may become rather complex, as
Len made clear in his writings.  However, I'm sure both Len & Miriam
have done some thought on this ;), and can contribute the necessary
insight.

It is apparent that different namespaces are crucial for representing
different aspects of human traits.

Based on our earlier discussions, and this thread, this is a possible
breakdown of humanmarkup:

Gestures
         wave, smile, lit eyes
Emotions
         happiness

Unit of communication
         introduction

Deep human qualities/traits
         friendliness

Communication settings
         one-on-one face-to-face

Repertoires (unique combination of the above)
         greeting

(and any other suggestions that you may have)

The manner in which these interactions may become rather complex, as
Len made clear in his writings.  However, I'm sure both Len & Miriam
have done some thought on this ;), and can contribute the necessary
insight.

-------
Ranjeeth Kumar Thunga
rkthunga@...
-------

--- In humanmarkup@y..., "Bullard, Claude L (Len)" <clbullar@i...>
wrote:
> Out of the gate, HumanML should be a set of namespaces,
> not a single schema.  Modularity has to account for
> the different uses.  Gestural markup and emotive markup
> can be applied in different media.   A happy face and a
> smiley are mapped representations for the same emotion,
> but they are not the same representation.  It is useful
> to create a gestural behavior and to denote its emotive
> message, but this is by reference, not containment.
> Further, gestures may be assembled into repetoires
> that are themselves still separated from the rendering.
>
> For example, a play is written for characters that are
> independant of the actors.  The play may contain annotations
> for some gestures, some emotions, etc.  The actor will have
> or inherit a repetoire and these may be quite unique to
> each actor.
>
> For understanding visualization of emotive and gestural
> markup, it is useful to study particular actors and see
> how they assemble their repetoire.  I find a VCR and a
> frame by frame viewing to be most helpful to understand
> timing and details.  This is of course, a specific application,
> but top-down then bottom-up and so forth.
>
> Len
> http://www.mp3.com/LenBullard
>
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h

Out of the gate, HumanML should be a set of namespaces,
not a single schema.  Modularity has to account for
the different uses.  Gestural markup and emotive markup
can be applied in different media.   A happy face and a
smiley are mapped representations for the same emotion,
but they are not the same representation.  It is useful
to create a gestural behavior and to denote its emotive
message, but this is by reference, not containment.
Further, gestures may be assembled into repetoires
that are themselves still separated from the rendering.

For example, a play is written for characters that are
independant of the actors.  The play may contain annotations
for some gestures, some emotions, etc.  The actor will have
or inherit a repetoire and these may be quite unique to
each actor.

For understanding visualization of emotive and gestural
markup, it is useful to study particular actors and see
how they assemble their repetoire.  I find a VCR and a
frame by frame viewing to be most helpful to understand
timing and details.  This is of course, a specific application,
but top-down then bottom-up and so forth.

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h