This page provides a basic HOWTO for using the OpenCCG Web based frontend that is available at http://comp.ling.utexas.edu/ccggui/frontend. The frontend is intended for instructional purposes, not for actual grammar development (though you could use it to bootstrap the beginning of a grammar project). There are some things which are still not complete on it – see below for details.
Here is a very basic tutorial that should help you get started using the frontend. Contact Jason if you have questions, or if you have suggestions for adding further examples to the tutorial.
When you go to the frontend homepage, you’ll see two text boxes and two groups of options that can be checked. The textboxes are for the CCG Lexicon and the Sentences to Parse. Unsurprisingly, the former is where you need to enter CCG lexical entries, and the latter is where you can enter strings to test out on that lexicon. The option groups are the CCG rules which you wish to have activated and a set of general output options which we’ll cover as we go along.
Let’s start simple. Say we want to create a grammar that captures the sentence I sleep. We would put the following lexicon into the CCG Lexicon box:
I :- np sleep :- s\np
We can then enter the sentence “I sleep” into the Sentences to Parse box and press the Test Grammar button. We get the following result:
"I sleep": 1 parse found. Parse: s ------------------------------ (lex) I :- np (lex) sleep :- s\np (<) I sleep :- s
The web frontend creates a grammar specification from the lexicon and runs it in OpenCCG and returns the results to you. OpenCCG informs you that a single parse was found for the sentence and what the result category was (here, s), and then it gives the derivation. The (lex) lines indicate that a category was retrieved from the lexicon, and the (<) line indicates that the Backward Application rule was used to combine the categories of the words I and sleep.
Let’s do an example that includes features and captures the sentences he eats apples and he wants to eat apples. Put the following into the CCG Lexicon box:
he :- np wants :- (s[verbform=finite]\np)/(s[verbform=to_infinitive]\np) to :- (s[verbform=to_infinitive]\np)/(s[verbform=base]\np) eats :- (s[verbform=finite]\np)/np eat :- (s[verbform=base]\np)/np apples :- np
There is now a feature with the attribute verbform used in some of the categories. For wants the verb form has the value finite. For eat it is base. The category for to subcategorizes for a base form of a verb and returns a to_infinitive form.
Put the following into the Sentences to Parse box and press the Test Grammar button.
he eats apples he wants to eat apples he wants to eats apples
We get:
"he eats apples": 1 parse found. Parse: s ------------------------------ (lex) he :- np (lex) eats :- s\np/np (lex) apples :- np (>) eats apples :- s\np (<) he eats apples :- s "he wants to eat apples": 1 parse found. Parse: s ------------------------------ (lex) he :- np (lex) wants :- s\np/(s\np) (lex) to :- s\np/(s\np) (lex) eat :- s\np/np (lex) apples :- np (>) eat apples :- s\np (>) to eat apples :- s\np (>) wants to eat apples :- s\np (<) he wants to eat apples :- s "he wants to eats apples": Unable to parse.
Now we see the use of both the Forward Application (>) and Backward Application (<) rules and the intermediate results as the derivation is built up.
A result is returned for each sentence. As desired, the first two are parsed and the last one fails to parse. The reason for it is that it is impossible to combine the to and eats because to requires a base form of the verb while eats is a finite form.
We can see the features by selecting the Show Features option. Click the Test Grammar button, and you’ll see features on the categories. For example:
"he wants to eat apples": 1 parse found.
Parse: s{verbform=finite}
------------------------------
(lex) he :- np
(lex) wants :- s{verbform=finite}\np/(s{verbform=to_infinitive}\np)
(lex) to :- s{verbform=to_infinitive}\np/(s{verbform=base}\np)
(lex) eat :- s{verbform=base}\np/np
(lex) apples :- np
(>) eat apples :- s{verbform=base}\np
(>) to eat apples :- s{verbform=to_infinitive}\np
(>) wants to eat apples :- s{verbform=finite}\np
(<) he wants to eat apples :- s{verbform=finite}
Exercise: add a category for want that allows the sentence he wants to want to eat apples.
To use more than one feature specification, separate them by commas as in the following lexicon:
a :- s\np[a=1,b=2] z :- np[a=1,b=2] y :- np[a=1] x :- np[b=3]
Put the following strings into the Sentences to parse text field:
z a y a x a
The first two will succeed and the last will fail.
Sometimes you don’t want to change feature values, and instead just want to pass them up from an argument of a category to its result. For example, the adverb happily should apply to a inflected sentence and return an inflected sentence. Rather than give it the category s[verbform=inflected]\s[verbform=inflected], you can do the following:
happily :- s<1>\s<1>
If you add this to the lexicon already defined above, you’ll get the following result for the sentence he eats apples happily:
"he eats apples happily": 1 parse found.
Parse: s<1>{verbform=inflected}
------------------------------
(lex) he :- np
(lex) eats :- s{verbform=inflected}\np/np
(lex) apples :- np
(>) eats apples :- s{verbform=inflected}\np
(<) he eats apples :- s{verbform=inflected}
(lex) happily :- s<1>\s<1>
(<) he eats apples happily :- s<1>{verbform=inflected}
Sometimes you only want some features to be brought up rather than all (as shown above). In that case, use the inheritsFrom construct, indicated with ~. See below:
the :- np<~1>[case=acc]/n<1>[num] man :- n[case=nom,num=sg]
When we parse the man, we get:
"the man": 3 parses found.
Parse 1: np{case=acc, num=sg}
------------------------------
(lex) the :- np{case=acc, num=NUM}/n<1>{num=NUM}
(lex) man :- n{case=nom, num=sg}
(>) the man :- np{case=acc, num=sg}
Notice that the num feature from man has been inherited, but the case value was overridden.
A common point at which you need to pass feature values up is when you are ensuring that a relativized noun matches in person and number with the verb that it is “extracted” from. For example: the men that walk, the man that walks, but not *the man that walk or *the men that walks. For this, you need to explicitly name the attribute in question in your relativizer, eg as follows:
the :- np<1>/n<1> man :- n[num=3sg] men :- n[num=non3sg] that :- (n\n[num])/(s\np<1>[case=nom,num]) walks :- s\np[case=nom,num=3sg] walk :- s\np[case=nom,num=non3sg]
Try parsing the above clauses with the features turned on and see what happens.
* is the application only modalityx is the crossing modality^ is the diamond, or harmonic, modality. or unspecified is the anything goes modalityFor example:
the :- np<~1>[case=acc]/^n<1>[num] old :- n/^n happy :- n/*n man :- n[case=nom,num=sg]
If we parse the happy and the old, we get:
"the happy": Unable to parse. "the old": 1 parse found. Parse: np/^n ------------------------------ (lex) the :- np/^n (lex) old :- n/^n (>B) the old :- np/^n
As desired.
The following are still not operational:
If you are just starting out, you should ignore the Output ccg2xml option.
There is unfortunately not a lot of help with error messages right now. If you are getting errors and just can’t see what is going wrong, please get in touch with Jason right away.