The chart is a kind of graph showing relations among
events.
Many charts fit within the standard window. Very large charts cause scrollbars to be added to the window so that you can examine all parts of the chart.
A Function menu appears in the dark area
above the
chart. The different functions that are available in the Function
menu are discussed below.
Events are represented on the chart by their short names.
A name may be dragged to a different position. Repositioning lasts until the program redraws the entire chart.
Font styles used to print event names convey information. A plain style is used for concrete events with conjunctive prerequisites - that is, all prerequisites have to happen before the focal event can happen. Italic shows events with disjunctive prerequisites - that is, only one prerequisite has to happen before the focal event can happen. Bold is used for generalized events.
Lines represent relations between events.
Black lines represent implications. Occurrence of the bottom event implies occurrence of the top event. In other words, the event at the top of a black line is a prerequisite for the event at the bottom, and the bottom event cannot occur until after an occurrence of the top event.
Magenta lines stand for a commutation relation, in which the bottom event becomes a prerequisite for the top event, after an initial occurrence of the top event.
An example of commutation is entering and leaving a room. Entering is required before leaving can occur. But having entered, one must leave before entering again. The two events commute. An event-structure-analysis chart would represents this relation by a black line going down fromenters roomto represent the requirement of entering before leaving. The chart also would show a magenta line going up fromleaves roomtoenters roomto represent the requirement of leaving before entering again.Yellow lines stand for a relation in which a concrete event instantiates a general event. When the concrete event occurs, we can say that the general event has occurred as well.
An example of instantiation is a corporate executive parking in the company garage. When this occurs, we can say the executive has gone to work. Parking in the company garage instantiates going to work.
Several procedures impose a dialog window over the chart. You may drag the dialog window to a different position to reveal the chart underneath.
Tracing upward along black lines from a focal event reveals the set of events that have to happen before the focal event can happen. Tracing downward is going "deeper": e.g., someone who engages in an event lower on the diagram is "deeply" involved in the incident.
The chart initially appears in Inspecting mode, and in this mode you may click an event to highlight its linkages. Events linked to the clicked event - upward and downward, directly or indirectly - are displayed white-on-black. Click in any blank area to remove highlighting from all events.
Having selected Editing from the Function menu, you can operate directly on the chart to add, delete, or modify an implication. Click on an event and it will be highlighted. Click on a second event, and it, too, will be highlighted. The relation of interest is between these two events.
A dialog window appears over the chart.
Hold down the Shift key
while clicking the events if you want to create, or eliminate,
commutation between events. The dialog window will ask if you want to
toggle commutation. Answering okay adds commutation when the events do
not have commutation initially; answering okay removes commutation when
they do have a commutative relation currently.
The diagram looks different than usual after you select Testing from the Function menu. The name of the first event in the sequence will be printed on a red field. Names of other events that are possible at that point will be printed on yellow fields. In general:
- Red field
- This event is occurring currently.
- Yellow field
- This event could be occurring; its prerequisites are fulfilled.
- Aqua field
- This event has been accomplished and is not yet depleted by a consequence.
The diagram changes after you click anywhere on the chart, causing the first event to be "done". The red event now is event 2 in the sequence. The first event is printed on an aqua field, indicating that it has happened and no other event has yet made use of its effects. As you continue clicking, you will see yellow fields appearing as new events are enabled, and aqua fields disappearing as occurrence of later events uses up the effects of earlier events.
Keep clicking until the program informs you that you have reached the end of the event sequence.
To make events in the sequence occur automatically, hold down the Shift key when you click on the chart.
You probably will be interrupted before you reach the end because some event violates assumptions of the process model. When the program comes to such a case, it superimposes an Amelioration dialog on the chart and tells you what's wrong. There are two basic possibilities.
Occurrence of the next event may be impossible because all of its prerequisites are not fulfilled. The program suggests ways of fixing this, which may or may not include all of the following.
Let's call the next event "event X" and the problematic prerequisite "event P". Then P may have been used up recently by some other event Y, and thus P's consequences no longer are available to enable X, or prime it. In this case the problem could be solved by changing the logical structure so that P isn't a prerequisite for Y. Then Y's occurrence wouldn't use up P, and P still would be available for X after the occurrence of Y. The program will suggest such possibilities if there was an event that used P since the last occurrence of X. The program also will suggest that the problem could be solved just by eliminating P as a prerequisite of X.
Another solution is possible by allowing that P is a prerequisite for Y, but Y does not use up P: then P's effects still would be available to enable X.
Instead of focusing on the model, we might suppose that the record of events is inaccurate. Maybe there was an occurrence of P after Y, but it didn't get recorded. The program will suggest this possibility if an unfulfilled prerequisite is enabled and possible right before the occurrence of X.
It's possible that the logical structure has to be interpreted in a special way. Maybe P is one of the prerequisites of X but not necessary for P, because X can be enabled by any one of its prerequisites. That is, X is enabled by one of its prerequisites OR another, rather than by the combination of all of them. The program will suggest the possibility of disjunctive prerequisites if X has multiple prerequisites and at least one of them has occurred and not been used up. If X already has been made into an event with disjunctive prerequisites, then the program will list events that happened recently and suggest that one of these might be another disjunctive prerequisite of X that enables X at the moment.
Possibly an event that depends on X also enables it. For example, suppose someone entered a room (X), then left the room (Q), then entered again. Q depends on X, but Q also enables the second occurrence of X - the two are connected in a commutation loop. When possible, Ethno will offer this solution to the problem of X being unprimed. Adopting the solution makes X into an event with disjunctive prerequisites and adds a relation from Q to X which is displayed in magenta.
Alternatively, the next event (X) may be impossible because it has gone unused since its last occurrence. The program has a number of ways of dealing with this problem, too.
Perhaps X is a prerequisite for one of the events that occurred since the last occurrence of X. Then X would have been depleted, and it would make sense to do X again. The program will suggest this possibility for any events that occurred just once since the last occurrence of X.
The program will ask if X can be repeated without regard to whether X was depleted by some consequence.
You might want to deplete X by adding an overlooked event as a consequence of X. The program will offer the opportunity to define a new event by entering its short name.
On the other hand, maybe the event record is wrong, and some event that uses X did occur but didn't get recorded. The program will list any possibilities - events that require X and that are ready to occur just before X is to occur again.
The Problem dialog tells you which event is problematic and which kind of problem has occurred. All solutions are listed in a scroll box so you can consider the different options before making a choice. One particular solution is presented below the scroll box, and this is the one that will be implemented if you click the Adopt this solution button. However, you can change the implementable solution by clicking the Go to next solution button.
A popup menu appears in some of the proposed solutions. It lists all the different events that can be used with the given solution, and you must select the one you want before clicking the Adopt this solution button. (Sometimes there is only one item in the popup menu.)
A text field for entering a short name appears when the program offers the opportunity to add a new event. Type the name of a new event before clicking Adopt this solution. The Problem dialog will be replaced by the Relation dialog (described in the section above on Editing Mode), so you can define the relation between the problem event and the new event.
After you adopt a solution, click the Done button. The program reruns the analysis from the beginning of the event sequence to make sure the change doesn't create inconsistencies earlier in the sequence. It stops and waits for you to continue when it reaches the event you fixed.
You may forego all proposed solutions by clicking the Done button on the dialog window without clicking the Adopt this solution button. This allows you to look at the sequence or the definitions of some events before making a decision about how to fix the problematic event.
A Completion Dialog appears when every event in the sequence has been tested successfully. The dialog announces that all events have been tested, and tells you that event statistics are available on the Java console. Clicking the Cancel button makes the dialog disappear, leaving the chart as it was at the beginning of testing.
If you look at the Java console, you will see a table
The topmost numerical entry in the table, Number of defined events, reports how many entries currently are in Ethno's Events menu. The next numerical entry, Number of event occurrences, reports how many lines currently are in the Sequence listing.
A three-column table with a row for each defined event appears below the first two numerical entries. The columns are labeled FREQUENCY, PRIORITY, and EVENT.
EVENT is the short name of the event considered on that row. The rows are sorted alphabetically by the events' short names. Names of generalized events are tagged with an underline as the first character.
FREQUENCY is the number of times the event appears in the Sequence listing.
PRIORITY is an indicator of an event's salience, of how soon individuals implemented an event once it was feasible. The priority indicator roughly corresponds to the percentage of times the event occurred out of all the times the event was primed and ready to occur. Precisely, the value is the number of times the event occurred (fe), divided by one plus the number of times the event occurred, plus the number of times the event was possible but its occurrence was preempted by some other event (fo), with the overall quotient multiplied by 100 to produce a percentage-like value. In algebraic terms, the priority indicator is the following: 100 fe / (1 + fe + fo).
One is added to the denominator to mute values based on small numbers. For example, suppose an event occurred immediately the one time it was possible. In this case, the event occurred 100% of the time that it was possible, but the priority indicator is 50 to reflect the fact that the computation is based on a single instance. On the other hand, suppose an event occurred immediately all nine times that it was possible. Again the event occurred 100% of the time it was possible, but the priority indicator is 90 in this case, reflecting the fact that the computation is based on more instances and therefore is a more dependable indicator of high priority.
The table may be selected by dragging through it, copied with a keystroke command (e.g., Control-C on Windows computers), and pasted into a text file. Then the text file can be imported into a spreadsheet to sort the rows of the table on frequency or on priority. Column entries are separated by tabs to facilitate importing into a spreadsheet.
Selecting Experimenting from the Function menu produces a change similar to selection of Testing mode: events that are feasible appear on a yellow field. However, no event is shown as occurring (on a red field) because Ethno ignores the stored sequence of events while operating in Testing mode. Instead, you define a sequence of events by clicking on one event after another.
Clicking on an event causes the event to be displayed on an aqua field, indicating that the event now has been accomplished, and its accomplishments are yet to be depleted by other events. Clicking also causes events that are enabled by the accomplished event to be shown on a yellow field, indicating that they could happen now.
Clicking only on yellow entries produces a string of events that conforms to the rules defined in the model. Thus Experimenting mode allows you to see how the model defines a variety of episodes, each consisting of a "grammatical" string of events.
If a model includes generalizations, then the generalized events occur when their instantiations are clicked. Clicking generalized events causes occurrence of the generalized event without causing any instantiation to occur.
Clicking in a blank area resets the chart to its initial state in Testing mode.
Clicking on an event alternatively may cause the Amelioration dialog to appear. This means that there is something doubtful about occurrence of the event at that point. The dialog indicates why there is a problem and suggests ways that the problem could be fixed, as discussed above under Testing mode.
Caution: Adopting a solution presented in the Amelioration dialog permanently changes the model, the same as in Testing mode.
After you select Summarize in the Function menu, the program finds every network of events that can be traced back to a single prerequisite, and that flows down to a single consequence, with at least one intervening event. A network of events of this kind can be interpreted as a single event, and in principle such a network might be summarized by a single event name.
Computations take a noticeable amount of time if a large number of events are in the model. They culminate in a dialog appearing above the chart.
A scrolling list titled Summarizable sequences records each of the networks, using the name of an event or two. Clicking on a line highlights the whole network on the chart.
You can use these results to simplify a model. Select
the
network that you want to summarize, type a name in the dialog field
called Short
name for summary event, then click the button labeled Summarize
sequence permanently. The events in the network are suppressed
from view
and a single event with the new name takes their place.
Caution: save your data with the Import-Export option in the Operations menu before summarizing, in case you want to see the detailed events again.
The dialog window also contains a Done button. Click this button to leave the dialog without changing data.
Generalized events refer to more abstract kinds of people and actions than concrete events. A concrete event instantiates a generalized event if occurrence of the concrete event is reason to say that the generalized event occurred as well.
For example, the concrete event, "John spanks Tommy," might correspond to the generalized event, "parent disciplines child." An occurrence of "John spanks Tommy" is an instantiation of "parent disciplines child."
The program allows you to formulate a model of generalized events in parallel with a model of concrete events.
Select the Generalizing option in the Function menu. This causes a dialog to appear above the chart.
Entering a name in the field titled Short name for new generalized event and clicking the Incorporate new event button adds a generalized event to the data. The generalized event will be listed in the Events menu when you leave the dialog.
Each generalized event that you define appears in a popup menu on the right of the dialog window. The popup menu on the left lists all concrete events in the system.
Below each popup menu is a text box that presents the full description for the event selected in the popup menu above the box. In the case of generalized events, you can type in the box, allowing you to create or edit descriptions for the generalized event selected in the popup menu above the box.
Instantiations are established by selecting a concrete event in the left popup menu, selecting a generalized event in the right popup menu, and clicking the Instantiates button. The button then changes to Delete link.
The Instantiates button appears when you align a concrete event and a generalized event that are unconnected. The Delete link button appears when you align a concrete event and a generalized event that are connected by an instantiation relation.
Enter all generalized events and establish their instantiations. Click the Done button to leave the dialog.
The program sets the time ordering of the generalized events to the time ordering of their instantiations. But the program does not presume that the logical relations among generalized events can be computed from the logical relations of the instantiations. Instead, you must link the generalized events one by one. Define instantiations so that the program knows the time ordering of the generalized events. Then select the Link events option in the Operations menu. The program will present questions about the generalized events, allowing you to establish which are prerequisites for which.
The chart will show yellow instantiation lines connecting concrete and generalized events, after the generalized events have been linked. Generalized events are displayed in boldface, and the names are printed somewhat lower than concrete events to reveal instantiating lines.
You can refine the generalized model by selecting Testing in the Function menu, and clicking through the events in the standard way. Generalized events will happen along with their concrete instantiations.
Select Print in the Function menu to print the chart on paper. A Page Setup dialog will appear, followed by a Print dialog. Specifications of paper size, margins, and portrait-versus-landscape must be made on the Page Setup dialog rather than on the Print dialog. (The Print dialog can be used to cancel the print job, and to adjust the printer.)
Ethno formats the chart automatically to fit the
printed page. Changing paper size, margins, and
portrait-versus-landscape
usually changes the formatting of the chart.
Here is a kludge to save the chart as a graphic.
URL:
www.indiana.edu/~socpsy/ESA/Chart.html