|
Well, humans
have enough trouble processing the information they receive already, I'm sure
they wont be able to handle any markup. So, an app should just be tuned in a way
to process HumanML in a way the end user wants it to. IMHO, the "app
perspective" deserves the same attention "human perspective"
does.
Just a
thought.
Manos
I do
understand that HumanML is intended for end user consumption. However,
what humans think and what apps "think" will "hopefully" coincide at some
point "not to far off". This is the point I'm trying to
make. While VR and AI are just two of the application areas that would
use HumanML, they are likely to be very demanding ones...
Again, I will attempt to view it from a non-apps perspective...
Rob
Re: HumanML is designed to represent what the human
thinks...not what the app thinks.
Ranjeeth Kumar Thunga wrote:
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
|