RE: [humanmarkup-comment] Our Next Meeting

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

Rex asked that I post something quickly in reference to 
my proposal for experimental sign markup language.  This 
is a quick write up of what I have in mind.  Note that 
I am not abandoning an effort for the toolkit, but I 
feel personally that we need something simpler so we 
can investigate the numerous domains that we have 
come to understand affect a simple human communication. 
Since semiotics have impacted much of thinking, I 
think it useful to explore a basic, bare bones, 
semiotic markup, or sign metalanguage.

NOTE:  This is not a sign language in the sense 
of gestures learned by the hearing-impaired.  It 
is a semiotic markup language.

Why Do This?

1.  It is easier than attempting to create a complete and faithful 
model of human psychology

2.  It is simple enough to build rapidly.

3.  It provides a basis for experimenting with single and multi 
channel human communications.  That is, given Ricardo Gudwin's 
paper, one can consider intelligence to be measured by the 
numbers and instances of signs that an intelligent system 
can handle.   A simple sign processor works with just one.  Others 
can handle and correlate multiple sign systems.  The Gudwin model 
for a semiotic processor is a pretty good place to start to understand 
how a layered system for interpreting signs can be built.

4.  What is learned may enable us to look at our efforts to date 
and decide how best to refactor or take a different approach.

5.  It is time to produce.

Constraints:

KISS.  Stick to the classical 
definitions of semiotic sign concepts and create a markup 
for an observer/markup technician.   Ideally, someone with 
an adequate background in semiotic analysis should be able 
to take any given sign and create a SignML representation 
in just a few minutes.

KISS:  For this first pass, use the DTD form of schemas. 
They are easy to do, are the only form of schema XML validators 
are required to support, and we can always upsize DTDs to 
other languages as long as we avoid any exotic features of 
the DTD itself. 

KISS:  We know that time/space/culture components are 
required for full-up HumanML processing.  It is likely 
that these can be integrated via namespace systems.  We 
should avoid trying to create a complete model of human 
communication and as in item one, stick to classical 
semiotic constructs until we are sure we have fully 
understood this one piece.

Why?

We know that the effect of a sign on an observer varies by the culture, time, and space 
of the observer.   Interpretation varies by context.  Building up a context 
is critical to the category problem (how to discriminate members in overlapping 
sets and close matches).  However, before we build a context, we have to have 
a sign metalanguage.  Then we can go to the next step of how to describe the 
context.   Because interpretation varies based on context, we have to work 
out where interpretations belong in the markup, or if they belong there 
at all.  Because the meanings may be connotative or denotative, different 
conditions prevail.  So before we delve to deeply into interpretation, 
let's agree on a markup for the signs themselves.

Basic Assumptions:

Everything an observer perceives is a sign, has an interpretation, has an 
effect on the observer.  

A sign has a

Signifier:  the sign, eg, curve sign on a highway.
Signified:  the concept signified by the sign, the concept of bending
Referent:  an instance of the concept, a real curve in a real road

A sign may be a

Symbol:  the signifier is abstract, does not have a necessary relationship 
to the signified; has to be learned through experience or tutorial, eg, 
using a Left arrow to mean BACK.

Icon:  the sign resembles the signifier, eg, using a picture or drawing of 
a thing as its representation.

Index: pointer to signified (the concept).  Using a scissor to indicate 
cut of text.   Using a magnifying glass to indicate a zoom operation.

A sign can be made up of other signs.  Traffic signs often have 
compound signs such as the icon for a cigarette with symbol 
for NO (circle with line through it) on top of it.  Sign systems 
may include multiple signs for different channels, ie, ensuring 
that a vocal instruction set is accompanied by pictures, or even 
signing language for the hearing impaired.

To start:

<!ELEMENT sign (sign*, signifier, signified, referent) >
<!ATTRIBUTE sign
  id ID #REQUIRED
  type (symbol | icon | index) #REQUIRED >


Comments?