Agenda

• finalize the proper name xml structure
• prepare integration of the kvensk project, if SD accepts

Participants: Børre, Linda, Sjur, Tomi, Trond

Questions:

• What (the content): ** make an overview of all info we want to store ** … and how to organise it
• How (the xml structure): ** one or two files? (two actually implies three) ** what info to split into common parts and project / language specific parts

Views:

• Iconic id better than arbitrary id.
• Single linking, or automatically made double linking
• pro links in common: lg-specific files are not cluttered
• pro links in lg files: that is where the info is

Work process:

• Timbuktu: Add iconic id and semantics once, to common. ** The machine MAKES the lg entries, based upon these assumpt: *** one form, inherited from iconic id _ one sem, inherited from common _ and we will decide a default declension class for each lg *** we may leave a tag in place saying “untouched by human hands”
• Helsinki: - same case, but here we need heavy manual editing
  ** make a tag saying “now touched (by native speaker)”

Conclusions:

Double linking, iconic id Iconic id decided by the following principle:

• Place names: pick Norwegian, Swedish, Finnish, English names.
• Other names: pick the most common (the one which give most “identical” hits among our lgs: sme, smj, sma, nor/nob/nno, swe, fin, eng (sms, smn) )

With the princ of inheritance (lemma inherited from common file):

• inherit right away / at creation time (= larger files, more duplicate info)

common        |     swe          |    fin           |
India_2       |     India        |    Intia         |
->lg=a        |     ->India_2    |    ->India_2     |
(->lg=b Intia)|     ->India      |                  |
sem plc
...


Timbuktu      |     Timbuktu     |    Timbuktu      |
->lg=a id     |     ->Timbuktu   |    ->Timbuktu    |
->lg=b id     |                  |                  |
sem plc       |     <ab>Tmb.</ab>|
...


|   sme:            | ... | nor:   | fin | swe | eng
Tana          |   Deatnu         | ... | Tana   |     |     |
->lg=a id     |   ->Tana         | ... |->Tana  |     |     |
->lg=b id     |                  | ... |        |     |     |
sem plc       |                    ... |              |     |
...                                ... |              |     |

What do we store in the “common” file the iconic id the semantics + info about the world (encyclopedic info) links to the lg specific files

What is stored in the lang-specific ones? Linguistic info:

• inflection
• stem
• lemma
• derivation class?
• compounding?
• senses (pointers to concepts)
• orthographical variants (incl. (common) misspellings)
• acronym(s) and abbreviation(s): ** as separate entries or as part of the name entry?

NATO => OTAN
NRL => NBR, Ap => Bb


KRD
KRD     KRD
KRD     KRD+N+ACR+Sg+Acc
KRD     KRD+N+ACR+Sg+Gen
KRD     KRD+N+ACR+Sg+Nom


NATO
NATO    NATO+N+ACR+Sg+Acc
NATO    NATO+N+ACR+Sg+Gen
NATO    NATO+N+ACR+Sg+Nom
NATO    NATO+N+Prop+Org+Sg+Acc
NATO    NATO+N+Prop+Org+Sg+Attr
NATO    NATO+N+Prop+Org+Sg+Gen
NATO    NATO+N+Prop+Org+Sg+Nom


"<NATO>" S:1732, 1732, 1732, 1732, 5423, 5849, 5849, 9980
        "NATO" N Prop Org Sg Nom <<< S:1285 @HNOUN

Different aspects of abbreviations and acronyms:

• expansion (requires linking/common entry): ** abbr needs to be expanded for IR and text-to-speech ** translation systems want to transl. them to other lg abbrs (possibly requiring (intermediate) expansion)
• linguistic analysis/properties: ** the preprocessor is concerned about abbr’s behaviour wrt. sentence delimitation (TRAB, ITRAB) ** speller programs want to correct them whenever wrongly spelled (possibly storing misspellings of abbrs) ** disambiguators want their underlying POS analysis (in addition to their ABBR tag) ** they have inflections of their own _ St.dieđ. 10 / St. dieđáhus OR St. dieđáhusa… (implicit case) _ NRK:as (explicit case, except for Acc/Gen, who may be left unexpressed) ** can take part in compunding, possibly derivation

Lexicon conclusion:

• store abbr. that are coming from names as separate entries? (we probably have no dotted abbrs for names)
• store accr. as separate entries in the name database, with type=”acr”
• store alternative names as separate entries
• all linked together or to the same concept (open??? If to the concept, forces us to allow more than one entry/language in the common file)

Transducer conclusions:

• Leave things at status quo for the abbreviations and the acr generator
• We will return to the issue of double abbrs if they turn up (They probably don’t)
• Double acrs arelaready taken care of in the sme-dis.rle urle set (lexical acronyms are preferred over generated ones)

xml example format:

Concept center (common file):

<entry id="India" type="full (default)/abr/acr/alt/err">
 <sem>
  <plc type="xxx" ssrcode="" > <!-- type=5., ssrcode=6. -->
   <geo>
     <country>IN</country>
     <region/> <!-- "fylke" or similar, 11. -->
     <munic/> <!-- 10. -->
     <coord /> <!-- 14. -->
   </geo>
   <regul>
     <gnr/> <!-- 7. -->
     <bnr/> <!-- 7. -->
   </regul>
  </plc>
 </sem>
 <!-- These links are convenience entries, to speed up processing -->
 <langentry lang="sme" ref="India"/>
 <langentry lang="smj" ref="India"/>
 ...
 <langentry lang="fin" ref="Intia"/>
</entry>


<entry id="India_2">
 <sem>
  <fem/>
 </sem>
 <langentry lang="sme" ref="India"/>
 <langentry lang="smj" ref="India"/>
...
 <langentry lang="fin" ref="India"/>
</entry>

Language file for, say, sme:

<entry id="India">
 <!-- Do we need the stem, or can it be inferred/inherited from the id?
      NO, only if different from the id. -->
 <stem/>
 <infl lexc="ACCRA">(example?)</infl>
 <name-parts>
 <etym/>
 <rel-name ref="xyz"/>
 <senses>
  <sense ref="India_2"/>
  <sense ref="India"/>
 </senses>
</entry>

Language file for fin:

(numbers refer to Irene’s draft, see below)

<entry id="Intia"> <!-- 1. -->
 <stem lexc="14">(only if different from id/headword)</stem> <!-- 2. and 3. -->
 <name-parts> <!-- 4. -->
 <variants> <!-- 15. -->
  <variant ref="xyz">
 </variants>
 <etym/> <!-- 24. -->
 <rel-name ref="xyz"/> <!-- 18. -->
 <senses>
  <sense ref="India"/>
 </senses>
</entry>


<entry id="India">
 <stem/>
 <infl lexc="14">(example?)</infl>
 <name-parts>
 <etym/>
 <rel-name ref="xyz"/>
 <senses>
  <sense ref="India_2"/>
 </senses>
</entry>

Language file for kvensk:

(numbers refer to Irene’s draft, see the [meeting memo from Nov. 28 | https://giellalt.uit.no/admin/weekly/2005/Meeting_2005-11-28.html#7.+Name+lexicon+infrastructure])

<entry id="Porsanki"> <!-- 1. -->
 <stem lexc="14">(only if different from id/headword)</stem> <!-- 2. and 3. -->
 <name-parts> <!-- 4. -->
 <variants> <!-- 15. -->
  <variant ref="xyz">
 </variants>
 <etym/> <!-- 24. -->
 <rel-name ref="xyz"/> <!-- 18. -->
 <senses>
  <sense ref="Porsanger">
   <legal>
    <status/> <!-- 8. -->
    <decision/> <!-- 9. -->
   </legal>
   <source>
    <informants>
     <informant id="some-id"> <!-- 20. -->
      <explanation date="" /> <!-- 19. -->
      <explanation date="" />
     </informant>
    </informants>
    <collectors>
     <collector id="" year=""/> <!-- 21. -->
     <collector id="" year=""/>
    </collectors>
    <archive/>
    <other>
     <print/>
    </other>
   </source>
   <comment/> <!-- 28. -->
  </sense>
 </senses>
</entry>
In the case that  stem = lemma, we have the entry:
 <stem lexc="14"/>

These points from Irene’s list are still open:

Print info - do they belong to the common or language-specific sections?:
12. kartprodukt
13. kartblad


Unclassified:
25. pilhenvisning, nuoliviite, til annen artikkel
    -> How is this different from 18.?


Multimedia - do they belong to the common or language-specific sections?:
26. lydfil
27. bilde(r), illustrasjone(r)