I'm rather inclined to agree with Manos here. The
uses of HumanML by people will probably only be handled through intermediation
elements -- machines. You are not likely to actually write HumanML by hand.
Instead you would use an application to generate the HumanML for you, or to
interpret the HumanML from external systems. This will hold true for even
specialized uses such as psychology or social science -- I see very few postdocs
willingly creating a HumanML document by hand.
-- Kurt
----- Original Message -----
Sent: Tuesday, October 09, 2001 12:50
AM
Subject: RE: Fw: HM.VR_AI: bridge
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
|