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

[cognite@zianet.com]

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