This is a further response to Juan Trujillo's posting. (Apologies to
Juan who will get this message twice.)
 
> I'm interested in comments on the appropriateness of a couple of
> potential ways to add grammatical tagging at the word level.
>
> I'm doing historical research in Spanish, and must deal with large
> numbers of orthographic variants. I want to be able to search easily on
> individual grammar variables and control formatting in Panorama based
on
> grammar attribute values.
>
> There is nobody around here that works with this kind of corpus (or any
> other kind), and I am pulling out my hair with a September dissertation
> deadline rapidly approaching.
>
> METHOD ONE:
>
> BNC-type tags in the form of entity refs like: perro&NMS;, which could
> be expanded to "Noun Masculine Singular" or something similar.
>
> (I actually tried a variant of this, putting the codes into a TYPE
> attribute, but stripped them all out two weeks ago.)
>
> PROBLEM: The codes symbolize the entire SET of grammar values, and
> individual grammar variables have to be extracted from the codes to be
> useful. There is no place to store the regularized form of the word
> being tagged without adding a <DISTINCT> or <W> tag of some sort.
>
> This brings us to
>
> METHOD TWO:
>
> Go ahead and use the <W> element, but modify the attribute list, adding
> part of speech, tense, number, gender, etc. and defining possible values
> for each.
>
> Example (stripped down for brevity):
>
> <!ELEMENT w         - -  ((#PCDATA | %n.seg; | %n.w; |
>                              %n.m; | %n.c;)*)                   >
> <!ATTLIST w              %a.global;
>                              %a.seg;
>     lemma              CDATA                         #IMPLIED
>     pos                (n | v | art | adj | adv )    #IMPLIED
>     gender             (masc | fem | neut)           #IMPLIED
>     number             (sing | pl)                   #IMPLIED
>     person             (1 | 2 | 3)                   #IMPLIED
>     case               (nom | gen | ac | dat)       #IMPLIED
>     tense              (inf | pres | imperf | cond | fut)     #IMPLIED
>     mood               (indic | imper | subj)        #IMPLIED
>     TEIform            CDATA               'w'            >
>
>
> Perro would be encoded: <W LEMMA="perro" POS="N" GENDER="MASC"
> NUMBER="PL">perro</W>
>
> PROBLEM: It becomes possible to create illegal combinations of
> attributes.  For example a noun could be given a TENSE attribute.
> However, this seems to be the easiest way to allow for searches on
> individual variables and on standardized orthography. I'm not sure a
> simple warning that the DTD can allow illegal encoding is enough,
> though. Any thoughts? This is what I am leaning toward.
 
Gary Simons and I discuss this kind of solution to grammatical encoding
in our article in CHum (special TEI issue). We point out that it doesn't
provide a general solution to the tagging of grammatical information,
since attributes are not recursive, whereas grammatical structures are.
However, for the information you're interested in encoding, the problem
of recursion doesn't arise. The lack of validation is a general problem
in SGML, short of providing actual tags like <noun>, <gender>, etc. with
individual content models (your Method 3 below), a solution which Gary
and I also reject in our article, on general linguistic grounds, though
for applications involving single languages only, it may not be so
problematic.
 
> METHOD THREE:
>
> Add elements for each part of speech that would be contained by the
> standard TEI <W> element as defined in the guidelines. Define attribute
> lists tailored to those parts of speech--no illegal combinations.
>
> PROBLEM: It is debatable whether a <NOUN> or <ADJECTIVE> tag could
be
> considered structural descriptions as are the current <M> and <C>
> elements.  The designation of pos, gender, number, etc. is structural in
> a linguistic sense, but not necessarily in a textual sense.
>
>
> METHOD FOUR:
>
> Feature structures. I have read the TEI chapter four or five times, and
> it still is a puzzle to me how this could be a solution. The example
> from Ch. 15 of the Guidelines shows that each word ends up with an ID,
> then a linking structure links each one *individually* to the target
> grammar descriptions!? This is a level of abstraction I don't want, it
> interferes with the simple display options I would have if the grammar
> stayed in the attributes, and even with only some 7500 unique forms,
> this does not look like a linkGrp I want to be working on.
 
Ch 15 contains a number of suggestions of varying degrees of complexity,
of which you describe here the last, and most elaborate. The question of
forming links and link-groups should be separated from the question of
using feature-structure tags for encoding grammatical categories.
Libraries of predefined <f> and <fs> tags could be set up and linked in
one direction only to the text. This would, of course require <w>, <m>,
etc. tags in the text, but without ID attributes. The elements in the
library, of course, have to be identified in order to link them to the
text elements. Validation problems of the sort you mention above are
also handled, as long as the predefined feature structures are all valid
grammatical descriptions of something (in the text, or in principle). Of
course, one could point to the incorrect feature structure in the
database, but that's not a mistake that a validation procedure should
pick up.
*************************************************************************
Terry Langendoen
Editor, Linguistics Abstracts, beginning 1/1/97
Chair, Technical Review Committee, Text Encoding Initiative
Head, Department of Linguistics, University of Arizona
Mailing Address: PO Box 210028, Tucson AZ 85721-0028 USA
Phone: +1 520 621-6898    Fax: +1 520 626-9014
Email: [log in to unmask] OR [log in to unmask]
Dept WWW homepage: http://wacky.ccit.arizona.edu/~ling/index.html