Text Notation
Victor H. Yngve, Professor Emeritus
University of Chicago
1. Characters
People working in human linguistics are found in a number of countries. The problems we have been having in international e-mails in regard to the graphic representation of characters on computer screens and in printed output would be enough to make one tear one’s hair out.
A bit of research has led to the following list of Internationally OK characters for use in e-mails and attachments and for the web page. Clearly a final publication can be dressed up from this if desired. The full list is:
Latin letters (no diacritics or accents), numbers, space and the following:
! ” # $ % & ‘ ( ) * + , – . / : ; < > = ?
I think this list will work with all the following International Standards Organization ISO 8859 standard character sets:
Latin1 (West European)
Latin2 (East European)
Latin3 (South European)
Latin4 (North European)
Cyrillic
Arabic
Greek
Hebrew
Latin5 (Turkish)
Latin6 (Nordic)
Sometimes word processors can be too helpful. I might also suggest that when sending materials around you confine yourself to straight single and double quotes ‘ and ” , not the curly kind and in your word processor or e-mail system (look in the help section) turn off the option “fix curly quotes” or “use smart quotes”.
Also avoid using three or more periods in a row unless you have turned off the option in your word processor that converts them automatically to a single 3-dot ellipsis character.
2. Procedures
Procedures can be represented as in the 1996 book using only the allowed characters. The reasons for their choice is set forth in footnotes 62-65.
x v – ( ) : :: , Dt (Dt for “delta t”)
Specifically, avoid trying to use logic symbols in logic expressions. They are difficult to use and different on different computers. Use the ordinary lower-case letters x and v for them and an ordinary hyphen – for “not”. And of course the parentheses ( and ) and : and :: and comma. If you ever have need for “Delta t”, use ordinary capital D instead (Dt).
A block of description in English etc. introducing a block of procedures can end with a colon.
Setting expressions, control procedures, setting procedures etc. can be punctuated at the end with comma or period following the standard usage of ordinary textual orthography for clauses and sentences. So Procedures can be any length and line ends on the printed page can come anywhere in a long procedure without introducing ambiguity.
I will probably be using /name/ for system names. I don’t think it will ever interfere with anyone wanting to mix in phonemic notation in an HSL paper because one can simply supply the appropriate context when one moves from one theoretical orientation to the other.
3. Task hierarchies
This is a higher-level notation that is separate and distinct from the above notation for procedures. It is still experimental.
For plex diagrams in terms of task hierarchies I am considering the following, copied from a draft of part of a paper I am working on. It is a notation for part of the plex diagram (7) under 4.3 in my paper “Rules of Order” (page 7) that many of you have. In any event it’s described here, too:
Systems are characterized by properties, some of which may be task procedures. When the meeting is transacting business, we can say that the /meeting/ linkage is carrying out a task procedure <transact business>. When the meeting is transacting business, we say it is open. We model this as the /meeting/ linkage having a property <open>.
Consider a person attending this meeting as a member. We set up a system called a role part to represent in theory the part that this member plays in the meeting. We can call this role-part system /member/.
The task procedure executed in the /member/ role part when the member is attending the meeting can be called <attend>. This <attend> task in the /member/ role part is carried out by carrying out a sequence of subtasks:
<time> involving waiting for the time for the meeting to start;
<take seat> involving the member taking a seat in the hall;
<come to order> involving the member’s part in the meeting coming to order; and
<transact business> involving the member’s part in transacting the business of the meeting.
There is no problem in using the same name “transact business” for the linkage task procedure and for the role-part task procedure as they are properties of different systems. Similarly, the /member/ role part can have a state property called <open> to represent the member’s part in the /meeting/ linkage state property <open>.
we can write this analysis of the <attend> task in the /member/ role part as:
<attend> = <time> -> <take seat> -> <come to order> -> <transact business> ? <open>.
(This is much more compact than the box notation in the paper, and easier to produce on a computer since we don’t have to draw boxes with lines or arrows between them.)
Let us now look at the member’s task <come to order>. This involves parallel expectations. Having taken his seat the member expects either the presiding officer to stand <expect stand> or to hear the sound of the rap of the gavel <expect rap> or the assemblage to become quiet <expect quiet>. When any of these occurs, the member becomes quiet <be quiet> and expects to hear the presiding officer call the meeting to order <expect in order>.
We can write this as:
<come to order> = <expect stand> + <expect rap> + <expect quiet> -> <first done> -> <be quiet> -> <expect in order>.
Note how the influence of context is handled. It is manifested in the expectations. If the presiding officer in the context of a formal meeting, as here, stands when he is expected to open the meeting, the assemblage becomes quiet. If he were to stand in some other context or in this context at some other time when not expected, it would probably be ignored.
There’s one other notation used in another diagram in the same paper (diagram 6 on the preceding page:
<wait> + <V> + <L> -> <VltL> -> Y<1> N<2>
The “less than” procedure <VltL> is satisfied if the property <V> is less than the property <L>. One or the other of the procedures on the right are executed depending on the outcome of the test.
4. A question
From a June 2, 2002 posting on our e-mail list:
Since we are still at the beginning, I think it should be allowed, and even encourages, for those who wish to do so to experiment with other notations so long as they explain their notation each time they use it. Then if other ideas develop and catch on, we could, if we wish, move later to adopt them as standard notation for HL.
From a June 9, 2002 posting on our list:
The notation for HL/HSL is not yet standardized so anyone can use the notation of his or her choice as long as it is explained in the email or paper.
At 4:36 PM -0400 6/9/02, Bernard Sypniewski wrote:
I seem to recall several discussions with you in which you led me to
believe that the notation was not open to modification. Please correct me if
I’m in error.
It occurs to me that in my June 9 posting I may not have answered the question Bernard was really asking. I thank him for the question. It has set me thinking:
The fact is that “notation” is ambiguous (I now realize).
My answer of June 9 was centered on the first sense, ‘notation’ 1: What characters should we use to set off system names and property names and what kind of a linear notation can we develop to use in our papers to replace the box and arrow notation for task hierarchies which are difficult to draw and take up a lot of page space? This is a matter of convenience and convention as I tried to explain.
But my dim memory of the discussions Bernard mentions is slowly returning. To explain the second sense, ‘notation’ 2, which was probably the focus of our discussion as I understood it at the time, and why I felt so strongly that “the notation” was certainly not open to modification, I have to review for you a bit of the history of linguistics and share with you some of my personal history in regard to hard-science linguistics research that you may not be familiar with.
As you know, over the last two centuries there have been literally dozens of types of grammar proposed by dozens of different linguists. (This is no exaggeration. I could easily give you a long list.) In most cases the developer of a “new” type of grammar would try to differentiate it from earlier ones by introducing a different notation for it, even though the “new” type of grammar might not depart very much in its essence from the rest. Grammar is grammar, whatever costume it is decked out in. A new type of grammar would basically give a linguist or grammarian a new notation for writing grammars. And linguists became very adept at reading a new proposed type of grammar and translating it at sight into the notation they were most familiar with. So a new notation became a proxy for a new way of doing grammar, but all notations were basically the same in that they were all notations for grammar. They were all in the logical domain and not scientifically justified.
The reason that the depth hypothesis turned out not to be a legitimate scientific hypothesis as intended, was just the lack of scientific justification for the then-current types of grammar, including my own, which were seen as different notations for writing grammars. I looked long and hard at many types of grammar trying to find a notation in which the depth hypothesis could be expressed in a testable form. For a while I thought it was because there did not seem to be any good way of handling semantics. And how could we handle the context? Etc. I also looked at a number of computer programming notations including my own COMIT and many others including Lisp and C and Forth. But they were all computer notations designed mainly for the convenience of computer programmers for writing programs of various types. I also looked at logic notations and at mathematical notations and at the latest formalisms.
Then I read the Stoics and realized that all the notations I had been considering were all in the logical domain and untestable. One would have to move to the physical domain in order to have a scientifically justified notation in which the depth hypothesis could finally be put forth in a way that would be testable. I never found it but realized that if it were ever to be found it would have to be based on a hard-science linguistics.
Because I had uncovered so many faulty assumptions in linguistics from a scientific point of view, I mistrusted everything. I worked very hard over a number of years to assure myself that what I was coming up with was not nonsense, that it would stand up to the closest scientific scrutiny. So in the 1996 book, there is much attention paid to scientific justification and the legitimacy of proposed concepts, and chapter 11 has the title “A Scientifically Justified Notation”. This is the ‘notation’ 2 sense, of course. I think you can understand why I feel strongly that it cannot be altered. It might put its scientific integrity at risk.
5. A postscript
At 11:14 AM -0400 6/13/02, Bernard Sypniewski wrote:
Dear Vic,
This is one of the things that has always confused me, the notion of a “scientifically justified notation”. A notation, as I understand it is a method for expressing something, ala musical notation. Some notations, it is true, are more elegant, coherent, consistent (add your favorite good words here) than others but, in the long run, all notations are conveniences of expression. I don’t understand why – or how – they can be “scientifically justified”. Ultimately, a grammar is a form of notation (albeit a clumsy one and one in which “notation” must be broadly defined) because it expresses a model for a language. Since we are not dealing with grammars (of languages at least), we can ignore this last remark.
Confused in Woodbine
Yes, it is confusing.
It’s ‘notation’ 1 that is open to experimentation and ‘notation’ 2 that is not for the reasons given. But the ‘notation’ 1 developed for this ‘notation’ 2 should also not be changed either lest people become really confused.
If what I have already written plus what’s in the 1996 book has not dispelled your confusion, or left you uncertain as to what is open for experimentation and what is not, and why, I don’t know what more I could say. I might remark that we’re simply trying to find out how to do good science in this difficult area, and that domain confusions are among our worst nightmares.
Since everything in your question is in or presupposes the logical domain (notion, method, expressing something, grammar, a model for a language, broadly defined), I should also say that we’re not trying to clarify concepts or notions, especially those found in the common folk culture, which is a peculiarly philosophical type of endeavor.
Try asking a physical-domain question in the real world instead and then try answering it (as I know you are actually doing.)
Victor H. Yngve
June 17, 2002