-
Notifications
You must be signed in to change notification settings - Fork 4
MatrixDoc_Lexicon
This document explains how to fill out the Lexicon page of the Grammar Matrix Customization questionnaire and presents background information on the person library of the Grammar Matrix Customization System (Bender et al., 2002; Bender and Flickinger, 2005; Bender et al., 2010). General instructions on using the questionnaire can be found here.
The Lexicon page interacts with virtually every library in the customization system. On the Lexicon page, the user can define various lexical types. The features and values available to use in the definition of these lexical types depend on the answers to other parts of the questionnaire.
Most of the work for the Lexicon Library and its implementations has been done as part of Drellishak 2009. The full reference and .bib entry can be found here.
The Lexicon page provides means to define grammatical properties of nouns, transitive and intransitive verbs, auxiliaries, determiners and case-marking adpositions. The page bears a red question mark when unfilled. This means that it is possible to create a grammar with an empty lexicon, but generally assumed that it makes sense to define at least a noun and two verb types (typically intransitive and transitive) so that the grammar will be able to parse something. The question mark disappears as soon as at least one noun type and two verb types are given. Nouns and verbs that partially share grammatical properties can be defined as a hierarchy, where a general supertype defines properties shared by more than one class of nouns or verbs. The noun or verb classes that exhibit these shared properties will inherit them from the supertype (see the specific documentation on noun and verb classes for details)
The following information can be provided for each noun type:
-
Type name
-
Supertypes
-
Features (name value)
-
Determiners (obligatory)
-
Stems (Spelling Predicate)
-
Morphotactic constraints
A more detailed description of each of these properties follows below.
Defines the name of the class of nouns. It should be noted that:
-
The suffix -noun-lex will be added to the given name, e.g. mass becomes mass-noun-lex and mass-noun, mass-noun-noun-lex
-
Noun types without a type name will be numbered: noun1-noun-lex, noun2-noun-lex, etc.
-
Good engineering style: pick transparent names, such as mass and count, 1st-sg-pro, 1st-pl-incl-pro rather than cryptic names
This dropbox allows you to select supertypes of the noun-class. The dropbox will contain all other noun types you have defined, the order is not relevant. You can select several supertypes. This is useful if you want to cross-classify properties such as grammatical gender and countability for classes of nouns.
A noun inherits the feature values of its supertype. For instance:
- noun_type has feature Name: PERSON Value: 3rd
- noun_type2 has supertype noun1
In the resulting grammar, all nouns belonging to the class of noun_type2 will be 3rd person.
Next to Noun Types, you find a(n experimental) link saying visualize noun hierarchy. It will display the supertype relations that are defined at that moment as a hierarchy.
Cycles of inheritance are not allowed (and they do not make sense anyway). So if noun_type2 is a supertype of noun_type1, noun_type1 may not be a supertype of noun_type2. Note that the supertype-subtype relation is transitive, so if a := b indicates a supertype relation where b is supertype of a, the following is forbidden as well:
a := b.
b := c.
c := a.
In the supertype hierarchy above, c is a supertype of a through b. So a cannot be a supertype of c
CAREFUL!!!!!!
Validation does not check whether constraints on supertypes and subtypes are compatible. This means that grammars with such errors can be created by the customization system, but they will not load in lkb and cannot be compiled to work with PET or ACE. An example of this would be the following:
NounType 1
Type name: 2nd-sg
supertype: 3rd-sg
Feature: PERSON 2nd
NounType 2
Type name: 3rd-sg
Feature: PERSON 3rd
The 2nd-sg noun will inherit the property [PERSON 3rd] from the 3rd-sg noun, but have the additional property of [PERSON 2nd] from its own definition. Assuming that 3rd and 2nd are conflicting values, the grammar contains an ill-defined type. The following hierarchy would be possible:
NounType 1
Type name: 2nd-sg
supertype: 3rd-sg
Feature: PERSON 2nd
NounType 2
Type name: 3rd-sg
Feature: PERSON 3rd, 2nd
In this case, Noun Type 2 will have a value for PERSON that is an underspecification of 2nd and 3rd. This value can unify with the value of Noun Type 1.
There is a bug report for this problem, but it is extremely hard to implement so that it works at the time of validation. So for now and the near future: pay attention while defining inheritance!
The Feature option for verbs has three fields name, value. You can select a feature under name and its value(s) under value.
The drop-boxes will show features and values based on what was filled out at the pages Person, Number, Gender, Case and Other Features. The first four libraries (Person, Number, Gender, Case) each define features typically appropriate for nouns. Other Features allows you to define customized features. These features can be assigned to nouns, verbs or both. Features that are defined for both categories or for nouns will appear in the drop-box.
Select the feature you want to specify from the left drop-box. Appropriate values will appear in the right drop-box. Each value is preceded by a check box. You can select as many values as you want for each feature (but note that selecting all values leads to the same behavior as not specifying a feature value pair at all).
If you select more than one value for a feature, the noun class will assign an underspecified value to the feature that may unify with any of the selected values. The customization system will adapt the type hierarchy of the feature value accordingly. See the analysis section for an example of the impact on the type hierarchy.
This is the only obligatory question for noun classes, validation indicates an error when this question is not answered, while other questions for a given noun class are.
You must indicate whether determiners are optional, obligatory or impossible. Nouns with optional determiners can either form a noun phrase by themselves or by being combined with a determiner. If determiners are obligatory, they can only form a noun phrase (and hence only occur in a parsed sentence) when combined with a determiner. If determiners are impossible, the nouns form NPs by themselves and cannot be combined with determiners.
If you indicated on the Word Order page that the grammar does not have determiners, you must select impossible (else validation will indicate there is an error).
Here you can define the actual stems of nouns belonging to a given class. Note that classes that are meant to serve as a supertype for other noun classes should (in most cases) not have stems. You can add as many noun stems per class as you want. It is not the fastest way to define a large scale lexicon, so you probably want to limit it to a hand-full that allows you to build decent test suites.
For each noun stem, spelling and a predicate must be provided. After you fill out the spelling and hit tab, a predicate name based on the stem and MRS standards is suggested. This has the following form:
Spelling: myStem Predicate: _myStem_n_rel
You can change the predicate if you like, but it is recommended to stick to the conventions of starting with _ and ending nominal relations by _n_rel.
Pronouns are a typical examples where Predicates are not based on the spelling of the stem (e.g. _pronoun_n_rel, _pro_n_rel for all pronouns, INDEX features indicate the person, number, gender and other distinctive properties it may have).
This part of the lexicon library allows you to define interactions with morphotactics, which morphemes are required and which are forbidden to combine with a given lexical type.
When you click either of the buttons, a constraint description appears with a drop-down menu. The position classes and morphological rules defined for nouns on the morphology page appear in the drop-down. Select a class to define complete the constraint. You can define as many constraints as necessary.
A Require constraint makes sure the lexical item is only accepted as a word after combining with a morpheme belonging to the selected position class or an instance of the selected lexical rule (depending on whether a position class or lexical rule was selected).
A Forbid constraint makes sure the lexical item cannot combine with a morpheme belonging to the selected position class or an instance of the selected lexical rule (depending on whether a position class or lexical rule was selected).
The following information can be provided for each noun type:
- Type name
- Supertypes
- Features (name, value, specified on)
- Argument structure
- Stems (Spelling Predicate)
- Morphotactic constraints
A more detailed description of each of these properties follows below
Defines the name of the class of verbs (similar to nouns). It should be noted that:
-
The suffix -verb-lex will be added to the given name, e.g. trans becomes trans-verb-lex and trans-verb, trans-verb-verb-lex
-
Verb types without a type name will be numbered: verb1-verb-lex, verb2-verb-lex, etc.
-
Good engineering style: pick transparent names, such as trans and intrans, nom-acc-trans, nom-dat-trans rather than cryptic names
This dropbox allows you to select supertypes of the verb-class. The dropbox will contain all other verb types you have defined, the order is not relevant. You can select several supertypes. This is useful if you want to cross-classify properties such as argument structure, case marking on arguments and subject or object agreement (if not handled by morphotactics).
A verb inherits the feature values of its supertype. For instance:
- verb_type1 has the feature value [CASE nom] marked on subject
- verb_type2 has argument-structure intransitive
- verb_type3 has argument-structure transitive
- verb_type5 has supertypes verb_type1 and verb_type2
- verb_type6 has supertypes verb_type1 and verb_type3
In the resulting grammar, all verbs belonging to the class of verb_type5 will be intransitive verbs with nominative subjects, all verbs belonging to the class of verb_type6 will be transitive verbs with nominative subjects.
Next to Verb Types, you find a(n experimental) link saying visualize verb hierarchy. It will display the supertype relations that are defined at that moment as a hierarchy.
Cycles of inheritance are not allowed (and they do not make sense anyway). So if verb_type2 is a supertype of verb_type1, verv_type1 may not be a supertype of verb_type2. Note that the supertype-subtype relation is transitive, so if a := b indicates a supertype relation where b is supertype of a, the following is forbidden as well:
a := b.
b := c.
c := a.
In the supertype hierarchy above, c is a supertype of a through b. So a cannot be a supertype of c
CAREFUL!!!!!!
Validation does not check whether constraints on supertypes and subtypes are compatible. This means that grammars with such errors can be created by the customization system, but they will not load in lkb and cannot be compiled to work with PET or ACE. An example of this would be the following:
VerbType 1
Type name: past
supertype: present-v
Feature: TENSE past
NounType 2
Type name: present-v
Feature: TENSE present
The past verb will inherit the property [TENSE present] from the future verb, but have the additional property of [TENSE past] from its own definition. Assuming that past and future are conflicting values, the grammar contains an ill-defined type. The following hierarchy would be possible:
VerbType 1
Type name: past
supertype: past-v
Feature: TENSE past
VerbType 2
Type name: present
Feature: TENSE present, past
In this case, Verb Type 2 will have a value for TENSE that is an underspecification of present and past (typically this would be non-future defined on verbal features). This value can unify with the value of Noun Type 1.
There is a bug report for this problem, but it is extremely hard to implement so that it works at the time of validation. So for now and the near future: pay attention while defining inheritance!
The Feature option for verbs has three fields name, value and specified on. The name of the feature can be selected under name, its value(s) under value and where the feature-value pair applies to under specified on. Further explanation follows below.
The first two drop-boxes will show features and values based on what was filled out at the pages Person, Number, Gender, Case, Tense-Mood-Aspect and Other Features. The first four libraries (Person, Number, Gender, Case) each define features typically appropriate for nouns. Tense-Mood-Aspect provide the means to define typical verbal features (including grammatical features such as finiteness). Other Features allows you to define customized features, which can be assigned to nouns, verbs or both. All features, regardless of whether they are defined for nouns, verbs or both categories will appear in the drop-box.
The third drop-box provides five options: the verb, the subject NP, the object NP, the higher-ranked NP and the lower-ranked NP. Typical verbal properties such as Tense, Aspect, Mood and verb form should be assigned to the verb. Agreement between verbs and their arguments can be modeled by assigning properties to an NP. Be careful to only assign properties that are defined for verbs or both categories to the verb and only properties that are defined for nouns or both to the NPs. Currently validation does not check for such errors. You will therefore be allowed to do define properties this way on the questionnaire, but your grammar will not load. A bug report has been filed to fix validation.
If your grammar has optional arguments and you defined the related properties on Argument Optionality page of the questionnaire, you can define which arguments are optional and which are not by defining feature value pair [OPT +] and [OPT -], respectively, for the arguments in question. In other words, an optional object is defined by assigning [OPT +] to the Object NP. The OPT feature cannot be defined for the verb. Validation checks for this.
Select the feature you want to specify from the left drop-box. Appropriate values will appear in the right drop-box. Each value is preceded by a check box. You can select as many values as you want for each feature (but note that selecting all values leads to the same behavior as not specifying a feature value pair at all). Assign the feature value pair to the appropriate element, keeping in mind the comments made above.
If you select more than one value for a feature, the verb class will assign an underspecified value to the feature that may unify with any of the selected values. The customization system will adapt the type hierarchy of the feature value accordingly. See the analysis section for an example of the impact on the type hierarchy.
Please not that you cannot define argument-structure here, argument-structure should be defined by the special argument-structure drop-down explained below. The option argument-structure is intended for the morphemes only (to be defined on the morphology page).
The argument structure drop-box allows you to indicate whether a verb is transitive or intransitive. Depending on the definitions you provided on the case page, the drop-box also provides the standard case marking of your language's subjects and objects (e.g. intransitive (nom) transitive (nom-acc), intransitive (erg), transitive (erg-abs)). For split case marking, no basic marking will be given for the case marking on the argument structure.
If you want to define a verb with non-standard case marking (e.g. a verb with dative objects in a nominative-accusative language, nominative-nominative case marking for copula verbs), you can select the option (case unspecified). You can then specify the case marking on subject and object using 'features'.
=== Stems ===
Here you can define the actual stems of verbs belonging to a given class. Note that classes that are meant to serve as a supertype for other verb classes should (in most cases) not have stems. You can add as many verb stems per class as you want. It is not the fastest way to define a large scale lexicon, so you probably want to limit it to a hand-full that allows you to build decent test suites.
For each verb stem, spelling and a predicate must be provided. After you fill out the spelling and hit tab, a predicate name based on the stem and MRS standards is suggested. This has the following form:
Spelling: myStem Predicate: _myStem_v_rel
You can change the predicate if you like, but it is recommended to stick to the conventions of starting with _ and ending verbal relations by _v_rel.
"The term bipartite stem was coined by William Jacobsen (1980) to describe a pervasive type of verb formation in Washo, a Hokan language of western Nevada in which [...] bound morphemes neither of which can constitute a verb stem on its own, are combined to form a “bipartite” stem." (DeLancey, p.1)
Above 'Stems' you will find the line If this verb class includes bipartite stems, select the position class for the affix portion of the stems: followed by a dropbox. Here, you can select a position class defined on the morphology page. Position classes define whether an affix is a prefix or suffix and the morphemes (stems or other affixes) it is preceded or followed by.
If the verbs in the language have positions specific to the affix of the bipartite stem, you should go to the Morphology page and define this position. You can then select it for the verb class on the lexicon page.
If you click on Add a bipartite Stem three boxes appear, one for the root, one for the affix and one for the predicate. As for regular stems, a predicate is suggested as soon as you enter the root:
Root spelling: myRoot Affix spelling: myAffix Predicate: _myroot_v_rel
This part of the lexicon library allows you to define interactions with morphotactics, which morphemes are required and which are forbidden to combine with a given lexical type.
When you click either of the buttons, a constraint description appears with a drop-down menu. The position classes and morphological rules defined for verbs on the morphology page appear in the drop-down. Select a class to define the constraint. You can define as many constraints as necessary.
A Require constraint makes sure the lexical item is only accepted as a word after combining with a morpheme belonging to the selected position class or an instance of the selected lexical rule (depending on whether a position class or lexical rule was selected).
A Forbid constraint makes sure the lexical item cannot combine with a morpheme belonging to the selected position class or an instance of the selected lexical rule (depending on whether a position class or lexical rule was selected).
Auxiliaries represent verbs that take other verbs as their complement. A basic description is provided on the lexicon page. You can add an auxiliary by clicking on the Add an Auxiliary Type. This opens up a range of relevant fields and questions to define auxiliaries.
They are:
-
Type Name
-
No predicateor An independent predicate
-
Auxiliary Features
-
Subject Type
-
Complement Features
-
Stems
-
Morphotactic Constraints
A more detailed description of each of these properties follows below (note: currently under development)
Defines the name of the class of auxiliaries (similar to nouns and verbs). It should be noted that:
-
The suffix -aux-lex will be added to the given name, e.g. modal becomes modal-aux-lex and modal-aux, modal-aux-aux-lex
-
Aux types without a type name just receive the suffix (-aux-lex), you should therefore provide a type name!
-
Good engineering style: pick transparent names, such as modal and participle, future, past rather than cryptic names
By selecting a radio button, you indicate whether the auxiliaries belonging to a class have an independent predicate (e.g. English can, may) or not (e.g. English will contributing future tense through a feature).
The Feature option for auxiliaries has three fields name, value and specified on. The name of the feature can be selected under name, its value(s) under value and where the feature-value pair applies to under specified on. Further explanation follows below.
The first two drop-boxes will show features and values based on what was filled out at the pages Person, Number, Gender, Case, Tense-Mood-Aspect and Other Features. The first four libraries (Person, Number, Gender, Case) each define features typically appropriate for nouns. Tense-Mood-Aspect provide the means to define typical verbal features (including grammatical features such as finiteness). Other Features allows you to define customized features, which can be assigned to nouns, verbs (including auxiliaries) or both. All features, regardless of whether they are defined for nouns, verbs or both categories will appear in the drop-box.
The third drop-box provides five options: the auxiliary, the subject NP, the object NP, the higher-ranked NP and the lower-ranked NP. Typical verbal properties such as Tense, Aspect, Mood and verb form should be assigned to the auxiliary. Agreement between verbs and their arguments can be modeled by assigning properties to an NP. Be careful to only assign properties that are defined for auxiliaries or both categories to the auxilaries and only properties that are defined for nouns or both to the NPs. Currently validation does not check for such errors. You will therefore be allowed to do define properties this way on the questionnaire, but your grammar will not load. A bug report has been filed to fix validation.
If your grammar has optional arguments and you defined the related properties on Argument Optionality page of the questionnaire, you can define which arguments are optional and which are not by defining feature value pair [OPT +] and [OPT -], respectively, for the arguments in question. In other words, an optional object is defined by assigning [OPT +] to the Object NP. The OPT feature cannot be defined for the verb. Validation checks for this.
Select the feature you want to specify from the left drop-box. Appropriate values will appear in the right drop-box. Each value is preceded by a check box. You can select as many values as you want for each feature (but note that selecting all values leads to the same behavior as not specifying a feature value pair at all). Assign the feature value pair to the appropriate element, keeping in mind the comments made above.
If you select more than one value for a feature, the auxiliary class will assign an underspecified value to the feature that may unify with any of the selected values. The customization system will adapt the type hierarchy of the feature value accordingly. See the analysis section for an example of the impact on the type hierarchy.
Please not that you cannot define argument-structure here, the argument-structure for auxiliaries is currently defined on the word order page, because its specifications are mostly seen in word order. In principle, all that can be defined on argument structure for auxiliaries is which arguments of the verbal complement are raised, and which are picked up by the verbal complement itself. The option argument-structure is intended for the morphemes only (to be defined on the morphology page).
Here you can define the kind of subject the auxiliary takes. There are three options concerning case marking of nouns and the option to select an adpositional phrase as a subject. Case options include no case marking, the case the verbal complement assigns to its subject, i.e. similar to a raising analysis and receiving the following case from the auxiliary, which allows you to define a specific case the auxiliary will assign to the subject.
Click on the button Add a complement feature to define features on the verbal complement. As mentioned on the page, a feature for FORM is required. If no feature values for form where defined, the options finite and nonfinite will be available for FORM.
The features in the drop-down menu are all suitable for verbal complements.
Here you can define the actual stems of auxiliaries belonging to a given class. You can add as many stems per auxiliary class as you want.
For each auxiliary stem must be provided. Depending on the option you filled out regarding predicates (No predicate or An independent predicate) you may also need to define a predicate (validation will throw an error if you define a predicate for a predicateless auxiliary or no predicate for an auxiliary requiring one). Since not all auxiliaries have their own predicate, no predicate form is suggested for auxiliaries. The recommended form is however similar to that of nouns and main verbs:
Spelling: myStem Predicate: _myStem_v_rel
You can provide any predicate you like, but it is recommended to stick to the conventions of starting with _ and ending verbal relations by _v_rel.
This part of the lexicon library allows you to define interactions with morphotactics, which morphemes are required and which are forbidden to combine with a given lexical type.
When you click either of the buttons, a constraint description appears with a drop-down menu. The position classes and morphological rules defined for verbs on the morphology page appear in the drop-down. Note that position classes for auxiliaries are included in position classes for verbs. Select a class to define the constraint. You can define as many constraints as necessary.
A Require constraint makes sure the lexical item is only accepted as a word after combining with a morpheme belonging to the selected position class or an instance of the selected lexical rule (depending on whether a position class or lexical rule was selected).
A Forbid constraint makes sure the lexical item cannot combine with a morpheme belonging to the selected position class or an instance of the selected lexical rule (depending on whether a position class or lexical rule was selected).
The following information can be provided for each determiner:
- Type name
- Stems
- Features
- Morphotactic constraints
Defines the name of the class of auxiliaries (similar to nouns, verbs and determiners). It should be noted that:
-
The suffix -determiner-lex will be added to the given name, e.g. def becomes def-determiner-lex and def-det, def-det-determiner-lex
-
Determiner types without a type name will be numbered: det1-determiner-lex, det2-determiner-lex, etc.
-
Good engineering style: pick transparent names, such as definite and def-nom-sg, indef-fem-erg rather than cryptic names
Here you can define the actual stems of determiners belonging to a given class. You can add as many determiner stems per class as you want.
For each determiner stem, spelling and a predicate must be provided. After you fill out the spelling and hit tab, a predicate name based on the stem and MRS standards is suggested. This has the following form:
Spelling: myStem Predicate: _myStem_q_rel
You can change the predicate if you like, but it is recommended to stick to the conventions of starting with _ and ending quantifier relations by _q_rel.
The Feature option for verbs has three fields name, value. You can select a feature under name and its value(s) under value.
The drop-boxes will show features and values based on what was filled out at the pages Person, Number, Gender, Case and Other Features. The first four libraries (Person, Number, Gender, Case) each define features typically appropriate for nouns, which can also be assigned to determiners. Other Features allows you to define customized features. These features can be assigned to nouns, verbs or both. Features that are defined for both categories or for nouns will appear in the drop-box.
Select the feature you want to specify from the left drop-box. Appropriate values will appear in the right drop-box. Each value is preceded by a check box. You can select as many values as you want for each feature (but note that selecting all values leads to the same behavior as not specifying a feature value pair at all).
If you select more than one value for a feature, the determiner class will assign an underspecified value to the feature that may unify with any of the selected values. The customization system will adapt the type hierarchy of the feature value accordingly. See the analysis section for an example of the impact on the type hierarchy.
This part of the lexicon library allows you to define interactions with morphotactics, which morphemes are required and which are forbidden to combine with a given lexical type.
When you click either of the buttons, a constraint description appears with a drop-down menu. The position classes and morphological rules defined for determiners on the morphology page appear in the drop-down. Select a class to define the constraint. You can define as many constraints as necessary.
A Require constraint makes sure the lexical item is only accepted as a word after combining with a morpheme belonging to the selected position class or an instance of the selected lexical rule (depending on whether a position class or lexical rule was selected).
A Forbid constraint makes sure the lexical item cannot combine with a morpheme belonging to the selected position class or an instance of the selected lexical rule (depending on whether a position class or lexical rule was selected).
This part of the lexicon page allows you to define case marking adpositions. Unlike the other lexical items on this page, you cannot define an adposition class, but only individual adpositions with grammmatical properties.
You can provide the following information for each adposition:
- Spelling
- Optionality or not
- Order (before or after the noun)
- Features
Note that these adpositions are meant to fill the role of case markers. They thus have no predicates of their own. If the adposition is optional, check the check box before 'optional' in the sentence following Spelling.
You can indicate whether the adposition is a preposition or postposition by indicating whether it appears before or after the noun phrase.
The Feature option for verbs has three fields name, value. You can select a feature under name and its value(s) under value.
The drop-boxes will show features and values based on what was filled out at the pages Person, Number, Gender, Case and Other Features. The first four libraries (Person, Number, Gender, Case) each define features typically appropriate for nouns, which can all be defined on adpositions. Other Features allows you to define customized features. These features can be assigned to nouns, verbs or both. Features that are defined for both categories or for nouns will appear in the drop-box.
Select the feature you want to specify from the left drop-box. Appropriate values will appear in the right drop-box. Each value is preceded by a check box. You can select as many values as you want for each feature (but note that selecting all values leads to the same behavior as not specifying a feature value pair at all).
If you select more than one value for a feature, the adposition will assign an underspecified value to the feature that may unify with any of the selected values. The customization system will adapt the type hierarchy of the feature value accordingly. See the analysis section for an example of the impact on the type hierarchy.
If you select more than one value for a feature, the noun class will assign an underspecified value to the feature that may unify with any of the selected values. The customization system will adapt the type hierarchy of the feature value accordingly.
For instance, the basic customized hierarchy for the option 'first-second-third' person and 'none' first person distinction will look as follows:
person := avm.
1st := person.
2nd := person.
3rd := person.
If you define the following Feature-value pair:
Feature: PERSON value [x] 1st []2nd [x]3rd
The hierarchy will look like this:
person := avm.
2nd := person.
non-2nd := person.
1st := non-2nd.
3rd := non-2nd.
The resulting noun class will bear the feature-value pair [PERSON non-2nd]
- [ This documentation is under construction. When it is more complete, this section should describe the analyses that are implemented as part of this library and/or point to publications where those analyses are described. ]
The lexicon will soon be extended to cover modification. This will include adpositions, adjectives and possibly adverbs.
Delancey, Scott. Bipartite Verbs in Languages of Western North America. link to the article
Drellishak, S. (2009). Widespread but Not Universal: Improving the Typological Coverage of the Grammar Matrix. PhD thesis, University of Washington.
Jacobsen, William. 1980. Washo bipartite verb stems. In: Klar et. al. (eds.) 1980:85-99.
bibtex:
@phdthesis{Drellishak:09, author = {Scott Drellishak}, year = {2009}, title = {Widespread but Not Universal: Improving the Typological Coverage of the {G}rammar {M}atrix}, school = {University of Washington} }
Home | Forum | Discussions | Events