[freedict] Re: Poll: replace deu-eng / eng-deu

  • From: Einhard Leichtfuß <alguien@xxxxxxxxxxxxx>
  • To: freedict@xxxxxxxxxxxxx
  • Date: Sun, 30 Aug 2020 00:56:57 +0200

Hi Sebastian,

thanks for the answers!

On 29/08/2020 16:25, Sebastian Humenda wrote:

The latter is also the reason for that I neither published any code yet
nor contacted you again earlier, since I was unsure what I was allowed
to in the context of my bachelor's thesis.

I suppose that has been resolved? Is the licencing clear?

I am allowed to publish under any license I wish; though the university
may also use it under some other license.

I do have some questions.  A lot, in fact.  I hope not to overwhelm you
with them.  Just ignore some of them, if they are to many.
Since this is now my bachelor's thesis, I need to ask you to refrain
from giving me any coding-specific advice (or else I'd have to cite you
in my bachelor's thesis).  Please also do not publish any changes to my
code before I submit my bachelor's thesis (september or october 2020).

Ok, sure :).
Is citing a bad thing? :)?

No.  I guess, a little advice cannot harm, though I suggest it being
given, iff

a) I ask for it,
b) I express that something is hard / impossible to solve and somebody
   disagrees,
c) another good reason (I trust your judgement).

Note that I currently target version 1.8.1 exclusively.

1.8.1. of what?

Of the Ding.

* There is also "devel", which is expected to change.  Due to a notable
  amount of preprocessing (fixing syntax mostly), the current program
  only "works" for that specific version.

A) TEI

A.1) TEI Lex-0.  Have I understood correctly that it is a good idea to
    follow this standard [0]?  E.g.
    * a) <gram type="gender"/> instead of <gen/>.;
    * b) <usg> with @type (and possibly @norm)

I'm not sure about this, Michael, Piotr, do you have comments? If nothing
comes during the next 1-2 weeks, I would say rather stick to the current
version that is in our schemas. It is easy to transform and better if
consistent with other dictionaries.

By "our schemas", you mean the files

  fd-dictionaries : shared/freedict-P5.* ?

I have to admit that these files are hard to grap for me (no prior
experience with XML).  Are these meant to serve as human-readable
documentation?  Is it worth the effort?

Otherwise, I will continue to rely on the Wiki, the (example) TEI files
and the TEI docs (and your answers).


I actually like the TEI Lex-0 standard, in particular:

  i)   b) from above:  a fixed listed of good @type's (see the
       comparison table at [10]).  How would I represent
       @type="textType" (e.g. bibl., poet., admin., journalese) or
       @type="attitude" (e.g. derog., euph.), which do not have an
       equivalent in the TEI suggested @type's?
       ? Should I just use these as suggested in TEI Lex-0, thereby
         creating a mixture between TEI and TEI Lex-0?
  ii)  Requirements to fully annotate with @xml:id and @xml:lang.
       ? Can / should be done nonetheless?
       * @xml:id useful for linking entries.

If I understand corretly, the Freedict TEI-guidelines have a similar
objective as the TEI Lex-0 standard.  I understand that the specs are
probably incompatible, though in the long term it might be beneficial to
adopt the TEI Lex-0 standard.


A.4) Normalization of usage annotations
    * Recommended by TEI Lex-0.
    * different languages (e.g. "[Sprw.]" ~ "[prov.]")
    * same language (e.g. "[coll.]" ~ "[slang]")
    ? Should they be normalised to a single label?
    ? Should they be normalised to some standard labels?
      * ISO 12620 [4,5,6] (full standard only commercially available)
    * The usage of @norm in <usg> might render that less an issue.

Define an ontology, that should be enough. @Karl, would you be able able to
help out here? Or is this the wrong solution?

? I guess this is similar to shared/FreeDict_ontology.xml ?

  * If I understand correctly, this does only allow to link equivalent
    annotations in different languages, however not "coll." and "slang"
    (if these should even be considered equivalent).

? Where do I find information (in the TEI docs?) on how to write (and
  use) such an ontology?

? Btw., should I annotate grammar information using the short english
  forms from the above ontology?
  ? Or even import that file somehow?

A.5) Quantified (or similar) usage annotations
    * Ex.: "mainly Am."
    * Ex.: "bes. Süddt.", "especially Am."
    ? How to represent the determiner?

What is the determiner here? I thought determiner are for componound phrases
such as lemmon tree.

"mainly", "bes.", "especially".  I thought these were determiners.

