Hi Sebastian,
thanks again for all the answers!
On 09/09/2020 08:25, Sebastian Humenda wrote:
Can you give us a hint on your timely plan so that we can prioritise your
questions?
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.9.2) DateIn publicationStmt, there can be:
* The Ding is annotated with both a version and a date.
? How/whether to represent the date?>
<date when="2017-11-18">Nov 18, 2017</date>
