What Exactly Is the Context?

In SILKin our main focus is to learn the kinship terminology for a particular culture or language. A set of definitions for all the kin terms is called a 'Domain Theory' (a computer science term). In some cultures there are two sets of kin terms: terms of reference and terms of address. But there is only one population of people and families, only one set of mores for marriage and courtesy, etc. We say that this culture is the Context of our effort while we focus on learning one or two sets of kin terms (reference and address). If there is only one set of kin terms in the culture you are studying, you may think of the culture, the domain theory (kin term definitions), and the Context as interchangeable. The distinction is only important to SILKin's inner workings.

The Context for any SILKin project contains one or two domain theories, the people and families, etc. Whenever you Save (or Save As) your work in a SILK file, you are saving the entire Context.

The Context Editor

Most of your time will be spent building family tree charts and recording the kin terms that people use with one another. Periodically, you will ask SILKin for suggestions and will act on those suggestions: gathering disambiguating data, confirming or denying synonyms and umbrella terms, and accepting or rejecting proposed definitions for kin terms in this Context (the 'domain theory' we are trying to learn). None of this activity requires the Context Editor.

But a few things can only be done in the Context Editor:

You can also do two things here that duplicate other screens: indicate whether polygamy is permitted in this culture, and whether there are distinct terms of address.

You reach the Context Editor from SILKin's main screen via the 'Edit > Edit Context' menu choice. This will bring up a solid blue background screen holding the Context Editor. The blue screen has other functions that are reserved for SILKin's administrators. You only need to deal with the Context Editor.

Deleted Records

When working on the Chart, you can delete a person or a family with your mouse. If the person/family deleted was the last one created (has the highest serial number), SILKin will remove all trace of it. But if you delete the person with serial number 17 when there are higher serial numbers in existence, SILKin will mark that person (#17) as 'deleted' and they will disappear from your chart. But their record will still exist in the database. You can view it in the Context Editor in the 'View/Edit Person' drop-down list.

If you click on a person in the 'View/Edit Person' list, an editor window will open that allows you to edit their properties. In general, you should NOT use this editor to change a person's properties. Use the chart window. But this is the only way to view a deleted person, and also the only way to un-delete a person. Clicking on the Un-Delete button will make the person visible and usable again. Because SILKin cannot put the un-deleted person in their former position in the chart (the chart may have changed), the un-deleted person will appear in the upper left corner of the chart. You can drag them to wherever you want them.

Likewise, if you have deleted a Family (union) you can view it or undelete it from the 'View/Edit Family' list. With both Families and People, it is not necessary to un-delete -- you could simply make a fresh Person or Family to replace the deleted one and link them with the rest of your chart. One motivation to un-delete might be if you had extensive notes in the Comments field of the deleted item.

BE CAREFUL. Do not delete the person or family if you only need to delete a relationship. The next time you Save (or Save As) your data, all the people and unions you deleted will be erased from the SILK file. This action cannot be undone.

User-Defined Properties

SILKin has a built-in understanding of many words used in kinship (e.g. 'son'). The list is quite extensive. But sometimes a unique or seldom-used concept may be part of the kinship system you are studying. To allow for this, SILKin provides User-Defined Properties (UDPs). The meaning of a UDP is whatever the User decides it is, and the name is chosen by the User. However, the name of any UDP must begin with an asterisk/star ('*') and contain only lowercase letters. SILKin will treat any property/predicate as a UDP if and only if the lowercase name begins with the asterisk/star. (This should be an upper case symbol above one of the numbers on your keyboard. On most US keyboards, it is above the number 8.)

You may think of UDPs as either properties or predicates because they serve as both. For example: if your context provides special honor to bald-headed men, you might create a UDP named '*bald'. Baldness is a property of some persons (a rather nice one, don't you think?) so you can think of the UDP as a property. But you can use *bald as a predicate. The built-in predicate 'father' allows you to state that Alter is Ego's father. Likewise your UDP *bald can be used to declare that Alter is bald; in this case you are using the UDP as a predicate. (There is a tutorial about predicates and their role in Horn Clauses here.)

A typical use of UDPs would arise in a context that uses clans in the kinship system. Not every society that recognizes clans uses them in their kinship system. But in some systems, a person of the same gender and the same clan has a kin term (gloss: 'clan brother'). In that case, you would want to create a UDP named '*clan' (or any other name you like, so long as it follows the naming rules). You do this by clicking on the 'Add UDP' button of the Context Editor (that you reached from the 'Edit > Edit Context' choice on the main Data Gathering screen). This brings up the 'Create New UDP' screen.

After choosing a name for your UDP, you must decide what kind of value it will have. In the example above, a UDP named '*bald' probably describes a property that is either true or false. So in the drop-down menu of Data Types you would choose 'boolean' (the mathematical name for true/false variables). Or if the *clan property has values like 'bear', 'turtle', or 'fish' then you would choose the Data Type 'string' (i.e. a string of letters and numbers). A UDP may also have a Data Type of 'person'; you might use this for an *owner UDP in a slave-holding society, or for adoption. UDPs can have numeric Data Types also: either 'integer' (whole numbers) or 'real number' (a decimal number, like 98.6).

A UDP may have multiple values, or not. A UDP describing the relative(s) responsible for passing on cultural knowledge or values (*mentor) could have multiple persons as values for the UDP. But if clan membership is exclusive, then *clan would be restricted to a single value. (Once you establish a UDP's data type and restrictions, SILKin will enforce them.) There may be only certain values that are legal. For example, there may be only four clans in the context: bear, fish, turtle, and eagle. If you check the radio button 'Yes' for 'Restricted to Certain Values' SILKin will prompt you to type in the legal values, separated by commas.

Sometimes there is a common value that applies to most people but not all. In that case you may check 'Yes' for the Default Value and type that value in the box. This value will then be entered automatically for every person created. You can edit the few values that are different from the default in a person's Detail Display panel. But to create a UDP in your Context -- or modify it -- you must always use the Context Editor. Finally, for numeric values you can enter minimum and maximum values.

When you have entered all the information about a new UDP, you click the 'Check for Errors' button. SILKin will assure all your entries make sense, then give you a 'Save' button. When you click 'Save' a UDP will be created for every person in the context. If a default value was provided, that value will be inserted for everyone. Thereafter, a UDP drop-down box will appear in the Detail Display for every person. The value(s) of their UDP(s) can be viewed and edited in the Detail Display. (Adoption UDPs have their values changed graphically.)

Editing a Domain Theory

SILKin's main focus is to learn one or two domain theories for your context. Ideally SILKin will periodically compare your genealogical data and related kin terms to other kinship systems in its Library and suggest definitions for your kin terms based on definitions it has seen in other contexts. But SILKin is just a software program; you may figure out the definition for a term before SILKin does. If so, you will want to manually add your definition to the domain theory.

SILKin may have suggested a definition that is accurate, so you've accepted it. But you would like to express the definition differently. This requires editing an accepted definition.

Or you may have discovered a cultural concept in your context that is not a kin term per se but the concept is useful for expressing the definitions of kin terms. You would want to introduce an Auxiliary Term into the domain theory (a term that is not a kin term, but is used in the definitions of kin terms). For example: if your context has terms for 'female cross cousin' and 'male cross cousin' it makes sense to first define the concept of 'cross cousin' (as it is understood locally) and then use that term in the definition of both the male and the female kin term.

To accomplish any of these things, you must click on 'Edit Theory'. This will take you to a separate screen for that purpose. Because you need to understand the basics of Horn Clauses in order to edit a domain theory, there is a separate help page devoted to editing Horn Clauses. That page explains how to edit a domain theory (set of definitions).