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

[Rex Brooks <rexb@starbourne.com>]

Note to lurkers and others, this particular discussion has now gone 
on beyond the scope of the requirements per se, which is as it should 
be. I just wanted to make that clear before I start in on what is 
DEFINITELY a darn site more interesting to me than requirements. 
Lessee, oh yeah, bald speculation, that's what I want to do.

My $.02: I think it is within the scope of the primary base schema to 
have something along the lines of

huml.HumanIdentifier.SelfDescription:xxxx

I don't think I would go farther. I'm not sure how many datatypes 
this should take beyond allowing for string. This would allow for any 
number of other child elements in Secondary Schemata.

I suggest that it might be valuable if that piece of work we once 
discussed--a chronological history of the Phase 0 discussions from 
the Yahoo mail archive were taken up by someone with the time to put 
it in referenceable order. As Len mentions, we went through a fairly 
rigorous period of research and discussion. I for one, would prefer 
not to have to rechew it all, though I wouldn't mind being able to 
refresh my memory.

I do think we might want to stay with Characteristics, 
CharacteristicSets, etc as a way to collect up elements and 
attributes for descriptive purposes. I also think it still makes 
sense to divide the element sets into actors and actions, chief among 
which is communicators and communication.

We might also want to give some very, very careful consideration to 
whether or not we want to have events and event handlers of our own. 
I think not, but I could be persuaded that it was necessary, 
depending on whether XML or the various sub specs have delivered up a 
suitable array of possible events and event handlers. I know I am 
getting beyond this discussion area, but, as with IPR and rights 
negotiations for which OASIS just announced a new TC yesterday, and 
which I have harped on about in the WSIA TC, as I have about 
Transport Protocol inadequacies, these are considerations we will 
have to deal with eventually one way or another, so we might as well 
start thinking about them.

Ciao,
Rex

P.S. This message is not the further discussion of Requirements I 
promised this morning.


At 2:21 PM -0600 3/26/02, Bullard, Claude L (Len) wrote:
>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
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


--