[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: possible Base anchor Idiosyncrasies RE: [humanmarkup-comment]First Working Draft of HM.Requirements
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> --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC