RE: possible Base anchor Idiosyncrasies RE: [humanmarkup-comment]First Working Draft of HM.Requirements

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

We had broken the original Base draft along the lines of the 
characteristics of the communication environment and the 
communicators.   Software agents will be a problem.  They 
are entirely artificial and only insofar as they are emulating 
the human characteristics can we classify them.  Otherwise, 
we are simply doing user interface design.  In the early 
discussions, we were talking more about human representations, 
eg, VR avatars, as applications.  That they have a software 
agent behind them is of interest to implementors, but not 
particularly something we have to deal with.  Tecg like 
emotion engines, articulation engines, etc. can use HumanML 
for tagging and some glueing together of semantic classes, 
but we aren't there yet.

We have to be careful not to invent too many abstractions 
or terms here.  We originally carefully mined articles 
on semiotics, hermaneutics, etc. to find a set of terms 
and concepts of human communication that some set of 
users will recognize and adapt and that appear to be 
reasonably well-shared among disciplines.  I'm not set in stone 
on these, just hopeful that we won't do too much in 
the primary schema.  

len

-----Original Message-----
From: cognite@zianet.com [mailto:cognite@zianet.com]
Sent: Tuesday, March 26, 2002 2:09 PM
To: humanmarkup-comment@lists.oasis-open.org; Bullard, Claude L (Len)
Subject: possible Base anchor Idiosyncrasies RE: [humanmarkup-comment]
First Working Draft of HM.Requirements



Avoiding MUST here is a logical way to keep HumanML from having declared
itself invalid in the likely case of incompatible conventions coming from
elsewhere.  (In my Notes version,
wording was softened to "MUST be designed to", I believe.)
        There may be cases where it would be poor design to adopt some
"standards" or counter-productive to have to change ours because someone
else changes theirs.  (Prior discussion noted this also.)
        Further, as Len points out, "pure physical characteristics" are not
always germane to the significance of communications in a given interpretive
context.

At 01:44 PM 25-03-2002 -0600, Len wrote:
>"The Primary Base HumanML Schema MUST include a HumanIdentifier Element
that is compatible with and interoperable with [many] standards, ...."
> 
>...identification ... relies not much on pure physical characteristics ....
The process ... >is typically matched to the need .... [And various,
changing systems are in use.]
>
> 
>So our human identifier code elements have to be fairly limited in the
primary schema.  

As a feature at the base level perhaps IDIOSYNCRASIES would do.  

Special-needs feature specs would then be slottables at the Secondary level.
As example, at Secondary level we might have the Name(s) of communication
agents.  Per provenience of the communique and interpretive purpose, Name(s)
could including Form(s) of Address style names, such as relationship-based
ones like Son, Mom, Boss, and Sir, not to mention telnet addresses.  At a
lower level a rich set of options for different applications might
be pulled in, as Len notes.  If these specs borrowed in were not totally
compatible with each other, the user can adjust as needed without
jeopardizing the HumanML itself.

>Physical characteristics for LE systems will also be a 
>small set and not nearly as detailed as they would be for say, medical
applications and perhaps even the VR systems.
> 
>Even the seemingly obvious and simple means such as recording names become
complicated if >inherited in a module that has a cultural 
>component.  Anthropometric means are better and biometric means are best.
> 
>len

For many genres, there is no single speaker:  consider media news or folk tales.
No personal name.  There may be, however, significant facts about the
provenience of the communique.  A place in the Base Schema is needed for
attaching whatever info there is.

HumanML also needs built-in flexibility for dealing with mixed-agent systems.
Some of the communication Agents in Human-Computer Interactions such as we
aim to deal
with might have physical existence but NO biometrics.  Yet like live beings,
they may have idiosyncrasies relevant to communication that we want to
characterize
in like wise.  For instance, all the communication agents may have
characteristic times-of-reaction. (Variations in turn-taking intervals in
different types of 
conversation in different groups are highly significant.  Lengthy times in CHI
may be differently interpreted than in geolocal human groups, though.
Artificial
agents may have voice profiles with parameters affecting significance of message
components.   There may well be idiosyncratic writing style(s) or rendering
to be characterized. (Cf. HTML, Unicode name adaptation.) 

Suppose we put something on the order of Idiosyncrasies ("Metrics" seems too
vague to me -- "Provenience"? "Eccentricities"? ;) at the Primary level.
Then, expansion into communication detail appropriate to the particular
expression and interpretation circumstances and purposes would be done in
the Secondary level.  And "identifier code elements ... be fairly limited in
the primary schema", as Len says.

SC