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

  • From: Sebastian Humenda <shumenda@xxxxxx>
  • To: freedict@xxxxxxxxxxxxx
  • Date: Wed, 9 Sep 2020 08:25:08 +0200

Hi Einhard

Einhard Leichtfuß schrieb am 30.08.2020,  0:56 +0200:

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

Great!

Note that I currently target version 1.8.1 exclusively.

1.8.1. of what?

Of the Ding.

Ok, I haven't checked this. Though when I visited the page two years ago,
there was a stable edition with 80,000 headwords and a "development" version
with 2xx,xxx headwords. You are not targeting the tremendously smaller
version, are you?

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?

No, they are not documentation. They are symlinked into each dictionary and
"make validation" will use them.
We have not used Lex-0 in our projects yet and I think using a consistent, but
battle-proven encoding is better for your thesis. Our conversion style sheets
and tools are not prepared for Lex-0.

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

Yes, I think this is better.

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?
[…]

It all boils down to somebody reading the document, defining our specific
requirements and potentially modification **and** implementing it.

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.

Sorry, I missed the point. I was unsure about determina and read up the
Wikipedia article, but apparently the wrong one. There is no encoding for this
ATM, I think. What is the Lex-0 suggestion? :) Isn't this anyway part of the 
usage? I
probably would have picked `<usg type="hint">mainly am.</usg>`, but maybe
that's too vague.

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?
[…]
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?

What about picking one of
https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-usg.html ;?

If I understand this slightly confusing page, it would in principle fine to
choose any type. If that were the case, I would at least document the choice
in the TEI header. I just checked the dict style sheets: they ignore the type
completely ;). It is really a parsing help, which strengthens the argument to
document your choice in the header.

Regarding where to document: in the fileDesc tag, you can have a noteStmt:

```xml
<notesStmt>
  <note type="status">small</note> <!-- mandatory for our DB -->
  <note xml:lang="de"> <!-- can be freely chosen -->
    <list><item>blah</list>
  </note>
</notesStmt>

You can use both paragraphs (p) or lists as above and have multiple notes. I 
think you can add this straight away.

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 ?

Sure.

A.8) entry/sense/gramGrp - OK?

Sure, even suggested if headword and translation gramGrp differ.
  Personally, I would put the grmGrp into the `form` if it is also in the 
sense, but that's my taste. But maybe that's not desired for consistency.

    ? Or may these be combined?

I didn't get this. Also, feel free if that answers has open points for you.

A.9) Header

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

I think that's down to the fact that we didn't manage to update our style 
sheets. I think the usage of this tag makes the validation fail and we hence 
decided to stick to plain text until the next potential format or style sheet 
update (discussion in a different thread).

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

In publicationStmt, there can be:

    <date when="2017-11-18">Nov 18, 2017</date>

A.9.3) fileDesc/publicationStmt/pubPlace
      * HowTo [11]: "http://freedict.org/";

Bah, non-HTTPS ;).

      * (example) TEI:
        "<ref target="http://freedict.org/";>http://freedict.org/</ref>"

Your style of writing is quite concise, I had to look up the entry :). I just 
updated the example to the `ref` version, which is preferred.

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?

Old upstream version is a broken marker, please use one of the HOWTO values.

A.9.5) revisionDesc/change
[…]

Please reread the section.

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

Up to you. Choose whatever you find logical. Maybe a date is helpful for an
imported dictionary? WikDict uses YYYY.MM; you might also want to consider the
Ding version.

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

I just grep'ed for the editor tag in our style sheets, you can use author,
editor or respStmt. If editor doesn't apply, don't use it. Again, have a look
at dictionaries such as eng-pol  or lat-deu (if somebody want to recommend
another one, please go ahead).

C.11) Reference types.
     a) Ding: unit ~word
        * often synonyms, not always
        ? xr[@type="see"] (seems correct to me)

Yes.

     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)

Sounds fine. Not sure whether slob supports this though. If you got a draft
version of the dictionary, it'd be great if you could test it with the FD
build system. That'll reveal whether the slob converter understands xr.

        ? Should <ref/> have a content?
          ? Or only @target?

Please put a human-readable representation there. Not all formats support
linking.

     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))?

Be creative, I wasn't sure myself at that time :). Again, if you feel it
deserves it, add a note in the header explaining your choice. BTW, you can
almost freely choose the xr type, in case the ones from FD are not enough.
There is unfortunately not a exhaustive list, but you might want to take a
look at tools/xsl/inc/teientry2txt.xsl:278 Everything in between
<xsl:template> that matches @type should grab your attention.

Can you give us a hint on your timely plan so that we can prioritise your
questions?

Thanks
Sebastian

Attachment: signature.asc
Description: PGP signature

Other related posts: