This page explains how to edit definitions in SILKin. When a SILK file has been opened in SILKin, choosing 'Edit > Edit Context' will open a Context Editor window. Near the bottom of the context editor is a box containing the Kinship System Domain Theories (i.e. definitions). If your target language does not have separate Terms of Address, there will only be a theory for Terms of Reference. If you click on an 'Edit Theory' button, it will open a theory editor for that set of definitions.
In the theory editor window you may edit the Primary Author and the citation of any publication containing further information about your work. Or these fields may remain blank if you like. Below these are a profusion of buttons and menus that allow you to view and edit definitions of kin terms, or edit related comments.
There are several ways you could express the definition of a kin term. Let's use the English term 'aunt' as an example.
Writing Horn Clauses is fairly simple. Each way a person can qualify for the kin term is expressed in a separate clause. In our example above, there are four different ways one can qualify as an 'aunt' in English, so there are four clauses. Each clause is independent of the others. The variable "B" may represent one particular person in one clause, and someone else in another clause.
The components of a Horn Clause, the individual relations, are called literals by mathematicians and computer geeks. A literal has a predicate that names the relation, followed by the arguments in parentheses. In our second example above, the literals are 'mother(B, Ego)', 'brother(C, B)', and 'wife(Alter, C)'. The predicates are 'mother', 'brother', and 'wife'. The predicate 'mother' has two arguments: 'B' and 'Ego'. A literal consists of one predicate and its arguments enclosed in parentheses. Multiple arguments are separated by commas. Multiple literals are also separated by commas. Notice that predicates and arguments are not alike:
When there are multiple literals in a clause, they are separated by commas. There is a period after the final literal.
When there are multiple clauses in a definition (e.g. 'aunt' above has four clauses), the first clause is preceded by a literal that represents what is being defined: for example 'aunt(Alter, Ego)' and a special symbol ':-' that means "is defined as." All clauses after the first one are preceded by the special symbol '|' that means "OR". To illustrate these rules, here is how the formal definition of English 'aunt' is written in Horn Clauses:
aunt(Alter, Ego) :- mother(B, Ego), sister(Alter, B). | mother(B, Ego), brother(C, B), wife(Alter, C). | father(B, Ego), sister(Alter, B). | father(B, Ego), brother(C, B), wife(Alter, C).
Once we get used to Horn Clauses, we can read a clause like a sentence, or read multiple clauses like a paragraph. Here is how we would read the 'paragraph' above that defines the concept of English 'aunt.'
Alter is the aunt of Ego if: B is mother of Ego, and Alter is sister of B. OR B is mother of Ego, C is brother of B, and Alter is wife of C. OR B is father of Ego, and Alter is sister of B. OR B is father of Ego, C is brother of B, and Alter is wife of C.
There is one more rule for writing Horn Clauses: there must be a chain of relations leading from Ego to Alter. For example, in the second clause of our 'aunt' definition we say that B is the mother of Ego, and C is the brother of B, and Alter is the wife of C. 'B' and 'C' are the two linking kinsmen between Ego and Alter. If the chain of linking kinsmen is broken (e.g. by misspelling a variable) then the definition is invalid and SILKin will reject it.
Here are some examples of incorrect clauses:
mother(B, Ego), sister(Alter, B),
father(B, Ego), Sister(Alter, B).
mother(B, Ego), brother(c, B), wife(Alter, C).
mother(B, Ego), sister(Alter).
father(B Ego) sister(Alter,B).
You need only a few basic relations to build a genealogical chart. You can tie all the people and families together using just parent-child and spouse relations. If we also use the relations to specify the gender of Alter, we need just 6 basic relations, or predicates:
sibling(Alter, Ego), gender(B, Ego), gender(B, Alter).
That clause would make the definition clear to a human reader, but if we asked SILKin to draw a chart of this kin term, it would draw a single
diagram where Ego is male (or female) and Ego's sibling has the same gender. But to be really precise, SILKin should draw
two examples: one for male and another for female, to make it clear the definition works for both genders.
When SILKin sees a plural gender-neutral predicate (e.g. siblings or spice), it knows that when creating examples or drawing charts it must
generate both cases. So the best way to write "same-sex sibling" would be:
siblings(Alter, Ego), gender(B, Ego), gender(B, Alter).
That is the same as writing two clauses, one with a male Ego and one with a female Ego. See the next two sections for other examples of how to use
gender-neutral predicates and a good rule-of-thumb.
Auxiliary terms are another potential convenience. You do not need to define or use any auxiliaries, but you may if you wish. Auxiliaries provide a way to define a concept in the local language that does not correspond to a single kin term.
For example: perhaps the local language includes the concept of 'cross cousin' but has separate terms for male cross cousin and female cross cousin. It would be convenient to define the cross cousin concept as it is used in the local language (there are many different interpretations around the world), then plug that concept into definitions wherever needed. Because there is no kin term for 'cross cousin' we need an auxiliary term.
The rules for auxiliaries are simple. The name you choose for this predicate must start with a lower-case letter and must contain "[aux]" inside the name. In this case, we might choose 'cross_cousin[aux]' as the name of our auxiliary term. We click on the 'Auxiliary Terms' drop-down menu and choose 'Define New Auxiliary Term'. We are prompted for a valid name, then we can begin to write the definition in the editing area.
As soon as we provide the name, SILKin puts into the editing area
cross_cousin[aux](Alter, Ego) :-
to start our definition. Let's assume that in the local language, the only requirement is that a cross cousin
must be the child of your parent's opposite-sex sibling. The gender of neither Ego nor Alter matters.
In that case, we would write the following definition in the editing area:
parents(B, Ego), sibling(C, B), children(Alter, C), gender(D, B), gender(E, C), not(equal(D, E)).
By assigning separate variables to the genders of B and C, and then specifying that those gender variables (D and E) cannot be equal, we have expressed the local meaning of "cross". As soon as we validate and accept the definition of this auxiliary term (as described below), 'cross_cousin[aux]' will appear in the menu of 'Defined Local Terms' and we can use it in definitions of other terms.
Notice that we used the plural 'parents' in this definition (it applies to both male and female parents) and also the plural 'children' (the gender of the cousin doesn't matter). But we did not use the plural of 'sibling'. Why not? Because (when generating examples) SILKin will generate samples for both a male parent and a female parent. But once the gender of the parent has been chosen, the gender of the sibling must be the opposite. So SILKin cannot generate both a male and a female sibling for the male parent. We use 'sibling' (singular) so that SILKin will not try to generate both genders for C. The rule of thumb is: Use a singular gender-neutral predicate if some constraints in the clause will restrict the gender. Use a plural gender-neutral predicate if there are no constraints on the gender, and you want to be sure SILKin generates both cases when creating examples or charts.
After you have written or edited a definition in Horn Clause form, SILKin must validate the definition before it can be accepted. The 'Syntax Check' button asks SILKin to verify that you have followed all the rules for writing Horn Clauses, spelled predicates correctly, etc. The sample session below illustrates the kinds of syntax errors SILKin can detect. We have tried to anticipate the more common errors, but if you try you can probably make a creative mistake that will completely perplex the syntax checker. If you fail the syntax check but cannot see anything wrong with your definition, perhaps a colleague can focus fresh eyes on the clause and suggest a solution. If all else fails, save your SILK file (your edits-in-progress are in it) and email it to the support address shown on the site where you downloaded SILKin. The project team will inspect your definition and tell you why it failed the test.
Once you pass the syntax check, you may need to perform a dyad check. (If you are editing or creating an auxiliary term definition, you may skip the dyad check — an auxiliary term will not have any dyads associated with it.) In a dyad check, SILKin examines every dyad in your data. If there are any dyads for this kin term that do not fit your definition, you will be informed. Also, if there are any dyads for some other kin term that fit this definition, you will be informed. You will have the option of examining a list of the misfit dyads.
Until you resolve the misfit dyads, the 'Accept Def' button will not light up. Usually you can resolve the misfits in one of the following ways:
If you have a large collection of dyads, and your definition fits all but a small number of cases, SILKin may ignore this 'noise in the data' and allow you to pass the dyad check. The percentage of 'noise' allowed in your data is determined by the parameter 'Ignorable %' in the 'Edit Prefs' screen.
When you have passed the syntax check and the dyad check, you may click 'Accept Def' to add the definition to the domain theory for this language. Once it is accepted, this kin term will be automatically applied to any new Ego/Alter pair who fit the definition. You will be given the option to retroactively apply it to all pairs who fit.
Jean has been gathering genealogical data about the XYZ people for several weeks. He chose "Get New Suggestions" recently, and SILKin suggested two definitions that seemed reasonable, so he accepted them. Jean thinks he has figured out the definition of a third term on his own. After loading his SILK file he chooses 'Edit Context.' In the context editor he clicks on 'Edit Theory' and the theory editor opens up. He chooses one of the accepted definitions from the 'Kin Terms & Edits In Progress' menu and it is displayed in the editing area. He wants to edit his definition, so he clicks the 'Display is editable' check box at the bottom of the editor window; now he can place his cursor in the text of the definition and make changes. He sees the following in the editing area:
gerbis(Alter, Ego) :- mother(B, Ego), sister(Alter, B). | mother(B, Ego), brother(C, B), wife(Alter, C). | father(B, Ego), sister(Alter, B). | father(B, Ego), brother(C, B), wife(Alter, C).
The definition of 'gerbis' is exactly the same as the English 'aunt' above (how convenient for this example!). Jean wants to replace the four clauses with just two that begin with 'parents.' So he changes 'mother' to 'parents' in the first two clauses and deletes the last two clauses. Now he has this:
gerbis(Alter, Ego) :- parents(B, Ego), sister(Alter, B). | parents(B, Ego), brother(C, B), wife(Alter, C).
Jean clicks the 'Syntax Check' button; he gets the message that his syntax is good, and the 'Dyad Check' button is enabled. Pressing the 'Dyad Check' button produces another message that everything is OK and the 'Accept Def' button is enabled. He clicks that button and the new statement of the definition becomes official. SILKin will use this two-clause version from now on.
Now Jean clicks on the 'Kin Terms & Edits In Progress' menu and scrolls down the list of undefined local terms to 'brac.' He has figured out that this kin term means "daughter's child". As soon as he clicks on 'brac' the beginning of the definition is generated in the editing area and the 'Display is editable' box is checked. He enters his definition, making the editing area look like this:
brac(Alter, Ego) :- daughter(B, Ego) child(Alter, B)
He does not notice his typing errors, so he presses the 'Syntax Check' button. SILKin responds with the message
KSBadHornClauseException: Each Horn Clause must end with a period. Found no period in " daughter(B, Ego) child(Alter, B) "
He adds the missing period. If he doesn't see his other error, pressing the 'Syntax Check' button again will produce
There is likely a punctuation error or missing comma somewhere near the '***' in: daughter(B, Ego) *** child(Alter, B). (Multiple arguments should be separated by commas. Also, multiple literals are separated by commas.)
Jean adds the missing comma between literals (after "Ego)") and presses 'Syntax Check' once more. This time he sees
Syntax is correct for this definition
and the 'Dyad Check' button lights up. This means he can now check his definition
against the data (dyads) he has gathered for the term 'brac'.
NOTE: Passing the Syntax Check successfully causes the 'Dyad Check' button to light up. And if the Dyad Check is passed the 'Accept Def' button lights up. But if Jean makes any further edits (changing just a single character), all the buttons will dim except 'Syntax Check.' If he wants to be sure he does not inadvertently change the definition, he may un-check the 'Display is editable' check box; this prevents accidental changes.
SILKin is very strict about the syntax of definitions. The smallest error in typing a predicate or variable — or a small punctuation mistake — will cause your definition to fail the Syntax Check. As a convenience, SILKin offers automatic variable generation. Whenever you are typing at the end of your definition (i.e. adding new literals) if 'Automatic Variable Generation' is checked you can simply scroll to and select the predicate you want, click 'Insert,' and SILKin will insert the predicate and try to generate a set of variables in parentheses. If it can't figure out what they should be, it may generate a capital letter you don't want. Our guess is that it's easier to edit an incorrect variable name than it is to type the whole literal. If you find this feature annoying, turn it off by un-checking the box.
When using Automatic Variable Generation, the last literal inserted will have a generated variable and the literal will be followed by a comma. If you click on 'Period' the last variable generated will be changed to 'Alter' and the final comma will be replaced with a period. This will complete your clause in the usual way. If you need to insert constraints, you must do this manually.
NOTE: If you are editing in the middle of an existing clause, SILKin will not even attempt to guess the variables you might want. You can still use 'Insert' to insert a predicate, but it will be followed by empty parentheses where you may type the proper variables. The 'Period' button will be ineffective.
There is a 'Comments' field associated with each accepted definition, plus one for the entire context. When the 'Edit Def' button is selected (below the editing area), you can edit definitions. When the 'Edit Comments' button is selected, you can edit the comments associated with an accepted definition. These comments are stored on the SILK file; they might be useful for documenting special circumstances or meanings of a kin term. Or they might explain why the User has written the Horn Clause in a particular way.
To edit the comments associated with the defined kin term 'gerbis' you would select that term in the 'Kin Terms & Edits In Progress' menu, then click on 'Edit Comments.' Note that the syntax and dyad checks (as well as acceptance) are not available for comments. Whatever you type in the editing area will be stored in the SILK file.
To edit your commentary on the entire context, select the titles of the 'Kin Terms & Edits In Progress' and 'Auxiliary Terms' menus. (The editing area will say "[No definition selected for editing.]") Then click the 'Edit Comments' button and the context comments will be displayed for editing. There is no limit on the length of your comments (except the memory available on your computer), but SILKin is not a word processor. Please note that if you have separate theories for Terms of Reference and Terms of Address, your comments about both of them will appear together in the context's comments. You should label them clearly.