Lexical Type Conflict

A lexical type conflict occurs when importing a lexical item file into a lexicon that a) doesn't contain one of required lexical types or b) defines one of the lexical types differently than how it's defined in the import file. Note that the second situation can only occur if you're importing a plx file since csv files don't contain any lexical type definitions. In both cases, a dialog is displayed telling you of the problem and asking how it should be resolved. You have 3 options to chose from and the program will suggest which one it thinks is best. The 3 options are as follows:

• Add the new lexical type definition to your lexicon (plx files only).
• Use an existing lexical type in place of the one being imported. In other words, all lexical items in the import file that are assigned the lexical type will be reassigned to a type already defined within the lexicon.
• Skip any lexical items being imported that are assigned the lexical type.

Options 1 and 3 are straight forward, but option 2 may require a little more effort. First, you'll need to select which existing lexical type you want use, although if the program automatically suggested option 2 then it will also suggest a type based on how similar it is to the type being imported. If you're importing a csv file or the lexical type being imported doesn't define conjugations, genders, or lexical classes then nothing else needs to be done. Clicking the Continue button will proceed with the import.

However, if the lexical type does define some of these fields then the dialog will display them in a table entitled Conflict Details. Using this table you decide if each field defined in the imported type is to be created in the existing type, skipped, or mapped to a field in the existing type. The table is made up of 4 columns: Conflict Type, Import Field, Action, and Existing Field. The first column describes the type of conflict, which can be Conjugation Descriptor1, Conjugation Form2, Gender, or Lexical Class. The next column shows the actual field being imported. For example, perhaps the lexical type defines 3 gender fields: masculine, feminine, and neuter. Using the subsequent Action column you decide if the field should be created, skipped, or converted (i.e. mapped). The last column is enabled only if you choose to convert the import field to an existing field.

The action chosen when importing individual fields will also effect how lexical item data is imported. To illustrate this, let's go back to the previous gender example. Suppose that your lexicon already defines nouns to have either masculine or feminine gender, but the export file also allows for a neuter gender (as is the case with German nouns). The first thing to check is that the masculine field from imported lexical type is set to be converted to the masculine field in the existing type and that the same is done for the feminine gender. After that, you must decide what to do with imported lexical items that are assigned the neuter gender. Creating the neuter gender within the existing lexical type will ensure that all imported lexical items having this gender will still have it when the import process completes. Plus, in the future you'll be able to assign the neuter gender to other lexical items. Alternatively, you may decide that the neuter gender should not be added to your lexicon. In this case, you can chose to skip it, meaning that any lexical item from the export file that is assigned the neuter gender will be left unassigned, or you can convert all lexical items that are assigned the neuter gender to either masculine or feminine, depending on which you think is most appropriate.

If the imported lexical type uses lexical classes then the same rules apply for class fields as for gender fields when importing lexical items. However, conjugation fields behave slightly differently because, unless a conjugation descriptor is defined as a singleton, it takes both a descriptor and a conjugation form to make a lexical item conjugation. In other words, for a particular lexical item conjugation to be imported there must be a corresponding conjugation descriptor and conjugation form defined by the item's the lexical type. If there isn't then that conjugation will be left out when the item is imported.

For example, an English student might have defined a verb in her lexicon as having the conjugation descriptors Present and Past for the present and past tenses. Knowing that English verbs usually have just 2 conjugation forms, she decided to only define 2, I and he/she/it, ignoring you, we, and they. 3 If she imports a lexical item file that defines a verb as having the same 2 conjugation descriptors, but defines all 5 conjugation forms then she will have to choose what to do with the extra forms. If she sets the field actions so that the extra forms are created then all lexical item conjugation data will be imported (i.e. no conjugations will be lost). However, she may choose to skip or convert the forms that aren't in her lexicon. If she skips them then any lexical item conjugation associated with one of the missing forms won't be imported. Only conjugations associated with I and he/she/it will be imported. While it's perfectly legal to convert the missing forms to a single form, or in this case you, we, and they to the I form, this means that for each lexical item only the last of these conjugation forms will actually be saved in her lexicon for a given conjugation descriptor. This is because 4 distinct conjugations are associated with the same conjugation form causing any previously saved conjugation to be overwritten. This isn't a problem when the 4 conjugations are all the same, as with verbs like to drink, but it is a problem with irregular verbs like to be that have more than 2 distinct forms (i.e. I am, you are, he is). Here, unique conjugation data will be lost during the import. For this reason, it is almost always a bad idea to map more than one conjugation field to a single field.

Fortunately, all this is academic as long as the lexicon that you're importing into defines similar lexical types as the lexicon that created the export file. Even if lexical types don't match up precisely, the program will still setup the conflict details table so that no lexical item import data will be lost. The only time that you'll need to setup the conflict table yourself is when the program is so confused that it can't make any intelligent choices. In this case, perhaps you shouldn't proceed with importing the file. It may be for a different type of lexicon altogether.