OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [humanmarkup-comment] Base Schema-channel


I'd like to hear from some other voices on this. I hate to put things 
on hold, but my schedule keeps getting pre-empted, as it was just 
now. Also, this particular element plays large in the EMOTE program 
from The University of Pennsylvania's Center for Human Modeling and 
Simulation. so I am copying Norm Badler and Jan Allbeck to ask if 
they could catch up on this thread and give us their position on it.

The OASIS archives are way behind, so it is probably better to just 
look at the straw man toolkit schema:

http://groups.yahoo.com/group/humanmarkup/files/Technical/XML.Schema/XML.Schema/

You can download it from there.

Thanks,
Rex

At 9:27 AM -0500 6/4/02, Bullard, Claude L (Len) wrote:
>Channel is very messy.
>
>What might be a good idea is simply to specify channel as having
>attributes for in and out.  The problem is that extensibility
>below that quickly falls into the applications so we need some
>rubric for deciding what belongs in the base.  (BTW:  I don't
>disagree with having a set of toolkit secondaries, but let's
>be sure first we have weaned the base down.)
>
>The issue is that all sensory channels are input only. Human senses
>are
>
>sight
>hearing
>touch
>taste
>smell
>
>We discussed a sixth sense to account for intuition
>but for the moment let's not just to avoid the
>philosophy debate about that.
>
>Each of those channels is clearly input or simply,
>receptors.   It is easy to add these as enumerations
>via an attribute, but that isn't very useful.  If they
>are derived, they get the input/output attribute from
>the base, yes?  In every case, they are input. 
>
>As soon as we mention output, it gets
>quite a bit more complex.   Speech, hand gestures formal),
>postures or body language (informal) whistling, singing,
>etc. are all kinds of communication, but are they 
>channels per se?  Channel does not appear to be a particularly
>revealing concept.   I'm not suggesting we toss it yet but
>I'm trying to come up with a use for it beyond a root
>definition and a single attribute that accounts for
>directionality.
>
>I don't think we should account for the effects of a message
>received via a type of channel into the channel itself. 
>
>len
>
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Tuesday, June 04, 2002 9:06 AM
>To: Bullard, Claude L (Len); 'Rex Brooks'; cognite@zianet.com;
>humanmarkup-comment@lists.oasis-open.org
>Subject: RE: [humanmarkup-comment] Base Schema-channel
>
>
>Scope is a good point. There are factors in any environment which
>affect communications, and that is the context question. So
>information that is not necessarily part of an intentional
>communications session (including unintentional messages), may
>nevertheless have an impact. How that information is received by a
>human or agent and what that information does to the human or agent
>needs to be accounted for. That's the reasoning behind my suggestion
>for sensoryChannel, which absorbs any information available.
>
>So, a communicationChannel is the output channel for transmitting signals.
>
>An example where a sensoryChannel was at play while a
>communicationChanell was operating, was the chat I had going with
>Ranjeeth, while the WTC was collapsing. It had a major effect and we
>discussed it while it was happening, but it was not in and of itself
>a communication to us, though it could be argued that it was a form
>of communication apart from our chat. However, the point is that it
>affected us and our communication.
>
>I admit it is not necessary to put these elements into the base
>schema since they can be simply derived as abstractions from the
>abstract channel element itself. However, while the aim may be to
>keep the base as small as we can, we have this entire spectrum of
>elements which will be used across a multiplicity of secondary
>schemata, and I think it would just be helpful to have a common
>element or set of elements for those so that we can avoid the
>problems of proliferation of possibly conflicting vocabularies in
>secondary schemata that use common elements and needing a secondary
>base schema to cover those so that they are consistent across
>secondary Human Markup Schemata.
>
>I would like to keep the base as small as we can, but if it leads to
>conflicts, it won't be much use.
>
>However, I am quite willing to be led by a consensus on this.
>
>Ciao,
>Rex
>
>At 8:10 AM -0500 6/4/02, Bullard, Claude L (Len) wrote:
>>If the scope of HumanML is human communication, sensoryChannel
>>describes the means of a human receiving information.
>>
>>What is the purpose of communicationChannel?  What I wish to
>>avoid is opening a very very very large abstraction that
>>subsumes all manner of communication.
>>
>>Channel may be sufficient.
>>
>>len
>>
>>-----Original Message-----
>>From: Rex Brooks [mailto:rexb@starbourne.com]
>>
>>
>>a sensoryChannel would be a conduit for input information into a
>>human object, i.e. an instantiation of the human element
>>
>>a communicationChannel would be a conduit of message-bearing energy
>>
>>a signal would be message-bearing energy (which we will still revisit
>>in order when we get there, realising that it may be further refined
>>by that time.)
>>
>>While it would be possible to derive these from channel as it is
>>written in the straw man, I think it would necessitate a third level
>>of abstraction as a secondary base schema, so to speak, so what I
>>propose is that we take the time to define some basic, if derived,
>>elements to avoid a secondary base schema just for these top level
>>derivations. I do think that these distinctions will turn up for many
>>of our singular base elements.
>
>
>--


-- 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC