#482 The term strikes back - terminology chapter

[Laurent Romary]

During the ISO TC 37 meetings in Pretoria in June, we discussed the future of ISO 30042 TBX and the possibility to fully define it as an ODD. I made a first start in the form of a smaller subset that could be the basis of a new terminology chapter for the guidelines. I attach my work so far, asking the council for their views on how to proceed further on this (putting it on source forge, setting a WG, appointing a contact person, etc.).

[Syd Bauman]

I think expressing TBX in ODD is a good idea, and that TEI-C should support the effort. I don't know much about TBX (nor terminological databases), but would guess that a joint ISO/TEI WG is a goo way forward.

I've made some tweaks to the ODD.

And now I'll try again to upload the modified version ...

[Laurent Romary]

Thanks Syd. Maybe a call to get an overview of the work to be done and how to structure it would be ideal. Could the council express an in principle view as to the opportunity of the work, before we possibly bring in additional TBX expert.

[Laurent Romary]

And since I leave traces of my deeds: http://tags.hypotheses.org/10

[Laurent Romary]

Thanks Syd. Chow do we want to proceed on this. Are you the “official” contact point. Shall we finalize a first version that we send around to the TBX community for information/validation?

Le 10 nov. 2013 à 22:27, Syd Bauman sbauman@users.sf.net a écrit :

I think expressing TBX in ODD is a good idea, and that TEI-C should support the effort. I don't know much about TBX (nor terminological databases), but would guess that a joing ISO/TEI WG is a goo way forward.

I've made some tweaks to the ODD.

[feature-requests:#482] The term strikes back - terminology chapter

Status: open
Created: Wed Nov 06, 2013 09:07 AM UTC by Laurent Romary
Last Updated: Wed Nov 06, 2013 09:07 AM UTC
Owner: nobody

During the ISO TC 37 meetings in Pretoria in June, we discussed the future of ISO 30042 TBX and the possibility to fully define it as an ODD. I made a first start in the form of a smaller subset that could be the basis of a new terminology chapter for the guidelines. I attach my work so far, asking the council for their views on how to proceed further on this (putting it on source forge, setting a WG, appointing a contact person, etc.).

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/tei/feature-requests/482/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

Laurent Romary
INRIA & HUB-IDSL
laurent.romary@inria.fr

[James Cummings]

At Oxford 2013-11 LB, KH and SB to articulate a more generic policy for TEI on the integration of external standards and will generate a one-page proposal for this policy. This should be provided to Council ahead of the next teleconference. In addition, LB, KH, and SB will check with Laurent that he wants TBX incorporated into the Guidelines as is or kept in sync in the future and what he thinks about melding into the rest of the TEI Guidelines (in language, approach, element naming conventions) or keeping it self-contained.

[Kevin Hawkins]

FYI, that generic policy is in process: https://sourceforge.net/p/tei/feature-requests/507/ .

[Laurent Romary]

The objective is clearly to incorporate this step by step into the guidelines so that we have a reference TEI extension (module?) for terminological (onomasiological) data. There is some thinking to be don eon how to optimise the compatibility with other usages of TBX while merging into the TEI mechanisms. I will move ahead with the doc (on SB's update basis). Anyone is planning to follow this closely?

[Lou Burnard]

The ticket has been assigned to me, so I am certainly going to be following it, as closely as other committments permit. The Council meeting was unclear as to whether you were aiming to produce/promote a TEI extension -- effectively your current ODD -- which stands independent of the TEI and would not form part of the Guidelines (except perhaps by reference), or whether you plan eventually to convert this to a component of the Guidelines, either as a new or as part of an existing module. The latter is (obviously) much more work, and might necessitate some major changes in the current TBX world view, but it's certainly worth trying.

[Lou Burnard]

Following discussion with Laurent this morning, it's clear enough that what is planned here is to provide a TEI equivalent for TBX, enabling the useful parts of TBX to be embedded in a natively TEI document. As a first step, LR wants to be sure his ODD is compatible with current TEI practice and can (eventually) be handled in the sf tree along with the rest of the Guidelines. At his request, I've created a new Incubator/TBC directory in the main SF Trunk and put the latest draft there. I expect to review it and add comments later this week.

[Kevin Hawkins]

It sounds like Laurent and Lou are figuring out whether this would really be its own chapter of the Guidelines. (Maybe they discussed this on 2013-12-03, but I can't tell from Lou's notes what the outcome of that was.)

Still, if the proposed text would constitute its own chapter, it's not clear to me why this wouldn't be incorporated into the existing chapter on dictionaries. That is, why create all new elements (e.g., termEntry) instead of using elements already defined in the dictionaries chapter (e.g., entry) with a compatible meaning and then add new elements when an appropriate element doesn't already exist?

[Lou Burnard]

I think deciding whether this work is best presented as a separate chapter or as a new section of an existing one is some way down the track. If you look at the draft you'll see that it's still at a fairly preliminary stage. My discussion with Laurent was chiefly about what needs to be done to the draft to move it along from a stylistic point of view, but also to call attention to parts of it which are not yet clear enough for Council to take a view on.

I'll leave it to Lauren to answer Kevin's specific query above, but my take on it is that an entry in a lexical database is a very different kind of thing from an entry in a print dictionary, with different semantics and an entirely different internal structure, so there is good reason to propose a new element for it.

[Laurent Romary]

The main reason why we need a specific representational model (not just hack the dictionary entry element), is that the model for terminological entry is an onomasiological representation which goes from concept to term as opposed to the semasiological one implemented in word to sense dictionaries. See http://tags.hypotheses.org/10 for a quick overview or http://hal.inria.fr/inria-00100405 for an in-depth presentation of the underlying principles.

[Kevin Hawkins]

Okay. I was thinking of loosening the content model of <entry> to account for concept-to-term entries, but perhaps it is more sensible to create a new element (<termEntry>) that can have a tight content model to be used only for concept-to-term entries, leaving <entry> for just term-to-concept entries.

[Martin Holmes]

Is it possible that the issue of list type="gloss", which will be the only remaining list/@type value after we rework our list recommendations, might be solved by the idea of a <termEntry>?

[Laurent Romary]

I think it would. Can you give me an example I could code?

[Martin Holmes]

This is an example from chapter 3.7:

~~~~~~~~
<list type="gloss">
<head>Unit Three — Vocabulary</head>
<label xml:lang="la">acerbus, -a, -um </label>
<item>bitter, harsh</item>
<label xml:lang="la">ager, agrī, M. </label>
<item>field</item>
<label xml:lang="la">audiō, īre,
īvī, ītus </label>
<item>hear, listen (to)</item>
<label xml:lang="la">bellum, -ī, N. </label>
<item>war</item>
<label xml:lang="la">bonus, -a, -um </label>
<item>good</item>
</list>
~~~~~~~

[Laurent Romary]

This is indeed an interesting borderline case and it all depends how this sample is perceived. If you have a semasiological view on these lexical groups, you may consider the entry point is the latin word and the rest are glosses expressing its sense(s). This leads to a normal usage of [entry]:

        <entry>
          <form xml:lang="la">
            <orth>acerbus</orth>
            <form type="inflected">
              <orth>-a</orth>
            </form>
            <form type="inflected">
              <orth>--um</orth>
            </form>
          </form>
          <sense>
            <gloss xml:lang="en">bitter, harsh</gloss>
          </sense>
        </entry>

If you have an onomasiological view on this, you will consider each block as the description of a concept, for which you identify the possible ways of expressing it in any number of languages (here la and en, but you can add as many as you want ad libitum). This is the realm of TBX and the (simplified) encoding may look like this:

       <termEntry xmlns="http://www.tbx.org">
          <langSet xml:lang="la">
            <tig>
              <term>acerbus</term>
            </tig>
          </langSet>
          <langSet xml:lang="en">
            <tig>
              <term>bitter</term>
            </tig>
            <tig>
              <term>harsh</term>
            </tig>
          </langSet>
        </termEntry>

[Lou Burnard]

Laurent has now published an article explaining his ideas for this revision in more detail : http://hal.inria.fr/hal-00950862

[Laurent Romary]

With the paper you'll find a zip with the current ODD/rnc and a test file. Depanding on feedback, I'll update the paper and the ODD. I should not be presented before June (submitted at TKE in Berlin).

[Martin Holmes]

Laurent, could you update us on any feedback you got from Berlin?

[Laurent Romary]

The paper and the ODD have been updated. We have a stable spec although it would require (sigh) more prose and example. I am now recommending this customization for people wanting to do onomasiological descriptions in TEI documents.
Can council give guidance as to the way forward? Shall we have a little task force of motived colleagues (volunteers?)? First step could be to have this on GitHub as well.

[Lou Burnard]

Please could you check the latest stable spec into the Sourceforge "Incubator" repository (or send it me by email and I will).