An Open Source Urdu Resource Grammar
Shafqat M Virk
Department of Applied IT
University of Gothenburg
virk@chalmers.se
Muhammad Humayoun
Laboratory of Mathmatics
University of Savoie
mhuma@univ-savoie.fr
Aarne Ranta
Department of CS & Eng
University of Gothenburg
aarne@chalmers.se

Abstract

We develop a grammar for Urdu in
Grammatical Framework (GF). GF is a
programming language for defining
multilingual grammar applications. GF
resource grammar library currently
supports 16 languages. These grammars
follow an Interlingua approach and
consist of morphology and syntax
modules that cover a wide range of
features of a language. In this paper we
explore different syntactic features of the
Urdu language, and show how to fit them
in the multilingual framework of GF. We
also discuss how we cover some of the
distinguishing features of Urdu such as,
ergativity in verb agreement (see Sec
4.2). The main purpose of GF resource
grammar library is to provide an easy
way to write natural language
applications without knowing the details
of syntax, morphology and lexicon. To
demonstrate it, we use Urdu resource
grammar to add support for Urdu in the
work reported in (Angelov and Ranta,
2010) which is an implementation of
Attempto (Attempto 2008) in GF.

1. Introduction

Urdu is an Indo-European language of the Indo-
Aryan family, widely spoken in south Asia. It is
a national language of Pakistan and one of the
official languages of India. It is written in a
modified Perso-Arabic script from right to left.
As regards vocabulary, it has a strong influence
of Arabic and Persian along with some
borrowing from Turkish and English. Urdu is an
SOV language having fairly free word order. It
is closely related to Hindi as both originated
from the dialect of Delhi region called khari boli
(Masica, 1991).
We develop a grammar for Urdu that addresses
problems related to automated text translation
using an Interlingua approach and provide a way
to precisely translate text. This is described in
Section 2. Then we describe different levels of
grammar development including morphology
(Section 3) and syntax (Section 4). In Section 6,
we discuss an application in which a semantics-
driven translation system is built upon these
components.

2. GF (Grammatical Framework)

GF (Grammatical Framework, Ranta 2004) is a
tool for working with grammars, implementing a
programming language for writing grammars
which in term is based on a mathematical theory
about languages and grammars
1
. Many
multilingual dialog and text generation
applications have been built using GF. GF
grammars have two levels the abstract and the
concrete syntax
2
. The abstract syntax is
language independent and is common to all
languages in GF grammar library. It is based on
common syntactic or semantic constructions,
which work for all the involved languages on an
appropriate level of abstraction. The concrete
syntax is language dependent and defines a
mapping from abstract to actual textual
representation in a specific language
2
. GF uses
the term ‘category’ to model different parts of
speech (e.g verbs, nouns adjectives etc.). An
abstract syntax defines a set of categories, as
well as a set of tree building functions. Concrete
syntax contains rules telling how these trees are
linearized. Separating the tree building rules
(abstract syntax) from linearization rules
(concrete syntax) makes it possible to have
multiple concrete syntaxes for one abstract. This
153

makes it possible to parse text in one language
and translate it to multiple languages.
Grammars in GF can be roughly classified into
two kinds: resource grammars and application
grammars. Resource grammars are general
purpose grammars (Ranta, 2009a) that try to
cover the general aspects of a language
linguistically and whose abstract syntax encodes
syntactic structures. Application grammars, on
the other hand, encode semantic structures, but
in order to be accurate they are typically limited
to specific domains. However, they are not
written from scratch for each domain, but they
use resource grammars as libraries (Ranta
2009b).
Previously GF had resource grammars for 16
languages: English, Italian, Spanish, French,
Catalan, Swedish, Norwegian, Danish, Finish,
Russian, Bulgarian, German, Interlingua (an
artificial language), Polish, Romanian and
Dutch. Most of these languages are European
languages. We developed resource grammar for
Urdu making it the 17
th
in total and the first
south Asian language. Resource grammars for
several other languages (e.g. Arabic, Turkish,
Persian, Maltese and Swahili) are under
construction.

3. Morphology

In GF resource grammars a test lexicon of 350
words is provided for each language. These
words are built through lexical functions. The
rules for defining Urdu morphology are
borrowed from (Humayoun et el., 2006), in
which Urdu morphology was developed in the
Functional Morphology toolkit (Forsberg and
Ranta, 2004). Although it is possible to
automatically generate equivalent GF code from
it, we wrote the rules of morphology from
scratch in GF, to receive better abstractions than
are possible in generated code. Furthermore, we
extend this work by including compound words.
However, the details of morphology are beyond
the scope of this paper, and its focus is on
syntax.

4. Syntax

While morphological analysis deals with the
formation and inflection of individual words,
syntax shows how these words (parts of speech)
are grouped together to build well formed
phrases. In this section we show how this works
and is implemented for Urdu.

4.1 Noun Phrases (NP)

When nouns are to be used in sentences as part
of speech, then there are several linguistic
details which need to be considered. For
example other words can modify a noun, and
nouns have characteristics such as gender,
number etc. When all such required details are
grouped together with the noun, the resulting
structure is known as noun phrase (NP). The
basic structure of Urdu noun phrase is, “(M) H
(M)” according to (Butt M., 1995), where (M) is
a modifier and (H) is the head of a NP. Head is
the word which is compulsory and modifiers can
or cannot be there. In Urdu modifiers are of two
types pre-modifiers i.e modifiers that come
before the head for instance (_'- _''´ kali: bli:
“black cat”), and post-modifiers which come
after the head for instance (-- »- tm sb “you
all”). In GF resource library we represent NP as
a record

Thus NP is a record with two fields, ’s’ and ’a’.
‘s’ is an inflection table and stores different
forms of a noun.
The Urdu NP has a system of syntactic cases
which is partly different from the morphological
cases of the category noun (N). The case
markers that follow nouns in the form of post-
positions cannot be handled at lexical level
154

through morphological suffixes and are thus
handled at syntactic level (Butt et el., 2002).
Here we create different forms of a noun phrase
to handle case markers for Urdu nouns. Here is a
short description of the different cases of NP :

And ‘a’ (Agr in the code sample given in
previous column) is the agreement feature of the
the noun that is used for selecting the
appropriate form of other categories that agree
with nouns.
A noun is converted to an intermediate category
common noun (CN; also known as N-Bar)
which is then converted to NP category. CN
deals with nouns and their modifiers. As an
example consider adjectival modification:

