This discussion seems to make very clear the need
of the new VR_AI focus that Rob has brought to the table.
HumanML, in and of itself, is not meant to be for
apps designer consumption, but rather for end-user consumption. I'm being
a bit carefree with my labels here, but basically I mean that HumanML is
designed to represent what the human thinks...not what the app
thinks.
Of course, the app designer could use CSS or XSL or
code to style/transform a pure HumanML document in a conducive fashion, but
the point is is that how HumanML is rendered or transformed is not the concern
of HumanML...on its own.
Then whose concern is it? It certainly can't
be ignored or left on its own...no one would use it.
This brings us to explicitly defining a
bridge, as Rob describes in the outline, and this API of sorts is a fundamental
aspect of the project to clarify....maybe we can call it 'HumanAPI'? I
know you used the definition in a slightly different context Rob, but I think it
falls under the exact problem area we have been discussing thus
far.
-----------
Ranjeeth Kumar Thunga
----- Original Message -----
Sent: Monday, October 08, 2001 7:09
PM
Subject: Re: HM.VR_AI
I don't see how we can "completely" divorce ourselves from how
apps designers will think about HumanML (being a hard core apps designer
myself), I may require a bit of "training" to pull out of that
mode. The way I look at things, is that if a language does not allow for
those things I need to (or want to) do, I'm not going to bother with it
regardless of how noble the cause. I hope that we remain "cognizant" of
how complex HumanML may have to be in order to be of real value. "We"
are, after all about the most complex system going...
Yes, this should be discussed in a requirements thread.
Thanks Rex for the refocus,
Rob
Hmmn, A rewind may be in order here. I think we need to discuss
requirements in a requirements thread, and I should have made that
distinction way back when Ranjeeth spoke of a litmus test of what is within
the purview of HumanML in relation to VR_AI: Goals and Overview.
Unfortunately, I was so pleased at the prospect of a genuine argument over
values and datatypes that I neglected to point that out. When I
responded to Len's request for clarification, I said that HumanML needs to
look to such areas as VR and AI, (as well as all others that we identify as
important), for THEIR requirements of HumanML, and see if we can accommodate
them or at least not create vocabularies that contradict them. Somehow
that got to a discussion what is allowable as HumanML. I think we ought to
be careful of where we jump, as into conclusions, and mea culpa, me
too. IMHO, we're trying to do something we should not be doing when we
get into thinking about specifying primary, let alone secondary, audiences
for HumanML. Isn't that the realm of apps builders? Ciao,Rex At
6:03 PM -0400 10/8/01, Ranjeeth Kumar Thunga wrote:
The
cultural/historical/political/personal_belief IDENTITY is what
differentiates definitions from another...there is no such thing as a
precise word definition except it has attached a particular identity with
it.
Below is a
trashy example (I admit) but makes the point pretty clearly about a markup
language for human consumption, and as Rob mentioned it could be numbers
or letters.
Hypothetical example
--------------------------------
For "geek"
sub-culture, happiness may be represented from 0% to
100%
For
"literary" sub-culture, happiness may be enumerated as "cathartic"
"jubilent" or "ecstatic"
For
"pop_psychology" sub-culture, happiness may be enumerated as digits from a
scale of 1 to 10
The job of
mapping these to rendering languages is not the job of HumanML at a base
level, and not necessarily are represented in higher level constraints
either. I think we may need to scope out a "mapping/transformation"
deliverable as part of HumanMarkup (as if we don't have enough
;-))...nonetheless, as Len mentioned, we are building for a future...a
future which may take 10 years to see the final
implementation.
I propose
the following...
HM.Requirements:
HumanML
must represent, in an explicit and clear fashion, the values as they make
sense to the conveyers themselves themselves, as best as possible within
the limits of XML design...no one else needs to be consulted, or should be
consulted, except the designated authority creating these
self-definitions.
Ranjeeth Kumar Thunga
----- Original Message -----
From: Bullard,
Claude L (Len)
To: Rob
Nixon
Cc: Rex
Brooks ; Ranjeeth Kumar
Thunga ; OASIS
Comment
Sent: Monday, October 08, 2001 5:27 PM
Subject: RE: HM.VR_AI: Goals and Overview :
HumanML_VR_AI Facilitator
Of course
the dilemma there is secondary receivers (or multiple receivers past the
intended receiver). For example, the word "crusade" has
a
loose
meaning in the west. To a person from the Middle East, it has a
pejorative or emotional meaning. So code lists are developed
that
have
cultural attributes. This means the sender tries to
ascertain the use of the code in each view (where the view is an
aggregation of
culture,
history, etc.) and the receiver attempts to determine the scoping of the
original message (intent: was it local meaning of
sender,
or was it
intended to inflame the secondary receiver). For example,
one can envision an interface in which a gesture or word is
expressed
in a view
consisting of personal time, historical time, culture, etc. joined to a
set of all possible receivers ranked by the intention of
the
sender
for a given receiver to get this message in primary or secondary roles
(or any set of roles you can envision). This would
return
a graph
where that gesture is the topic and all of the receiver interpretations
are linked nodes with some visualization
technique
(say
color coding) that ranks the interpretations according to some other
dimension (criticality, danger, affinity, whatever).
This
would
make it possible to explore different interpretations and pick one that
meets the local politic. Remember, the system
doesn't
find a
"true" meaning; it enables one to choose a
meaning.
In a more
formal communication, say a process constrained set of messages, one
creates a protocol. This means that the
potential
interpretations and the potential receivers are much more
limited enabling a much more predictable behavior as long as
everyone
sticks to
the a priori rules for the protocol. Such
contract-constrained communications usually include a phase similar
to
what is
described above in which a set of message types are proposed,
contracted, and limited in the interpretation such
that
the
response behavior can be observed and validated as belonging to an
acceptable range. Otherwise, if outside the
range,
the
system punts to a negotiation node to enable it to determine the next
move.
len
-----Original Message----- From: Rob Nixon [mailto:robnixon@execpc.com]
Sent: Monday, October 08, 2001 4:03 PM
To: Bullard, Claude L (Len) Cc: Rex Brooks; Ranjeeth Kumar Thunga; OASIS
Comment 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. -- Rex Brooks GeoAddress: 1361-A Addison, Berkeley, CA, 94702
USA, Earth W3Address: http://www.starbourne.com
Email:
rexb@starbourne.comTel: 510-849-2309 Fax: By
Request
|