Major Classes of SILKin

This is a list of the major classes of SILKin. There is no 'natural order' to the classes, so the index pane lists them in alphabetical order. Most of these classes are documented in the Architecture segment of the documentation, in which case I simply provide a link to the section(s) where it is documented.

In the index pane, an asterisk after a class name means that it is a screen or panel of the GUI. A 'hat' (^) after a class name means that class is part of the file parsing process. A pound sign (#) indicates that class is part of Horn Clause modeling.

Action Boxes

When the User chooses to 'Act on Suggestions,' a DecisionFrame is launched (as pictured here). The right hand pane is filled with an HTML file created by applying Gary Simons' XSL transform to the current SILK file. The left hand pane is filled with one of eight Action Boxes:

  1. ActionBoxInstructions
  2. ActionAnomaly
  3. ActionDONEorUnDo
  4. ActionDataRequest
  5. ActionOverlap
  6. ActionPropDef
  7. ActionSynonym
  8. ActionUmbrella

Argument

The Argument class is an abstract class that is the superclass of anything that can be an argument to a Horn Clause. It is documented here.

ChartPanel

The ChartPanel class provides the area where family tree charts (diagrams) are drawn. When gathering and entering data, the User interacts primarily with this. It is pictured here and the text following the image discusses the major operations on a ChartPanel and their call stacks.

ClauseBody

The ClauseBody class plays a major role in Horn Clause modeling. It is documented here.

Context

The Context class represents the culture (language) that is being studied. It is documented here.

Context Editor

The ContextEditor class gives User, and perhaps an Anthropology Coordinator, a way to examine and revise the major components of a Context. An image of this screen is here. Although some functions of this screen have been superseded, the ContextEditor is the only way to reach some important functions:

Deterministic Finite Automaton (DFA)

An instance of the DFA class is a Parsing Table: an ArrayList<Object> of DFA_Rows. Each DFA_Row contains one or more DFA_Cells. Each DFA_Cell contains an 'alphabit' or component of the Alphabet (e.g. LineTerm, WhiteSpace, LtrOrDig) and a newState which is the state you shift to if you consume that 'alphabit.' DFA_Row #1 has cells for state #1, etc. -- one row in the table for each state in a DFA chart.

The table is loaded from a file, using the DFA's loadFromFile(FileName) method. Use of the DFA is documented here.

DomainTheory

The DomainTheory class represents a kinship system expressed in Horn Clause syntax. Every Context has one or two domain theories. A domain theory contains one or more KinTermDefs. Horn Clause syntax and all its components is documented here.

DomainTheoryGrammar

The DomainTheoryGrammar class is an empty class. The file exists only to document the Context Free Grammar used by ParserDomainTheory.

Dyad

The Dyad class represents the basic datum gathered by a field worker. A dyad is a triple: Ego, Alter, and kinTerm. Our Dyad instances have some additional fields, documented here.

DyadTMap

There are two DyadTMaps in each DomainTheory: dyadsDefined and dyadsUndefined. These hold all the dyads gathered by the field worker. Their use is documented here.

EditTheoryFrame

An EditTheoryFrame is the screen used to edit a domain theory. Its use is documented here.

Family

The Family class is the 'glue' that holds a family tree chart together. Individuals are never connected directly; they connect with specific roles in Unions (families, marriages): husband, wife, or child. This is a subclass of the Marriage class mentioned below. Just to keep things confusing, KAES referred to 'Unions' in its original interface; perhaps this was to reinforce their concept that any coupling that produces offspring is a genealogical fact, regardless of whether the culture recognizes that coupling as a family or a marriage. The Family class is documented here

FamilyPanel

The FamilyPanel is the 'Detail Display' in the lower pane of the main SIL_Edit window whenever a Family is clicked upon. The call stack and a general discussion is found here.

FeatureVectorObj

A FeatureVectorObj is a holder of all the features for one domain theory in the Library. Instances are compared to estimate the similarity between two domain theories. It is highly unlikey that maintenance will ever be required for these objects. They are discussed here.

HelpFrame

The HelpFrame class provides the screen that displays pages in the Help system. A single set of help topics is kept here, used in both the 'Help' menu of the SIL_Edit screen and the 'Topics' menu of this HelpFrame. The topics are stored in an inner class: HelpFrame.HMenu. The Help system is discussed here.

Individual

The Individual class represents all the people in a context. This is a subclass of Person, the KAES class for people. Many critical processes in SILKin involve either creating hypothetical people as an example of a definition, or else walking a tree filled by real people. The Individual class is documented here.

Issue

Issue is an abstract superclass encompassing all the specific problems or suggestions that may be presented to the User when they 'Get New Suggestions.' The seven subclasses, that can be instantiated, are:

  1. Anomaly
  2. ProposedDef
  3. ComposedDef
  4. SynonymCandidate
  5. UmbrellaCandidate
  6. OverlapCandidate
  7. DataRequest
They are discussed here.

JavaLex

The JavaLex class is the lexical analyzer for my parsers. It recognizes Unicode characters and issues tokens that are used in the DFA parsing table. Parsing is discussed here.

KinTermDef

A KinTermDef defines one kin term in Horn Clause syntax. A domain theory contains one or more KinTermDefs. Horn Clause syntax and all its components is documented here.

KinTermMatrix

Every context has a KinTermMatrix that can hold the kin terms for every Ego/Alter pair in the population. Its use is discussed here.

KinTypeIndex

Every context has a KinTypeIndex that maintains a pre-computed index of all Ego/Alter pairs that have each kin type (PCString). Its use is discussed here.

Library

The Library class (not to be confused with the 'Library folder') is never instantiated. All of its fields and methods are static and are accessed extensively by other classes. Its name is due to its role as the central repository of all system-wide materials. It has several important fields:

Link

The Link class represents the 'alias' objects we create when we want to draw an existing person, whose home chart is 'B,' on chart C. Links and their use are discussed here.

Linus

The Linus class provides the 'line server' that reads an input file and provides a string that represents each line of the file. It has only one significant method: makeLine(). Parsing is discussed here.

Literal

A Literal is the basic element of a Horn Clause. It has a predicate and one or more arguments enclosed in parentheses and separated by commas. Horn Clause syntax and all its components is documented here.

MainPane

MainPane was the primary screen during the academic portion of this project. It is focused on creation, indexing and maintenance of the library of known kinship systems. Those Administrative Functions are now only available to the system administrator, presumably the International Anthropology Coordinator or someone reporting to her.

Marriage

The Marriage class holds all the KAES fields and methods. It is the superclass of the Family class. The discussion of families above is sufficient.

Node

A Node is a cell in the two-dimensional KinTermMatrix. It contains all kin terms that the Ego (row) uses with Alter (column). In the SIL_Edit screen, each Individual in the context stores the node from their column of the current Ego's row. When User is entering kin terms in the Detail Display for an Individual, she is editing their node. The KinTermMatrix and its functions are discussed here.

ParserDomainTheory

ParserDomainTheory is used to read in a domain theory file created by a human or generated by SILKin. Parsing is discussed here.

ParserSILKFile

ParserSILKFile is used to read in a SILK file (the XML version). Parsing is discussed here.

Person

The Person class is the superclass of Individual. Person has all the KAES fields and methods. The Individual class discussion here is sufficient.

PersonPanel

The PersonPanel is the 'Detail Display' in the lower pane of the main SIL_Edit window whenever an Individual is clicked upon. The call stack and a general discussion is found here.

Predicate

A Predicate is the 'verb' in a Literal. The literal         mother(Alter,B).
means 'Alter is the mother of B.'

The Predicate class has a category field that holds a PredCategory. This is an abstract superclass of the three types of predicate in SILKin:

  1. PrimitiveCategory
  2. MathCategory (a subclass of PrimitiveCategory)
  3. CulturalCategory
Horn Clause syntax and all its components is documented here.

SIL_Edit

SIL_Edit is the main screen for drawing family tree charts and entering kinship data. As you can see here, the SIL_Edit instance encloses a ChartPanel in an upper ScrollPane, and a Detail Display in a lower pane (either a FamilyPanel or a PersonPanel).

The menu bar of the SIL_Edit screen is the primary menu the User interacts with.

SILKFileGrammar

The SILKFileGrammar class is another empty class. The file exists only to document the Context Free Grammar for parsing a SILK file.

SILKin

During the academic phase of the project, SILKin was the main Java class; it was the 'point of entry.' It's only function is to launch the SIL_Edit screen.

Tokenizer

A Tokenizer consumes input from a Linus one character at a time, building parse tokens as they are defined in a DFA. Parsing is discussed here.

TokenScanned

A TokenScanned is generated by the Tokenizer. It has fields for the data needed by the parser:

UDate

The UDate class is a utility. It provides more than a dozen static methods to validate, format, or transform dates. In my very first interaction with field workers, I learned that U.S. date formats are not used in Africa. Upon Gary Simons' advice, I adopted a universal date format. It allows 4-digit year YYYY, 6-digit YYYY/MM, or a full YYYY/MM/DD as a valid date.

UDPEditor

The UDPEditor is the screen that allows the User to create or modify a UserDefinedProperty (UDP). It is thoroughly documented here

UserDefinedProperty

A UserDefinedProperty is a general mechanism that allows the User to create an attribute or property that may be attached to Individuals. This was built into SILKin from the outset on the advice of Tom Headland that non-genealogical data was often helpful in analyzing the social patterns of a culture. He had in mind properties like 'EatingGroup' or 'SharesGardenWith.'

Although UDPs may be occasionally used for this original purpose, they are the only way to document adoptions and clans, two very important kinship factors that were added to SILKin late in the game. UDPs are discussed here and quite thoroughly in the Help system.

XMLTransformer

The XMLTransformer class has a single method transform. It is used to reformat a SILK file (in XML format) into an HTML file that provides summary statistics about the context and presents Suggestions (Issues for User). The transform method takes as input the User's SILK file and Gary Simons' Silk-status.xsl file.

NOTE: that there are both English and French versions of the XSL file. SILKin uses whichever one has the same 'language ID' that is currently selected for the menu language. For example, when French is the menu language Silk-status_fr.xsl will be used.