====== HOWTO for OpenCCG Web frontend ======

[[:openccg|Main UT OpenCCG page]]

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.

===== A Basic Tutorial =====

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.

==== A very simple example ====

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:

<code>
I :- np
sleep :- s\np
</code>

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:

<code>
"I sleep": 1 parse found.

Parse: s
------------------------------
(lex)  I :- np
(lex)  sleep :- s\np
(<)    I sleep :- s
</code>

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//.

==== A simple example using features ====

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:

<code>
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
</code>

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. 

<code>
he eats apples
he wants to eat apples
he wants to eats apples
</code>

We get:

<code>
"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.
</code>

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:

<code>
"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}
</code>

Exercise: add a category for ''want'' that allows the sentence ''he wants to want to eat apples''.

[[:openccg/webccg_howto#Howto for OpenCCG Web frontend|Top of page]]

==== Representing more than one attribute value pair on an atomic category ====

To use more than one feature specification, separate them by commas as in the following lexicon:

<code>
a :- s\np[a=1,b=2]
z :- np[a=1,b=2]
y :- np[a=1]
x :- np[b=3]
</code>

Put the following strings into the **Sentences to parse** text field:

<code>
z a
y a
x a
</code>

The first two will succeed and the last will fail.

==== Setting two feature structures to be the same ====

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:

<code>
happily :- s<1>\s<1>
</code>

If you add this to the lexicon already defined above, you'll get the following result for the sentence //he eats apples happily//:

<code>
"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}
</code>

[[:openccg/webccg_howto#Howto for OpenCCG Web frontend|Top of page]]

==== Inheriting a subset of features rather than all ====

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:

<code>
the :- np<~1>[case=acc]/n<1>[num]
man :- n[case=nom,num=sg]
</code>

When we parse //the man//, we get:

<code>
"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}
</code>

Notice that the num feature from //man// has been inherited, but the case value was overridden.

==== Bringing these things together ====

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:

<code>
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]
</code>

Try parsing the above clauses with the features turned on and see what happens.

[[:openccg/webccg_howto#Howto for OpenCCG Web frontend|Top of page]]


==== Modalities with the web front end ====

  * ''*'' is the application only modality
  * ''x'' is the crossing modality
  * ''^'' is the diamond, or harmonic, modality
  * ''.'' or unspecified is the anything goes modality

For example:

<code>
the :- np<~1>[case=acc]/^n<1>[num]
old :- n/^n
happy :- n/*n
man :- n[case=nom,num=sg]
</code>

If we parse //the happy// and //the old//, we get:

<code>
"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
</code>

As desired.

===== Caveats =====

The following are still not operational:

  * semantics are not supported with the frontend (i.e., the **Show Semantics** option won't do much unless you really know how to work it)

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.

[[:openccg/webccg_howto#Howto for OpenCCG Web frontend|Top of page]]