The linearization of AdjCN gives us common
nouns such as (_-'¸ '--+¯ n a pani: “cold
water”) where a CN (_-'¸ pani: “water”) is
modified by an AP ( '--+¯ , n a “cold”).
Since Urdu adjectives also inflect in number,
gender, case and degree, we need to concatenate
the appropriate form of adjective that agrees
with common noun. This is ensured by selecting
the corresponding forms of adjective and
common noun from their inflection tables using
selection operator (‘!’). Since CN does not
inflect in degree but the adjective does, we fix
the degree to be positive (Posit) in this
construction. Other modifiers include possibly
adverbs, relative clauses, and appositional
attributes.
A CN can be converted to a NP using different
functions: common nouns with determiners;
proper names; pronouns; and bare nouns as mass
terms:

These different ways of building NP’s, which
are common in different languages, are defined
in the abstract syntax of the resource grammar,
but the linearization of these functions is
language dependent and is therefore defined in
the concrete syntaxes.

4.2 Verb Phrases (VP)

A verb phrase is a single or a group of words
that act as a predicate. In our construction Urdu
verb phrase has following structure

In GF representation a VP is a record with
different fields. The most important field is ‘s’
which is an inflectional table and stores different
forms of Verb.
At VP level we define Urdu tenses by using a
simplified tense system, which has only three
tenses, named VPPres, VPPast, VPFutr. In case
of VPTense for every possible combination of
VPPTense and agreement (gender, number,
person) a tuple of two string values {fin, inf :
Str} is created. ‘fin’ stores the coupla (auxiliary
verb) , and ‘inf’ stores corresponding form of
verb. VPStem is a special tense which stores the
root form of verb. This form is used to create the
full set of Urdu tenses at clause level (tenses in
which the root form of verb is used, i.e.
perfective and progressive tenses). Handling
tenses at clause level rather than at verb phrase
level simplifies the VP and results in a more
efficient grammar.
The resource grammar has a common API
which has a much simplified tense system,
which is close to Germanic languages. It is
divided into tense and anteriority. There are only
four tenses named as present, past, future and
conditional, and two possibilities of anteriority
(Simul , Anter). This means it creates 8
combinations. This abstract tense system does
not cover all the tenses in Urdu. We have
covered the rest of tenses at clause level, even
though these tenses are not accessible by the
common API, but still can be used in language
specific modules.
Other forms for verb phrases include request
form (VPReq), imperative form (VPImp). There
are four levels of requests in Urdu. Three of
them correspond to (t ,-, tm »- , a:p _' ) honor
levels and the fourth is neutral with respect to
honorific levels. .
The Urdu VP is a complex structure that has
different parts: the main part is a verb and then
there are other auxiliaries attached to verb. For
example an adverb can be attached to a verb as a
modifier. We have a special field ‘ad’ in our VP
representation. It is a simple string that can be
attached with the verb to build a modified verb.
In Urdu the complement of a verb precedes the
actual verb e.g (_, _-,'¡ '-¸,- -, o d na t ahti:
he: “she want to run”), here ('-,'¡ t ahna “want”)
is complement of verb ('-¸,- d na “run”),
except in the case where, a sentence or a
question is the complement of the verb. In that
case complement of the verb comes at the very
end of clause e.g ( o khta he: kh o d ti: he: -,
_, _-¸,- -, -´ _, '-¸´ “he says that she runs”).
We have two different fields named ‘compl’ and
‘embCompl’ in the VP to deal with these
different situations.
‘vType’ field is used to store information about
type of a verb. In Urdu a verb can be transitive,
intransitive or double-transitive (Schmidt R. L.,
1999). This information is important when
dealing with ergativity in verb agreement. The
information about the object of the verb is stored
in ‘obj’ field. All this information that a VP
carries is used when a VP is used in the
construction of a clause.
A distinguishing feature of Urdu verb agreement
is ‘ergativity’. Urdu is one of those languages
that shows split ergativity at verb level. Final
verb agreement is with direct subjective except
in the transitive perfective tense. In transitive
perfective tense verb agreement is with direct
object. In this case the subject takes the ergative
construction (subject with addition of ergative
case marker (ne: _-).
However, in the case of the simple past tense,
verb shows ergative behavior, but in case of
other perfective tenses (e.g immediate past,
remote past etc) there are two different
approaches, in first one auxiliary verb (t ka '´¡)
is used to make clauses. If (t ka '´¡) is used,
verb does not show ergative behavior and final
verb agreement is with direct subjective.
Consider the following example

In the first case the subject (l ka, '´¸' “boy”) is
in direct case and auxiliary verb agrees to
subject, but in second case verb is in agreement
with object and ergative case of subject is used.
However, in the current implementation we
follow the first approach.
156

In the concrete syntax we ensure this ergative
behavior through the following code segment in
GF. However the code given here is just a
segment of the code that is relevant.

case vt of {
VPPast => case vp.vType of {
(Vtrans| VTransPost) => <NPErg, vp.obj.a>
_ => <NPC Dir, np.a>
} ;
_ => <NPC Dir, np.a>
} ;
e.g in case of simple past tense if verb is
transitive then ergative case of noun is used and
agreement is with object of verb. In all other
cases direct case of noun is used and agreement
is with subject of verb.
A VP is constructed in different ways; the
simplest is

fun UseV : V -> VP ;

where V is the morphological category and VP
is the syntactic category. There are other ways to
make a VP from other categories, or
combinations of categories. For example

fun AdvVP : VP -> Adv -> VP ;

An adverb can be attached to a VP to make an
adverbial modified VP. For example (i:ha ¸'¸,
'-,-)

4.3 Adjective Phrases (AP)

Adjectives (A) are converted into the much
richer category adjectival phrases (AP) at syntax
level. The simplest function to convert is

fun PositA : A -> AP ;

Its linearization is very simple, since in our case
AP is similar to A e.g.

fun PositA a = a ;

There are other ways of making AP for example

fun ComparA : A -> NP -> AP ;

When a comparative AP is created from an
adjective and a NP, constant “se: _-” is used
between oblique form of noun and adjective. For
example linearization of above function is

A clause is a syntactic category that has variable
tense, polarity and order. Predication of a NP
and VP gives simplest clause

fun PredVP : NP -> VP -> Cl ;

The subject-verb agreement is insured through
agreement feature of NP which is passed to verb
as inherent feature. A clause is of following type

lincat Clause : Type = {s : VPHTense =>
Polarity => Order => Str} ;

Here VPHTense represents different tenses in
Urdu. Even though current abstract level of
common API does not cover all tenses of Urdu,
we cover them at clause level and can be
accessed through language specific module. So,
VPHTense is of following type

Polarity is used to make positive and negative
sentences; Order is used to make simple and
interrogative sentences. These parameters are of
following forms

Polarity = Pos | Neg
Order = ODir | OQuest

PredVP function will create clauses with
variable tense, polarity and order which are
157

fixed at sentence level by different functions,
one is.

fun UseCl : Temp -> Pol -> Cl -> S

Here Temp is syntactic category which is in the
form of a record having field for Tense and
Anteriority. Tense in the Temp category refers
to abstract level Tense and we just map it to
Urdu tenses by selecting the appropriate clause.
This will create simple declarative sentence,
other forms of sentences (e.g Question
sentences) are handled in Questions categories
of GF which follows next.

4.5 Question Clauses and Question
Sentences

Common API provides different ways to create
question clauses. The simplest way is to create
from simple clause

fun QuestCl : Cl -> QCl ;

In Urdu simple interrogative sentences are
created by just adding “ki:a ',´” at the start of a
direct clause that already have been created at
clause level. Hence, the linearization of above
function simply selects appropriate form of
clause and adds “ki:a ',´” at the start. However
this clause still has variable tense and polarity
which is fixed at sentence level e.g

fun UseQCl : Temp -> Pol -> QCl -> QS

Other forms of question clauses include clauses
made with interrogative pronouns (IP),
interrogative adverbs (IAdv), and interrogative
determiners (IDet), categories. Some of the
functions for creating question clauses are

As an example consider the translation of
following sentence from English to Urdu, to see
how our proposed system works at different
levels.

He drinks hot milk.
Figure 1 shows the parse tree for this sentence.
As a resource grammar developer our goal is to
provide correct concrete level linearization of
this tree for Urdu.

Figure 1. Parse tree of an example sentence

The nodes in this tree represent different
categories and its branching shows how a
particular category is built from other categories
and/or leaves (words from lexicon). In GF
notation these are the syntactic rules which are
declared at abstract level. For example category
CN can be built from an AP (adjectival phrase)
and a CN. So in GF representation it has
following type signature.

A NP is constructed from this CN by one of the
NP construction rules (see section 4.1 for
details). A VPSlash (object missing VP) is build
from a two place verb ('-,¸ pi:ta “drinks”). This
VPSlash is then converted to VP through
function

An experiment of implementing Controlled
languages in GF is reported in (Angelov and
Ranta, 2010). In this experiment, a grammar for
Attempto Controlled English (Attempto, 2008)
is implemented and then ported to six languages
(English, Finnish, French, German, Italian, and
Swedish) using the GF resource library. To
demonstrate the usefulness of our grammar and
to check its correctness, we have added Urdu to
this set. Now, we can translate Attempto
documents between all of these seven languages.
The implementation followed the general recipe
for how new languages can be added (Angelov
and Ranta, 2009) and created no surprises.
However the details of this implementation are
beyond the scope of this paper.

7. Related Work

A suite of Urdu resources were reported in
(Humayoun et el., 2006) including a fairly
complete open-source Urdu morphology and a
small fragment of syntax in GF. In this sense, it
is a predecessor of Urdu resource grammar,
implemented in a different but related
formalism.
Like the GF resource library, Pargram project
(Butt et el., 2007) aims at building a set of
parallel grammars including Urdu. The
grammars in Pargram are connected with each
other by transfer functions, rather than a
common representation. Further, the Urdu
grammar is still one of the least implemented
grammars in Pargram at the moment. This
project is based on the theoretical framework of
lexical functional grammar (LFG).
Other than Pargram, most work is based on LFG
and translation is unidirectional i.e. from
English to Urdu only. For instance, English to
Urdu MT System is developed under the Urdu
Localization Project (Hussain, 2004), (Sarfraz
and Naseem, 2007) and (Khalid et el., 2009).
Similarly, (Zafer and Masood, 2009) reports
another English-Urdu MT system developed
with example based approach. On the other
hand, (Sinha and Mahesh, 2009) presents a
strategy for deriving Urdu sentences from
English-Hindi MT system. However, it seems to
be a partial solution to the problem.

8. Future Work

The common resource grammar API does not
cover all the aspects of Urdu language, and non-
generalizable language-specific features are
supposed to be handled in language-specific
modules. In our current implementation of Urdu
resource grammar we have not covered those
features. For example in Urdu it is possible to
build a VP from only VPSlash (VPSlash
category represents object missing VP) e.g (_,
'-'+´ kata he:) without adding the object. This
rule is not present in the common API. One
direction for future work is to cover such
language specific features.
Another direction for future work could be to
include the causative forms of verb which are
not included in the current implementation due
to efficiency issues.

9. Conclusion

The resource grammar we develop consists of
44 categories and 190 functions
3
which cover a
fair enough part of language and is enough for
159

building domain specific application grammars
including multilingual dialogue systems,
controlled language translation, software
localization etc. Since a common API for
multiple languages is provided, this grammar is
useful in applications where we need to parse
and translate the text from one to many other
languages.
However our approach of common abstract
syntax has its limitations and does not cover all
aspects of Urdu language. This is why it is not
possible to use our grammar for arbitrary text
parsing and generation.

Danish. However. they are not written from scratch for each domain. German. Persian. In GF resource library we represent NP as a record lincat NP : Type = {s : NPCase => Str . In Urdu modifiers are of two types pre-modifiers i.makes it possible to parse text in one language and translate it to multiple languages. and post-modifiers which come after the head for instance (   tm sb “you all”). The rules for defining Urdu morphology are borrowed from (Humayoun et el.e modifiers that come before the head for instance (  kali: bli: “black cat”). Thus NP is a record with two fields. Maltese and Swahili) are under construction. number etc. where (M) is a modifier and (H) is the head of a NP. Grammars in GF can be roughly classified into two kinds: resource grammars and application grammars. These words are built through lexical functions. UPerson = Pers1| Pers2_Casual | Pers2_Familiar | Pers2_Respect | Pers3_Near | Pers3_Distant. encode semantic structures.
4. Resource grammars are general purpose grammars (Ranta. When all such required details are grouped together with the noun. and nouns have characteristics such as gender.
Morphology
In GF resource grammars a test lexicon of 350 words is provided for each language. 2004). However. Application grammars. to receive better abstractions than are possible in generated code. Number = Sg | Pl . Bulgarian. and its focus is on syntax. we extend this work by including compound words..|NPAcc Case = Dir | Obl | Voc . the resulting structure is known as noun phrase (NP).. then there are several linguistic details which need to be considered. where NPCase = NPC Case | NPErg | NPAbl |NPIns|NPLoc1NPLoc2 |NPDat. Catalan. The Urdu NP has a system of syntactic cases which is partly different from the morphological cases of the category noun (N). 4. ’s’ and ’a’. For example other words can modify a noun. but in order to be accurate they are typically limited to specific domains. but they use resource grammars as libraries (Ranta 2009b). “(M) H (M)” according to (Butt M. Arabic. we wrote the rules of morphology from scratch in GF. Romanian and Dutch.g. Italian.
syntax shows how these words (parts of speech) are grouped together to build well formed phrases. Polish. Most of these languages are European languages. ‘s’ is an inflection table and stores different forms of a noun. Norwegian. on the other hand. Furthermore. 1995). Resource grammars for several other languages (e. a : Agr} . French. the details of morphology are beyond the scope of this paper. Gender = Masc | Fem . Head is the word which is compulsory and modifiers can or cannot be there. The basic structure of Urdu noun phrase is. Interlingua (an artificial language). Russian. Spanish. In this section we show how this works and is implemented for Urdu.
Syntax
While morphological analysis deals with the formation and inflection of individual words. Previously GF had resource grammars for 16 languages: English. The case markers that follow nouns in the form of postpositions cannot be handled at lexical level
3.1 Noun Phrases (NP)
When nouns are to be used in sentences as part of speech.

154
. 2006). 2009a) that try to cover the general aspects of a language linguistically and whose abstract syntax encodes syntactic structures. We developed resource grammar for Urdu making it the 17th in total and the first south Asian language. Although it is possible to automatically generate equivalent GF code from it. in which Urdu morphology was developed in the Functional Morphology toolkit (Forsberg and Ranta. Agr = Ag Gender Number UPerson . Finish. Turkish. Swedish.

2002). also known as N-Bar) which is then converted to NP category. relative clauses. comp : Agr => Str. n a “cold”). proper names. case and degree. lin AdjCN ap cn = { s = \\n.g he) fun MassNP : CN -> NP (e. This is ensured by selecting
A verb phrase is a single or a group of words that act as a predicate. a : Agr} .s ! n ! c . we fix the degree to be positive (Posit) in this construction. 4. vType : VType .g ! c ! Posit ++ cn. which are common in different languages. HLevel = Tu |Tum |Ap |Neutr

155
.s ! n ! cn. As an example consider adjectival modification: fun AdjCN : AP -> CN -> CN .through morphological suffixes and are thus handled at syntactic level (Butt et el. we need to concatenate the appropriate form of adjective that agrees with common noun. gender. obj : {s : Str . Here we create different forms of a noun phrase to handle case markers for Urdu nouns. and appositional attributes. In our construction Urdu verb phrase has following structure lincat VP = { s : VPHForm => {fin. Since Urdu adjectives also inflect in number. embComp : Str . ad : Str } . CN deals with nouns and their modifiers. Other modifiers include possibly adverbs. A noun is converted to an intermediate category common noun (CN. inf: Str} . A CN can be converted to a NP using different functions: common nouns with determiners. and bare nouns as mass terms: fun DetCN : Det -> CN -> NP (e. are defined in the abstract syntax of the resource grammar.g John) fun UsePron : Pron -> NP (e. g = cn.g the boy) fun UsePN : PN -> NP (e..2 Verb Phrases (VP)
And ‘a’ (Agr in the code sample given in previous column) is the agreement feature of the the noun that is used for selecting the appropriate form of other categories that agree with nouns. pronouns. The linearization of AdjCN gives us common nouns such as (  n a pani: “cold water”) where a CN ( pani: “water”) is modified by an AP ( . Since CN does not inflect in degree but the adjective does. but the linearization of these functions is language dependent and is therefore defined in the concrete syntaxes.c => ap. where VPHForm = VPTense VPPTense Agr | VPReq HLevel | VPStem and VPPTense = VPPres |VPPast |VPFutr.g }. Here is a short description of the different cases of NP : • • • • • • • • NPC Case: this is used to retain the original case of Noun NPErg: Ergative case with case marker ‘ne: ’ NPAbl: Ablative with case marker ‘se: ’ NPIns: Instrumental case with case marker ‘se: ’ NPLoc1: Locative case with case marker ‘mi: ’ NPLoc2: Locative case with case marker ‘pr ’ NPDat: Dative case with case marker ‘k ’ NPAcc: Accusative case with case marker ‘k 
the corresponding forms of adjective and common noun from their inflection tables using selection operator (‘!’).g milk) These different ways of building NP’s.

here ( t ahna “want”) is complement of verb ( d na “run”). but in second case verb is in agreement with object and ergative case of subject is used. i. The Urdu VP is a complex structure that has different parts: the main part is a verb and then there are other auxiliaries attached to verb. In Urdu the complement of a verb precedes the actual verb e. 1999). Other forms for verb phrases include request form (VPReq). past. person) a tuple of two string values {fin. L. but still can be used in language specific modules. except in the case where. In this case the subject takes the ergative construction (subject with addition of ergative case marker (ne: ).g immediate past.g ( o khta he: kh o d ti: he:        “he says that she runs”). perfective and progressive tenses). In Urdu a verb can be transitive. Consider the following example  l ka Direct ktab Direct xri:d Root t ka aux_verb he: The boy has bought a book The second way to make the same clause is  l ke: ne: Erg ktab Direct_Fem xri:di: Direct_Fem he: The boy has bought a book In the first case the subject (l ka. verb shows ergative behavior. named VPPres. but in case of other perfective tenses (e. There are four levels of requests in Urdu. Anter). We have two different fields named ‘compl’ and ‘embCompl’ in the VP to deal with these different situations. imperative form (VPImp). This abstract tense system does not cover all the tenses in Urdu. VPPast. The most important field is ‘s’ which is an inflectional table and stores different forms of Verb. The resource grammar has a common API which has a much simplified tense system. which is close to Germanic languages. in the case of the simple past tense. ‘vType’ field is used to store information about type of a verb. in the current implementation we follow the first approach. and ‘inf’ stores corresponding form of verb. in first one auxiliary verb (t ka ) is used to make clauses. All this information that a VP carries is used when a VP is used in the construction of a clause.. There are only four tenses named as present. For example an adverb can be attached to a verb as a modifier. We have covered the rest of tenses at clause level. ‘fin’ stores the coupla (auxiliary verb) . remote past etc) there are two different approaches.g ( o d na t ahti: he: “she want to run”). At VP level we define Urdu tenses by using a simplified tense system. and two possibilities of anteriority (Simul . Handling tenses at clause level rather than at verb phrase level simplifies the VP and results in a more efficient grammar. . However.

156
.In GF representation a VP is a record with different fields. number. which has only three tenses. In that case complement of the verb comes at the very end of clause e. In transitive perfective tense verb agreement is with direct object. VPFutr. intransitive or double-transitive (Schmidt R. This information is important when dealing with ergativity in verb agreement. tm  a:p ) honor levels and the fourth is neutral with respect to honorific levels. It is a simple string that can be attached with the verb to build a modified verb. VPStem is a special tense which stores the root form of verb. Three of them correspond to (t . A distinguishing feature of Urdu verb agreement is ‘ergativity’. It is divided into tense and anteriority. In case of VPTense for every possible combination of VPPTense and agreement (gender. We have a special field ‘ad’ in our VP representation. inf : Str} is created. even though these tenses are not accessible by the common API. a sentence or a
question is the complement of the verb. Final verb agreement is with direct subjective except in the transitive perfective tense. Urdu is one of those languages that shows split ergativity at verb level.  “boy”) is in direct case and auxiliary verb agrees to subject. However. This form is used to create the full set of Urdu tenses at clause level (tenses in which the root form of verb is used. This means it creates 8 combinations. The information about the object of the verb is stored in ‘obj’ field. If (t ka ) is used.e. verb does not show ergative behavior and final verb agreement is with direct subjective. future and conditional.

4.vType of { (Vtrans| VTransPost) => <NPErg. However the code given here is just a segment of the code that is relevant.obj. A VP is constructed in different ways.c. There are other ways of making AP for example fun ComparA : A -> NP -> AP . Order is used to make simple and interrogative sentences. constant “se: ” is used between oblique form of noun and adjective. e. Predication of a NP and VP gives simplest clause fun PredVP : NP -> VP -> Cl .s ! NPC Obl ++ "se:" ++ a. or combinations of categories. Here VPHTense represents different tenses in Urdu. In all other cases direct case of noun is used and agreement is with subject of verb.

157
. np.a> }. Even though current abstract level of common API does not cover all tenses of Urdu. polarity and order.g.g. VPHTense is of following type VPHTense = VPGenPres | VPPastSimple | VPFut | VPContPres | VPContPast | VPContFut | VPPerfPres | VPPerfPast | VPPerfFut | VPPerfPresCont | VPPerfPastCont | VPPerfFutCont | VPSubj Polarity is used to make positive and negative sentences. since in our case AP is similar to A e. case vt of { VPPast => case vp. _ => <NPC Dir. For example (i:ha  ) 4. Its linearization is very simple. An adverb can be attached to a VP to make an adverbial modified VP. The subject-verb agreement is insured through agreement feature of NP which is passed to verb as inherent feature. the simplest is fun UseV : V -> VP .
When a comparative AP is created from an adjective and a NP. For example fun AdvVP : VP -> Adv -> VP . vp. np. we cover them at clause level and can be accessed through language specific module.s ! n ! g ! c ! d .d => np.g in case of simple past tense if verb is transitive then ergative case of noun is used and agreement is with object of verb. So. The simplest function to convert is fun PositA : A -> AP .4 Clauses
A clause is a syntactic category that has variable tense. polarity and order which are
where V is the morphological category and VP is the syntactic category. }. These parameters are of following forms Polarity = Pos | Neg Order = ODir | OQuest PredVP function will create clauses with variable tense.3 Adjective Phrases (AP)
Adjectives (A) are converted into the much richer category adjectival phrases (AP) at syntax level.a> _ => <NPC Dir. There are other ways to make a VP from other categories. fun PositA a = a . A clause is of following type lincat Clause : Type = {s : VPHTense => Polarity => Order => Str} . For example linearization of above function is lin ComparA a np = { s = \\n.In the concrete syntax we ensure this ergative behavior through the following code segment in GF.a> }.

A correct implementation of this rule in Urdu concrete syntax ensures correct formation of a common noun (  grm d d “hot milk”) from a CN ( d d “milk”) modified by an Adjective (  . Parse tree of an example sentence The nodes in this tree represent different categories and its branching shows how a particular category is built from other categories and/or leaves (words from lexicon). Hence. grm “hot”). the linearization of above function simply selects appropriate form of clause and adds “ki:a ” at the start. He drinks hot milk. For example category CN can be built from an AP (adjectival phrase) and a CN.5 Question Clauses and Sentences Question
fun IdetQuant : IQuant -> Num -> IDet .
5.g Question sentences) are handled in Questions categories of GF which follows next. to see how our proposed system works at different levels. fun UseCl : Temp -> Pol -> Cl -> S Here Temp is syntactic category which is in the form of a record having field for Tense and Anteriority.
In Urdu simple interrogative sentences are created by just adding “ki:a ” at the start of a direct clause that already have been created at clause level.fixed at sentence level by different functions.
IP. fun AdjCN : AP -> CN -> CN . As a resource grammar developer our goal is to provide correct concrete level linearization of this tree for Urdu. The simplest way is to create from simple clause fun QuestCl : Cl -> QCl . fun PrepIP : Prep -> IP -> IAdv . In GF notation these are the syntactic rules which are declared at abstract level. So in GF representation it has following type signature. However this clause still has variable tense and polarity which is fixed at sentence level e. Some of the functions for creating question clauses are fun QuestVP walks) fun QuestIAdv does he walk) : IP -> VP -> QCl (e.g fun UseQCl : Temp -> Pol -> QCl -> QS Other forms of question clauses include clauses made with interrogative pronouns (IP). one is. This will create simple declarative sentence.g why
Figure 1.
Common API provides different ways to create question clauses. interrogative adverbs (IAdv). IAdv. 4. other forms of sentences (e.g who : IAdv -> Cl -> QCl (e.
Example
As an example consider the translation of following sentence from English to Urdu. Figure 1 shows the parse tree for this sentence. and interrogative determiners (IDet). fun AdvIP : IP -> Adv -> IP

158
. IDet etc are built at morphological level and can also be created with following functions. categories. Tense in the Temp category refers to abstract level Tense and we just map it to Urdu tenses by selecting the appropriate clause.

Finnish. A VPSlash (object missing VP) is build from a two place verb ( pi:ta “drinks”). we can translate Attempto documents between all of these seven languages. To demonstrate the usefulness of our grammar and to check its correctness. (Zafer and Masood.
Conclusion
The resource grammar we develop consists of 44 categories and 190 functions3 which cover a fair enough part of language and is enough for
______________________________
3

http://www. For example in Urdu it is possible to build a VP from only VPSlash (VPSlash category represents object missing VP) e. The implementation followed the general recipe for how new languages can be added (Angelov and Ranta. Further. English to Urdu MT System is developed under the Urdu Localization Project (Hussain.
Future Work
The common resource grammar API does not cover all the aspects of Urdu language. In this experiment. 2007) and (Khalid et el. Other than Pargram.
7. 2009) presents a strategy for deriving Urdu sentences from English-Hindi MT system. we have added Urdu to this set.
9.grammaticalframework. 2007) aims at building a set of parallel grammars including Urdu. 2008) is implemented and then ported to six languages (English. In this sense. the Urdu grammar is still one of the least implemented grammars in Pargram at the moment. Another direction for future work could be to include the causative forms of verb which are not included in the current implementation due to efficiency issues.. However. Finally clause (   h grm d d pi:ta he: “he drinks hot milk”) is build from NP ( h “he”) which is build from pronoun ( h “he”) and VP (    grm d d pi:ta he: “drinks hot milk”). One direction for future work is to cover such language specific features.html 159
. Pargram project (Butt et el. This VPSlash is then converted to VP through function fun ComplSlash : VPSlash -> NP -> VP . Similarly. For instance. Language dependent concrete syntax assures that correct forms of words are selected from lexicon and word order is according to rules of that specific language.
6.e. Resulting VP and NP are grouped together to make a VP (    grm d d pi:ta he: “drinks hot milk”). German. Now. and nongeneralizable language-specific features are supposed to be handled in language-specific modules.
An application: Attempto
implemented in a different but related formalism.. it is a predecessor of Urdu resource grammar. (Sarfraz and Naseem. 2009). 2004). In our current implementation of Urdu resource grammar we have not covered those features. On the other hand. While. French. 2009) reports another English-Urdu MT system developed with example based approach.org/lib/doc/synopsis. and Swedish) using the GF resource library.. Like the GF resource library.g (  kata he:) without adding the object.
8. 2010). This rule is not present in the common API. The grammars in Pargram are connected with each other by transfer functions. from English to Urdu only. most work is based on LFG and translation is unidirectional i. (Sinha and Mahesh.
An experiment of implementing Controlled languages in GF is reported in (Angelov and Ranta.1 for details). a grammar for Attempto Controlled English (Attempto. morphology makes sure that correct forms of words are built during lexicon development. Italian. 2009) and created no surprises. it seems to be a partial solution to the problem. However the details of this implementation are beyond the scope of this paper. rather than a common representation.A NP is constructed from this CN by one of the NP construction rules (see section 4.
Related Work
A suite of Urdu resources were reported in (Humayoun et el. 2006) including a fairly complete open-source Urdu morphology and a small fragment of syntax in GF. This project is based on the theoretical framework of lexical functional grammar (LFG).