λ is a binding operator, just as the first-order logic quantifiers are If we have an open formula, such as (33a), then we can bind the variable x with the λ operator, as shown in (33b) The corresponding NLTK representation is given in (33c) (33) a (walk(x) & chew_gum(x)) b λx.(walk(x) & chew_gum(x)) c \x.(walk(x) & chew_gum(x)) Remember that \ is a special character in Python strings We must either escape it (with another \), or else use “raw strings” (Section 3.4) as shown here: >>> lp = nltk.LogicParser() >>> e = lp.parse(r'\x.(walk(x) & chew_gum(x))') >>> e >>> e.free() set([]) >>> print lp.parse(r'\x.(walk(x) & chew_gum(y))') \x.(walk(x) & chew_gum(y)) We have a special name for the result of binding the variables in an expression: λ-abstraction When you first encounter λ-abstracts, it can be hard to get an intuitive sense of their meaning A couple of English glosses for (33b) are: “be an x such that x walks and x chews gum” or “have the property of walking and chewing gum.” It has often been suggested that λ-abstracts are good representations for verb phrases (or subjectless clauses), particularly when these occur as arguments in their own right This is illustrated in (34a) and its translation, (34b) (34) a To walk and chew gum is hard b hard(\x.(walk(x) & chew_gum(x)) So the general picture is this: given an open formula φ with free variable x, abstracting over x yields a property expression λx.φ—the property of being an x such that φ Here’s a more official version of how abstracts are built: (35) If α is of type τ, and x is a variable of type e, then \x.α is of type 〈e, τ〉 (34b) illustrated a case where we say something about a property, namely that it is hard But what we usually with properties is attribute them to individuals And in fact, if φ is an open formula, then the abstract λx.φ can be used as a unary predicate In (36), (33b) is predicated of the term gerald (36) \x.(walk(x) & chew_gum(x)) (gerald) Now (36) says that Gerald has the property of walking and chewing gum, which has the same meaning as (37) (37) (walk(gerald) & chew_gum(gerald)) 10.4 The Semantics of English Sentences | 387 What we have done here is remove the \x from the beginning of \x.(walk(x) & chew_gum(x)) and replaced all occurrences of x in (walk(x) & chew_gum(x)) by gerald We’ll use α[β/x] as notation for the operation of replacing all free occurrences of x in α by the expression β So (walk(x) & chew_gum(x))[gerald/x] represents the same expression as (37) The “reduction” of (36) to (37) is an extremely useful operation in simplifying semantic representations, and we shall use it a lot in the rest of this chapter The operation is often called β-reduction In order for it to be semantically justified, we want it to hold that λx α(β) has the same semantic value as α[β/x] This is indeed true, subject to a slight complication that we will come to shortly In order to carry out β-reduction of expressions in NLTK, we can call the simplify() method >>> e = lp.parse(r'\x.(walk(x) & chew_gum(x))(gerald)') >>> print e \x.(walk(x) & chew_gum(x))(gerald) >>> print e.simplify() (walk(gerald) & chew_gum(gerald)) Although we have so far only considered cases where the body of the λ-abstract is an open formula, i.e., of type t, this is not a necessary restriction; the body can be any wellformed expression Here’s an example with two λs: (38) \x.\y.(dog(x) & own(y, x)) Just as (33b) plays the role of a unary predicate, (38) works like a binary predicate: it can be applied directly to two arguments The LogicParser allows nested λs such as \x.\y to be written in the abbreviated form \x y >>> print lp.parse(r'\x.\y.(dog(x) & own(y, x))(cyril)').simplify() \y.(dog(cyril) & own(y,cyril)) >>> print lp.parse(r'\x y.(dog(x) & own(y, x))(cyril, angus)').simplify() (dog(cyril) & own(angus,cyril)) All our λ-abstracts so far have involved the familiar first-order variables: x, y, and so on —variables of type e But suppose we want to treat one abstract, say, \x.walk(x), as the argument of another λ-abstract? We might try this: \y.y(angus)(\x.walk(x)) But since the variable y is stipulated to be of type e, \y.y(angus) only applies to arguments of type e while \x.walk(x) is of type 〈e, t〉! Instead, we need to allow abstraction over variables of higher type Let’s use P and Q as variables of type 〈e, t〉, and then we can have an abstract such as \P.P(angus) Since P is of type 〈e, t〉, the whole abstract is of type 〈〈e, t〉, t〉 Then \P.P(angus)(\x.walk(x)) is legal, and can be simplified via βreduction to \x.walk(x)(angus) and then again to walk(angus) 388 | Chapter 10: Analyzing the Meaning of Sentences When carrying out β-reduction, some care has to be taken with variables Consider, for example, the λ-terms (39a) and (39b), which differ only in the identity of a free variable (39) a \y.see(y, x) b \y.see(y, z) Suppose now that we apply the λ-term \P.exists x.P(x) to each of these terms: (40) a \P.exists x.P(x)(\y.see(y, x)) b \P.exists x.P(x)(\y.see(y, z)) We pointed out earlier that the results of the application should be semantically equivalent But if we let the free variable x in (39a) fall inside the scope of the existential quantifier in (40a), then after reduction, the results will be different: (41) a exists x.see(x, x) b exists x.see(x, z) (41a) means there is some x that sees him/herself, whereas (41b) means that there is some x that sees an unspecified individual z What has gone wrong here? Clearly, we want to forbid the kind of variable “capture” shown in (41a) In order to deal with this problem, let’s step back a moment Does it matter what particular name we use for the variable bound by the existential quantifier in the function expression of (40a)? The answer is no In fact, given any variable-binding expression (involving ∀, ∃, or λ), the name chosen for the bound variable is completely arbitrary For example, exists x.P(x) and exists y.P(y) are equivalent; they are called α-equivalents, or alphabetic variants The process of relabeling bound variables is known as α-conversion When we test for equality of VariableBinderExpressions in the logic module (i.e., using ==), we are in fact testing for α-equivalence: >>> e1 = lp.parse('exists x.P(x)') >>> print e1 exists x.P(x) >>> e2 = e1.alpha_convert(nltk.Variable('z')) >>> print e2 exists z.P(z) >>> e1 == e2 True When β-reduction is carried out on an application f(a), we check whether there are free variables in a that also occur as bound variables in any subterms of f Suppose, as in the example just discussed, that x is free in a, and that f contains the subterm exists x.P(x) In this case, we produce an alphabetic variant of exists x.P(x), say, exists z1.P(z1), and then carry on with the reduction This relabeling is carried out automatically by the β-reduction code in logic, and the results can be seen in the following example: 10.4 The Semantics of English Sentences | 389 >>> e3 = lp.parse('\P.exists x.P(x)(\y.see(y, x))') >>> print e3 (\P.exists x.P(x))(\y.see(y,x)) >>> print e3.simplify() exists z1.see(z1,x) As you work through examples like these in the following sections, you may find that the logical expressions which are returned have different variable names; for example, you might see z14 in place of z1 in the preceding formula This change in labeling is innocuous—in fact, it is just an illustration of alphabetic variants After this excursus, let’s return to the task of building logical forms for English sentences Quantified NPs At the start of this section, we briefly described how to build a semantic representation for Cyril barks You would be forgiven for thinking this was all too easy—surely there is a bit more to building compositional semantics What about quantifiers, for instance? Right, this is a crucial issue For example, we want (42a) to be given the logical form in (42b) How can this be accomplished? (42) a A dog barks b exists x.(dog(x) & bark(x)) Let’s make the assumption that our only operation for building complex semantic representations is function application Then our problem is this: how we give a semantic representation to the quantified NPs a dog so that it can be combined with bark to give the result in (42b)? As a first step, let’s make the subject’s SEM value act as the function expression rather than the argument (This is sometimes called typeraising.) Now we are looking for a way of instantiating ?np so that [SEM= > The Merchant of Venice >>> print raw[1850:2075] ACT I SCENE I Venice A street. Enter ANTONIO, SALARINO, and SALANIO ANTONIO In sooth, I know not why I am so sad: We have just accessed the XML data as a string As we can see, the string at the start of Act contains XML tags for title, scene, stage directions, and so forth The next step is to process the file contents as structured XML data, using Element Tree We are processing a file (a multiline string) and building a tree, so it’s not surprising that the method name is parse The variable merchant contains an XML element PLAY This element has internal structure; we can use an index to get its first child, a TITLE element We can also see the text content of this element, the title of the play To get a list of all the child elements, we use the getchildren() method >>> from nltk.etree.ElementTree import ElementTree >>> merchant = ElementTree().parse(merchant_file) >>> merchant 11.4 Working with XML | 427 >>> merchant[0] >>> merchant[0].text 'The Merchant of Venice' >>> merchant.getchildren() [, , , , , , , , ] The play consists of a title, the personae, a scene description, a subtitle, and five acts Each act has a title and some scenes, and each scene consists of speeches which are made up of lines, a structure with four levels of nesting Let’s dig down into Act IV: >>> merchant[-2][0].text 'ACT IV' >>> merchant[-2][1] >>> merchant[-2][1][0].text 'SCENE I Venice A court of justice.' >>> merchant[-2][1][54] >>> merchant[-2][1][54][0] >>> merchant[-2][1][54][0].text 'PORTIA' >>> merchant[-2][1][54][1] >>> merchant[-2][1][54][1].text "The quality of mercy is not strain'd," Your Turn: Repeat some of the methods just shown, for one of the other Shakespeare plays included in the corpus, such as Romeo and Juliet or Macbeth For a list, see nltk.corpus.shakespeare.fileids() Although we can access the entire tree this way, it is more convenient to search for subelements with particular names Recall that the elements at the top level have several types We can iterate over just the types we are interested in (such as the acts), using merchant.findall('ACT') Here’s an example of doing such tag-specific searches at every level of nesting: >>> Act Act Act Act Act for i, act in enumerate(merchant.findall('ACT')): for j, scene in enumerate(act.findall('SCENE')): for k, speech in enumerate(scene.findall('SPEECH')): for line in speech.findall('LINE'): if 'music' in str(line.text): print "Act %d Scene %d Speech %d: %s" % (i+1, j+1, k+1, line.text) Scene Speech 9: Let music sound while he doth make his choice; Scene Speech 9: Fading in music: that the comparison Scene Speech 9: And what is music then? Then music is Scene Speech 23: And bring your music forth into the air Scene Speech 23: Here will we sit and let the sounds of music 428 | Chapter 11: Managing Linguistic Data Act Act Act Act Act Act Act Act Act 5 5 5 5 Scene Scene Scene Scene Scene Scene Scene Scene Scene 1 1 1 1 Speech Speech Speech Speech Speech Speech Speech Speech Speech 23: 24: 25: 25: 25: 25: 25: 29: 32: And draw her home with music I am never merry when I hear sweet music Or any air of music touch their ears, By the sweet power of music: therefore the poet But music for the time doth change his nature The man that hath no music in himself, Let no such man be trusted Mark the music It is your music, madam, of the house No better a musician than the wren Instead of navigating each step of the way down the hierarchy, we can search for particular embedded elements For example, let’s examine the sequence of speakers We can use a frequency distribution to see who has the most to say: >>> speaker_seq = [s.text for s in merchant.findall('ACT/SCENE/SPEECH/SPEAKER')] >>> speaker_freq = nltk.FreqDist(speaker_seq) >>> top5 = speaker_freq.keys()[:5] >>> top5 ['PORTIA', 'SHYLOCK', 'BASSANIO', 'GRATIANO', 'ANTONIO'] We can also look for patterns in who follows whom in the dialogues Since there are 23 speakers, we need to reduce the “vocabulary” to a manageable size first, using the method described in Section 5.3 >>> >>> >>> >>> >>> mapping = nltk.defaultdict(lambda: 'OTH') for s in top5: mapping[s] = s[:4] speaker_seq2 = [mapping[s] for s in speaker_seq] cfd = nltk.ConditionalFreqDist(nltk.ibigrams(speaker_seq2)) cfd.tabulate() ANTO BASS GRAT OTH PORT SHYL ANTO 11 11 12 BASS 10 11 10 26 16 GRAT 19 OTH 16 18 153 52 25 PORT 23 13 53 21 SHYL 15 15 26 21 Ignoring the entry of 153 for exchanges between people other than the top five, the largest values suggest that Othello and Portia have the most significant interactions Using ElementTree for Accessing Toolbox Data In Section 2.4, we saw a simple interface for accessing Toolbox data, a popular and well-established format used by linguists for managing data In this section, we discuss a variety of techniques for manipulating Toolbox data in ways that are not supported by the Toolbox software The methods we discuss could be applied to other recordstructured data, regardless of the actual file format We can use the toolbox.xml() method to access a Toolbox file and load it into an ElementTree object This file contains a lexicon for the Rotokas language of Papua New Guinea 11.4 Working with XML | 429 >>> from nltk.corpus import toolbox >>> lexicon = toolbox.xml('rotokas.dic') There are two ways to access the contents of the lexicon object: by indexes and by paths Indexes use the familiar syntax; thus lexicon[3] returns entry number (which is actually the fourth entry counting from zero) and lexicon[3][0] returns its first field: >>> lexicon[3][0] >>> lexicon[3][0].tag 'lx' >>> lexicon[3][0].text 'kaa' The second way to access the contents of the lexicon object uses paths The lexicon is a series of record objects, each containing a series of field objects, such as lx and ps We can conveniently address all of the lexemes using the path record/lx Here we use the findall() function to search for any matches to the path record/lx, and we access the text content of the element, normalizing it to lowercase: >>> [lexeme.text.lower() for lexeme in lexicon.findall('record/lx')] ['kaa', 'kaa', 'kaa', 'kaakaaro', 'kaakaaviko', 'kaakaavo', 'kaakaoko', 'kaakasi', 'kaakau', 'kaakauko', 'kaakito', 'kaakuupato', , 'kuvuto'] Let’s view the Toolbox data in XML format The write() method of ElementTree expects a file object We usually create one of these using Python’s built-in open() function In order to see the output displayed on the screen, we can use a special predefined file object called stdout (standard output), defined in Python’s sys module >>> import sys >>> from nltk.etree.ElementTree import ElementTree >>> tree = ElementTree(lexicon[3]) >>> tree.write(sys.stdout) kaa N MASC isi cooking banana banana bilong kukim itoo FLORA 12/Aug/2005 Taeavi iria kaa isi kovopaueva kaparapasia. Taeavi i bin planim gaden banana bilong kukim tasol long paia. Taeavi planted banana in order to cook it. Formatting Entries We can use the same idea we saw in the previous section to generate HTML tables instead of plain text This would be useful for publishing a Toolbox lexicon on the Web It produces HTML elements , (table row), and (table data) 430 | Chapter 11: Managing Linguistic Data >>> html = "\n" >>> for entry in lexicon[70:80]: lx = entry.findtext('lx') ps = entry.findtext('ps') ge = entry.findtext('ge') html += " %s%s%s\n" % (lx, ps, ge) >>> html += "" >>> print html kakae???small kakaeCLASSchild kakaeviraADVsmall-like kakapikoa???small kakapikotoNnewborn baby kakapuVplace in sling for purpose of carrying kakapuaNsling for lifting kakaraNarm band KakarapaiaNvillage name kakarauNfrog 11.5 Working with Toolbox Data Given the popularity of Toolbox among linguists, we will discuss some further methods for working with Toolbox data Many of the methods discussed in previous chapters, such as counting, building frequency distributions, and tabulating co-occurrences, can be applied to the content of Toolbox entries For example, we can trivially compute the average number of fields for each entry: >>> from nltk.corpus import toolbox >>> lexicon = toolbox.xml('rotokas.dic') >>> sum(len(entry) for entry in lexicon) / len(lexicon) 13.635955056179775 In this section, we will discuss two tasks that arise in the context of documentary linguistics, neither of which is supported by the Toolbox software Adding a Field to Each Entry It is often convenient to add new fields that are derived automatically from existing ones Such fields often facilitate search and analysis For instance, in Example 11-2 we define a function cv(), which maps a string of consonants and vowels to the corresponding CV sequence, e.g., kakapua would map to CVCVCVV This mapping has four steps First, the string is converted to lowercase, then we replace any non-alphabetic characters [^a-z] with an underscore Next, we replace all vowels with V Finally, anything that is not a V or an underscore must be a consonant, so we replace it with a C Now, we can scan the lexicon and add a new cv field after every lx field Example 11-2 shows what this does to a particular entry; note the last line of output, which shows the new cv field 11.5 Working with Toolbox Data | 431 Example 11-2 Adding a new cv field to a lexical entry from nltk.etree.ElementTree import SubElement def cv(s): s = s.lower() s = re.sub(r'[^a-z]', s = re.sub(r'[aeiou]', s = re.sub(r'[^V_]', return (s) r'_', s) r'V', s) r'C', s) def add_cv_field(entry): for field in entry: if field.tag == 'lx': cv_field = SubElement(entry, 'cv') cv_field.text = cv(field.text) >>> lexicon = toolbox.xml('rotokas.dic') >>> add_cv_field(lexicon[53]) >>> print nltk.to_sfm_string(lexicon[53]) \lx kaeviro \ps V \pt A \ge lift off \ge take off \tkp go antap \sc MOTION \vx \nt used to describe action of plane \dt 03/Jun/2005 \ex Pita kaeviroroe kepa kekesia oa vuripierevo kiuvu \xp Pita i go antap na lukim haus win i bagarapim \xe Peter went to look at the house that the wind destroyed \cv CVVCVCV If a Toolbox file is being continually updated, the program in Example 11-2 will need to be run more than once It would be possible to modify add_cv_field() to modify the contents of an existing entry However, it is a safer practice to use such programs to create enriched files for the purpose of data analysis, without replacing the manually curated source files Validating a Toolbox Lexicon Many lexicons in Toolbox format not conform to any particular schema Some entries may include extra fields, or may order existing fields in a new way Manually inspecting thousands of lexical entries is not practicable However, we can easily identify frequent versus exceptional field sequences, with the help of a FreqDist: >>> fd = nltk.FreqDist(':'.join(field.tag for field in entry) for entry in lexicon) >>> fd.items() [('lx:ps:pt:ge:tkp:dt:ex:xp:xe', 41), ('lx:rt:ps:pt:ge:tkp:dt:ex:xp:xe', 37), 432 | Chapter 11: Managing Linguistic Data ('lx:rt:ps:pt:ge:tkp:dt:ex:xp:xe:ex:xp:xe', 27), ('lx:ps:pt:ge:tkp:nt:dt:ex:xp:xe', 20), , ('lx:alt:rt:ps:pt:ge:eng:eng:eng:tkp:tkp:dt:ex:xp:xe:ex:xp:xe:ex:xp:xe', 1)] After inspecting the high-frequency field sequences, we could devise a context-free grammar for lexical entries The grammar in Example 11-3 uses the CFG format we saw in Chapter Such a grammar models the implicit nested structure of Toolbox entries, building a tree structure, where the leaves of the tree are individual field names We iterate over the entries and report their conformance with the grammar, as shown in Example 11-3 Those that are accepted by the grammar are prefixed with a '+' , and those that are rejected are prefixed with a '-' During the process of developing such a grammar, it helps to filter out some of the tags Example 11-3 Validating Toolbox entries using a context-free grammar grammar = nltk.parse_cfg(''' S -> Head PS Glosses Comment Date Sem_Field Examples Head -> Lexeme Root Lexeme -> "lx" Root -> "rt" | PS -> "ps" Glosses -> Gloss Glosses | Gloss -> "ge" | "tkp" | "eng" Date -> "dt" Sem_Field -> "sf" Examples -> Example Ex_Pidgin Ex_English Examples | Example -> "ex" Ex_Pidgin -> "xp" Ex_English -> "xe" Comment -> "cmt" | "nt" | ''') def validate_lexicon(grammar, lexicon, ignored_tags): rd_parser = nltk.RecursiveDescentParser(grammar) for entry in lexicon: marker_list = [field.tag for field in entry if field.tag not in ignored_tags] if rd_parser.nbest_parse(marker_list): print "+", ':'.join(marker_list) else: print "-", ':'.join(marker_list) >>> lexicon = toolbox.xml('rotokas.dic')[10:20] >>> ignored_tags = ['arg', 'dcsv', 'pt', 'vx'] >>> validate_lexicon(grammar, lexicon, ignored_tags) - lx:ps:ge:tkp:sf:nt:dt:ex:xp:xe:ex:xp:xe:ex:xp:xe - lx:rt:ps:ge:tkp:nt:dt:ex:xp:xe:ex:xp:xe - lx:ps:ge:tkp:nt:dt:ex:xp:xe:ex:xp:xe - lx:ps:ge:tkp:nt:sf:dt - lx:ps:ge:tkp:dt:cmt:ex:xp:xe:ex:xp:xe - lx:ps:ge:ge:ge:tkp:cmt:dt:ex:xp:xe - lx:rt:ps:ge:ge:tkp:dt - lx:rt:ps:ge:eng:eng:eng:ge:tkp:tkp:dt:cmt:ex:xp:xe:ex:xp:xe:ex:xp:xe:ex:xp:xe:ex:xp:xe - lx:rt:ps:ge:tkp:dt:ex:xp:xe - lx:ps:ge:ge:tkp:dt:ex:xp:xe:ex:xp:xe 11.5 Working with Toolbox Data | 433 Another approach would be to use a chunk parser (Chapter 7), since these are much more effective at identifying partial structures and can report the partial structures that have been identified In Example 11-4 we set up a chunk grammar for the entries of a lexicon, then parse each entry A sample of the output from this program is shown in Figure 11-7 Figure 11-7 XML representation of a lexical entry, resulting from chunk parsing a Toolbox record Example 11-4 Chunking a Toolbox lexicon: A chunk grammar describing the structure of entries for a lexicon for Iu Mien, a language of China from nltk_contrib import toolbox grammar = r""" lexfunc: {(*)*} example: {*} sense: {***} record: {+} """ >>> >>> >>> >>> >>> >>> >>> >>> >>> from nltk.etree.ElementTree import ElementTree db = toolbox.ToolboxData() db.open(nltk.data.find('corpora/toolbox/iu_mien_samp.db')) lexicon = db.parse(grammar, encoding='utf8') toolbox.data.indent(lexicon) tree = ElementTree(lexicon) output = open("iu_mien_samp.xml", "w") tree.write(output, encoding='utf8') output.close() 434 | Chapter 11: Managing Linguistic Data 11.6 Describing Language Resources Using OLAC Metadata Members of the NLP community have a common need for discovering language resources with high precision and recall The solution which has been developed by the Digital Libraries community involves metadata aggregation What Is Metadata? The simplest definition of metadata is “structured data about data.” Metadata is descriptive information about an object or resource, whether it be physical or electronic Although the term “metadata” itself is relatively new, the underlying concepts behind metadata have been in use for as long as collections of information have been organized Library catalogs represent a well-established type of metadata; they have served as collection management and resource discovery tools for decades Metadata can be generated either “by hand” or automatically using software The Dublin Core Metadata Initiative began in 1995 to develop conventions for finding, sharing, and managing information The Dublin Core metadata elements represent a broad, interdisciplinary consensus about the core set of elements that are likely to be widely useful to support resource discovery The Dublin Core consists of 15 metadata elements, where each element is optional and repeatable: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, and Rights This metadata set can be used to describe resources that exist in digital or traditional formats The Open Archives Initiative (OAI) provides a common framework across digital repositories of scholarly materials, regardless of their type, including documents, data, software, recordings, physical artifacts, digital surrogates, and so forth Each repository consists of a network-accessible server offering public access to archived items Each item has a unique identifier, and is associated with a Dublin Core metadata record (and possibly additional records in other formats) The OAI defines a protocol for metadata search services to “harvest” the contents of repositories OLAC: Open Language Archives Community The Open Language Archives Community, or OLAC, is an international partnership of institutions and individuals who are creating a worldwide virtual library of language resources by: (i) developing consensus on best current practices for the digital archiving of language resources, and (ii) developing a network of interoperating repositories and services for housing and accessing such resources OLAC’s home on the Web is at http: //www.language-archives.org/ OLAC Metadata is a standard for describing language resources Uniform description across repositories is ensured by limiting the values of certain metadata elements to the use of terms from controlled vocabularies OLAC metadata can be used to describe data and tools, in both physical and digital formats OLAC metadata extends the 11.6 Describing Language Resources Using OLAC Metadata | 435 Dublin Core Metadata Set, a widely accepted standard for describing resources of all types To this core set, OLAC adds descriptors to cover fundamental properties of language resources, such as subject language and linguistic type Here’s an example of a complete OLAC record: A grammar of Kayardild With comparative notes on Tangkic. Evans, Nicholas D. Kayardild grammar Kayardild English Kayardild Grammar (ISBN 3110127954) Berlin - Mouton de Gruyter Nicholas Evans hardcover, 837 pages related to ISBN 0646119966 Australia Text Participating language archives publish their catalogs in an XML format, and these records are regularly “harvested” by OLAC services using the OAI protocol In addition to this software infrastructure, OLAC has documented a series of best practices for describing language resources, through a process that involved extended consultation with the language resources community (e.g., see http://www.language-archives.org/ REC/bpr.html) OLAC repositories can be searched using a query engine on the OLAC website Searching for “German lexicon” finds the following resources, among others: • CALLHOME German Lexicon, at http://www.language-archives.org/item/oai: www.ldc.upenn.edu:LDC97L18 • MULTILEX multilingual lexicon, at http://www.language-archives.org/item/oai:el ra.icp.inpg.fr:M0001 • Slelex Siemens Phonetic lexicon, at http://www.language-archives.org/item/oai:elra icp.inpg.fr:S0048 Searching for “Korean” finds a newswire corpus, and a treebank, a lexicon, a childlanguage corpus, and interlinear glossed texts It also finds software, including a syntactic analyzer and a morphological analyzer Observe that the previous URLs include a substring of the form: oai:www.ldc.upenn.edu:LDC97L18 This is an OAI identifier, using a URI scheme regis- tered with ICANN (the Internet Corporation for Assigned Names and Numbers) These 436 | Chapter 11: Managing Linguistic Data identifiers have the format oai:archive:local_id, where oai is the name of the URI scheme, archive is an archive identifier, such as www.ldc.upenn.edu, and local_id is the resource identifier assigned by the archive, e.g., LDC97L18 Given an OAI identifier for an OLAC resource, it is possible to retrieve the complete XML record for the resource using a URL of the following form: http://www.languagearchives.org/static-records/oai:archive:local_id 11.7 Summary • Fundamental data types, present in most corpora, are annotated texts and lexicons Texts have a temporal structure, whereas lexicons have a record structure • The life cycle of a corpus includes data collection, annotation, quality control, and publication The life cycle continues after publication as the corpus is modified and enriched during the course of research • Corpus development involves a balance between capturing a representative sample of language usage, and capturing enough material from any one source or genre to be useful; multiplying out the dimensions of variability is usually not feasible because of resource limitations • XML provides a useful format for the storage and interchange of linguistic data, but provides no shortcuts for solving pervasive data modeling problems • Toolbox format is widely used in language documentation projects; we can write programs to support the curation of Toolbox files, and to convert them to XML • The Open Language Archives Community (OLAC) provides an infrastructure for documenting and discovering language resources 11.8 Further Reading Extra materials for this chapter are posted at http://www.nltk.org/, including links to freely available resources on the Web The primary sources of linguistic corpora are the Linguistic Data Consortium and the European Language Resources Agency, both with extensive online catalogs More details concerning the major corpora mentioned in the chapter are available: American National Corpus (Reppen, Ide & Suderman, 2005), British National Corpus (BNC, 1999), Thesaurus Linguae Graecae (TLG, 1999), Child Language Data Exchange System (CHILDES) (MacWhinney, 1995), and TIMIT (Garofolo et al., 1986) Two special interest groups of the Association for Computational Linguistics that organize regular workshops with published proceedings are SIGWAC, which promotes the use of the Web as a corpus and has sponsored the CLEANEVAL task for removing HTML markup, and SIGANN, which is encouraging efforts toward interoperability of 11.8 Further Reading | 437 ... British National Corpus (BNC, 199 9), Thesaurus Linguae Graecae (TLG, 199 9), Child Language Data Exchange System (CHILDES) (MacWhinney, 199 5), and TIMIT (Garofolo et al., 198 6) Two special interest... 14 496 ), (''your'', 14 496 , 15 791 ), (''dark'', 15 791 , 20720), (''suit'', 20720, 25647), (''in'', 25647, 2 690 6), (''greasy'', 2 690 6, 32668), (''wash'', 32668, 37 890 ), (''water'', 38531, 42417), (''all'', 43 091 ,... contemporary material on the formal semantics of natural language, including Montague Grammar and intensional logic, see (Gamut, 199 1a, 199 1b) (Kamp & Reyle, 199 3) provides the 10.7 Further Reading |