A.6) Dialect / language annotations.
    a) Ex.: "[Br.]", "[Am.]", "[Ös.]", "[Sächs.]"
    b) Ex.: "[South Africa]", "[Hessen]", "[Berlin]", "[Wien]"
    d) Ex.: "[French]", "[Lat.]"
    ? Represent as <usg type="geographic">?
      * According to TEI Lex-0: "marker which identifies the place or
        region where a lexical unit is mainly used"
        * Matches c) only.
    ? Separate d)?  And represent how?

Where is c)?

b) = c)

In any case, I see subtle differences and would suggest either to
be sloppy and group all these as a sort of geographic identifier (only
French/Lat. don't fit)

What to do with French/Lat. then?

or to craft your own type and document this in the
header.

How would I do the latter?  (Seems like work that is less important and
hence postponed for now.)

In fact, this might be a benefitial solution for the project. TEI
remains, AFAIR, vague enough and if you thoroughly document your choices, we
might adopt this as a guideline for the project. Up to now, we have been not
enough into this.

A.7) Abbreviations.
    a) Headwords, which are annotations.
       * rare
    b) Annotated on headwords.
    ? How to represent in TEI?
      * The TEI documentation contains an example [7] with both
        <form type="abbrev"> and <form type="full">, in the same
        <entry>.
        * I remember though that within the Freedict project multiple
          <form> tags inside <entry> are frowned upon.

Just do:

    <entry>
      <form>
        <orth>headword</orth>
        <form type="abbrev">
          <orth>h.w.</orth>
        </form>
      </form>
    …

And "Headwords, which are *abbreviations*" (wrong word above) I would
represent as

  entry/form[@type="abbrev"]/orth ?



Some more questions have come up (none of them very pressing):


A.8) entry/sense/gramGrp - OK?
     ? No entry/gramGrp then?
     ? Or may these be combined?
     * From the Ding directly, I only get gramGrp on the sense level; on
       the level above they need to be infered (if applying to all
       senses)
       * Special case: single sense (likely very frequent)
     * Note: Several senses arise from joining orthographically
       identical headwords together.

A.9) Header

A.9.1) fileDesc/publicationStmt/license
       In Freedict, I see only <availability> used (for licensing
       information).  Why not <license>?

A.9.2) Date
       * The Ding is annotated with both a version and a date.
       ? How/whether to represent the date?

A.9.3) fileDesc/publicationStmt/pubPlace
       * HowTo [11]: "http://freedict.org/";
       * (example) TEI:
         "<ref target="http://freedict.org/";>http://freedict.org/</ref>"
       ? Which?

A.9.4) notesStmt/note[@type="status"]
       * HowTo [11]: "documents the size of the database"
       * existing eng-deu.tei: "old upstream version"
       * Elsewhere: "Big enough to be useful", "stable"
         ? One of these two?  Which?

A.9.5) revisionDesc/change
       * HowTo [11]: "The attribute version of a change is mandatory."
         ? @version = @n (never seen @version in change)
       * In practice, @n seems infrequently used.
       ? Is it mandatory?
         ? If so, what to put there?
           ? Start versioning the importer?

A.9.6) fileDesc/editionStmt/edition (Version)
       ? Add minor version to account for changes caused by the
         importer?

A.9.7) fileDesc/titleStmt/editor
       * Should I consider myself an editor?
       * TEI doc: "[...] acting as editor, compiler, translator, etc."


C.11) Reference types.
      a) Ding: unit ~word
         * often synonyms, not always
         ? xr[@type="see"] (seems correct to me)
      b) Ding: unit1; unit2
         * Units that translate to the same group of units.
         * Considered bidirectional synonyms.
         * Frequently differently gendered forms of the same word
           * I think it's OK to consider these synonymous.
             * Otherwise, identification of plural forms using a
               heuristic should be doable.
         ? xr[@type="syn"] (seems correct to me)
         ? Should <ref/> have a content?
           ? Or only @target?
      c) Ding: unit1 | unit2  //  group1 | group2
         * units that are somewhat related
         ? xr[@type="see"]
           * no longer discernible from a).
         ? Some other/new @type value (for a) or c))?
         ? Should <ref/> have a content?
           ? Or only @target?


Regards,
Einhard


[10]
https://dariah-eric.github.io/lexicalresources/pages/TEILex0/TEILex0.html#index.xml-body.1_div.7_div.2
[11]
https://github.com/freedict/fd-dictionaries/wiki/FreeDict-HOWTO-%E2%80%93-Writing-Text-Encoding-Initiative-XML-Files
-- 
FreeDict - Free And Open Dictionaries
Manage your subscription at https://www.freelists.org/list/freedict
Wiki: https://github.com/freedict/fd-dictionaries/wiki
Web: http://freedict.org

Other related posts: