Next generation <etym> in the TEI – Putting together a proposal

After the discussion on the TEI list and the comments on the list, the post and twitter exchanges with @ttasovac, I came back to an old paper of Susanne Alt (http://hal.archives-ouvertes.fr/hal-00110971), which provides an overview of the constraints that could apply to a comprehensive representation of etymological information in a dictionary entry.

Susanne uses the entry “Pamplemousse” from the TLF (Trésor de la Langue Française) to encode the following etymological information:

PAMPLEMOUSSE, subst. masc. […]

Empr. au néerl. pompelmoes, fém., au sens 1 a, qui est prob. comp.de pompel «gros, enlé» et de limoes «citron» (BOULAN, p.148; KÖNIG, pp.159-160). Apparaît d’abord dans des textes fr. qui le donnent comme mot néerl.: 1665 pompelmoes (J. LE CARPENTIER, L’Ambassade de la Compagnie orientale des Provinces Unies… [trad. d’un ouvrage néerl.], II, p.88 ds ARV.); 1666 pompelmous (M. THÉVENOT, Relation de divers voyages curieux… t.3 ds KÖNIG).

At the end of paper, following an in-depth discussion of etymons and links, which I advise you all to read, she suggests the following encoding:

(i.e. the lexical entry pamplemousse and its direct etymon pompelmoes) of the data structure in a TeI like format. Note that the basic building blocks for the characterization of a lexical entry (<form> and <sense>) are completely reus- able for the description of an etymon, and the language has been implemented as a standardized xml:lang attribute.

<lexicalEntry id=”LE1″>
<form>
<orth>pamplemousse</orth> …
</form>
<sense>… </sense>
<etymology> <etymon id=”LE2″>
<form> <orth xml:lang=”dutch”>pompelmoes</orth> <pos>commonNoun</pos> <gender>feminine</gender>
</form> <sense>
<glose>Citrus maxima</glose>
<note>probablement d’origine tamoule, De Vries, Nederl</note> </sense>
</etymon> <etymologicalLink source=”LE2″ target=”LE1″>
<etymologicalClass>loan word</etymologicalClass> </etymologicalLink>
</etymology> </lexicalEntry>

If we “modernize” this proposal to make it as close to a TEI compliant entry, we could think of something as follows:
<entry xml:id=”LE1″>
<form>
<orth>pamplemousse … </form>
<sense>…
<etym>
<re type=”etymon” xml:id=”LE2″>
<form>
<orth xml:lang=”dutch”>pompelmoes</orth>
<gramGrp>
<pos>commonNoun</pos>
<gen>feminine</gen>
</gramGrp>
</form>
<sense>
<gloss>Citrus maxima</gloss>
<note>probablement d’origine tamoule, De Vries, Nederl</note>
</sense>
</re>
<link type=”loanWord” target=”#LE2 #LE1″/>
</etym>
</entry>

This is a little more ambitious than what was discussed in the previous post and related comments, but seems to follow what Toma Tasovac had in mind with an embedded entry in the description of the etymological content.

From print to code – multiple forms in one

An interesting discussion started on the TEI list (http://listserv.brown.edu/archives/cgi-bin/wa?A1=ind1309&L=TEI-L#14) about dictionary encoding, which I would like to reflect here to point to a couple of issues related to forms in dictionaries.

The post was sent by Susanna Allés, who is currently working on a Latin medieval dictionary. Here’s the initial question:

“we can’t find a satisfactory solution to encode a term (<term>) that corresponds to several languages. Here is the text:

arrencare  [cat. arrencar, arrancar (cf. oc., esp., port. arrancar), d’origen discutit | de origen discutido | of debated origin]  rompre roturar to break up: 1038 ACUrgell, Cart. I 357, f. 118, col. 2: terra quae fuit arrenchada qui est in Subuineas quae escamiauit Ermengauda a me Mirone. De una parte affrontat … in terra quae arrencauit … de IIII uero parte in ipsa fonnada de terra de Riamball que arrencauit.

The part in (square) brackets corresponds to the etymology (encoded with <etym>) and in red (cf. oc., esp., port. arrancar) corresponds to a term (the Romanic result); we want to relate this term with several languages (that it is, to Occitan, Spanish, Portuguese, in this case). Usually, if we are dealing with just a language, we encode it as <term xml:lang=”es”>arrancar</term> , but since we need to add other languages and the element term just allow one @xml:lang, we really don’t know how to handle.”

For sake of place, the original editor of the dictionary has used the same character sequence to represent three “words” from three different languages, which just happen, by chance (and linguistic proximity…), to be written in the same way.

The first line of thought, which considers the source text at face value may lead (like stated in the question) to  one could want to refer to three languages in relation to the sequence “arrancar”. Possibilities that have been alluded to on the list are:

  • putting more that one language codes as values for xml:lang, theoretically feasible, given the recent evolution of the corresponding W3C specification, not in the TEI though and probably an “interoperability nightmare” (quoting Stuart Yeates)
  • tagging the language references with <lang>, as suggested by Sabine Thuillier, in keeping to the basic constructs associated to <etym> (etymology) in the TEI guidelines (i.e. ​cf. ​<lang>oc., esp., port.</lang> <mentionned>arrancar</mentionned>​)​; Sabine rightly points to the fact that this solution is not optimal from a processing point of view.

Still, a more lexicographic analysis seems to lead to another path which consists in reconstructing the underlying logical representation, as nicely stated by Toma Tasovac:

“what we have here is typical lexicographic shorthand —  we know how lexicographers used to be stingy when it comes to space —  but that, if we really think about it, we are not (on the conceptual, modeling, even philosophical level) talking about one word being “the same” in three languages, but rather about three “different” words from three different languages that happen to have the same graphical representation.

What one could therefore also do is encode three instances of “arrancar” and each with an xml:lang for a different language.”

It is interesting to observe that several contributors, even being in line with this analysis, have actually suggested mechanisms to retain the “sameness” in the encoding (using @sameas, @exclude or <alt>; Syd Baumann actually provided quite a comprehensive set of possibilities)). No, Toma (supported by David Birnbaum) put it right:

“if one wanted to preserve the economic display in the end output, one would have to use XSLT or whatever one uses to check whether subsequent terms have the same graphical form and then display only one term, but display language ids from all of them.”

Which means that we need to produce an encoding where nothing may lead a processor to think that we have the “same” form, but it just happened that the three were printed out as one accidentally.

Finally, let me add that there is an issue with the encoding of “arrancar” as <term>. It is obviously a <form> (even better a <form>/<orth> if we anticipate that we could provide additional pronunciation information.

So my take at the encoding of this example would be as follows:

(cf. <lang>oc.</lang>, <lang>esp.</lang>, <lang>port.</lang> <form xml:lang=”oc”><orth>arrancar</orth></form><form xml:lang=”sp” ><orth>arrancar</orth></form><form xml:lang=”pt”><orth>arrancar</orth></form>)

But there is a hack here… <form> is not allowed there. Shall we change the content model of <etym>?