Re: multilingual lexical entries?

Dear Jorge,

I'm fine with that, but even then, we still need to make the single
language constraint explicit in OntoLex, then, because right now, it isn't.

Best,
Christial

Jorge Gracia del Río <jogracia@unizar.es> schrieb am Mo., 10. Jan. 2022,
11:03:

> Dear Christian,
>
> One of the motivations of the lexicog module was to cover aspects of
> dictionaries that go beyond the "standard" way of representing lexical
> information in Ontolex lemon. I think that yours is one of such cases.
> Possibly I am missing some details here, but I can perfectly imagine your
> language-agnostic entries as being represented by lexicog:Entry. Notice
> that such a class does not have the language restriction that
> ontolex:LexicalEntry has, and can be directly mapped with your dictionary
> records. Maybe it might be even possible (yet unusual) that the entry
> describes a LexicalForm directly (to account for an ideographic sign).
> Then, for the cases where the language and the meaning are known, the usual
> Ontolex machinery can be included (LexicalEntry, LexicalConcept).
>
> Best,
> Jorge
>
>
>
>
> El mié, 5 ene 2022 a las 16:35, Christian Chiarcos (<
> christian.chiarcos@gmail.com>) escribió:
>
>> Dear Jorge,
>>
>> thanks for the suggestion. Of course that would work from a modelling
>> perspective, but the problem is that in many cases we just don't know what
>> the language is, and it could be either Sumerian or Akkadian and even have
>> different readings (i.e., Latin renderings) for the same signs. For a
>> frequent word like a unit of weight (as in the example), this clearly
>> applies to both languages, but in other cases we risk creating ghost
>> entries instead of providing the language only in cases where we are
>> certain about the language.
>>
>> For this particular case (etymological dictionaries are different), the
>> problem is not so much that the entries are multilingual, but that the
>> defining criterion what enters our dictionary is not the language, but the
>> writing system, time and provenance of the writing. At times, we don't know
>> the language, and for languages with ideographic writing systems, this can
>> occur regularly. There are, indeed, entire writing systems that are not
>> language-specific and for whose texts we cannot really tell what the
>> language was (e.g., https://en.wikipedia.org/wiki/Zapotec_script, whose
>> tendency towards abandoning syllabic characters seems to be motivated by
>> its spread to foreign speaker communities; the linguistic identification of
>> the entire Teotihuacano writing is very uncertain, cf.
>> https://www.mesoweb.com/bearc/caa/AA01.pdf, and also early Sumerian
>> writing is fully pictorial, so we cannot ascertain its actual language and
>> only speculate that it was Sumerian, e.g., for the
>> https://en.wikipedia.org/wiki/Kish_tablet, -- and this has been
>> debated).
>>
>> The practical problem is that we need to duplicate large parts of our
>> dictionary, and in particular, this pertains to the attestations (all
>> occurrences in the corpus should be linked). For a sample window of 100
>> years (2100-2000 BCE), we are talking about a corpus of about 3 million
>> tokens where the problem of multilinguality is particularly prevalent, and
>> if no automated disambiguation can be performed, we might end up linking
>> each token twice. With the current FrAC vocabulary, that would mean to
>> create some 7.5 million additional triples (5 triples per attestation, for
>> 3 million tokens) simply for the luxury of having two lexical entries. We
>> could link the attestations to the lexical concept, but in fact, we need to
>> link them with a particular form, not with a particular meaning. (So we
>> need resolvable ontolex:Forms.) I am not sure whether the same form should
>> occur with different lexical entries (this seems counter-intuitive, but is
>> not formally required, depending on the generic or specific reading of the
>> determiner in "one grammatical realization of *a* lexical entry."), but
>> these need to be duplicated then, too. In fact, using one ontolex:Form with
>> multiple lexical entries (i.e., the same entry for different languages)
>> could be another solution to this problem.
>>
>> We will have the same problem for pictograms at some point. We certainly
>> do for things like road signs and emoticons, which differ in form and
>> function over certain areas (think of the use of stop signs in EU vs. US
>> all-way stops), but these areas do not overlap with particular languages --
>> and it is still possible (and there seems to be a need) to create
>> machine-readable dictionaries for them:
>> https://github.com/nikukyugamer/kaomojitoka-to-google-ime-dictionary.
>>
>> For this reason, because of its obscure way of introduction (i.e., not at
>> LexicalEntry but in Lime), and because it is actually not part of any
>> definition, but just mentioned in accompanying text, I am wondering whether
>> OntoLex is actually supposed to have a single language constraint. I think
>> it is clear that there must be a preference to have that (which is why lime
>> says "should", not "must"), and that that should be formulated more
>> explicitly in the core module. But also, I have a feeling that in the
>> context of diachrony, multilingual terminology and multimedia the existence
>> of cross-linguistic lexical entries will be a recurring question, so if any
>> deviations or refinements of OntoLex core properties, e.g., in designated
>> subclasses would be neccessary, it would be good to refer to that line in
>> the documentation.
>>
>> I suggest to *decide* for one of the following additions to OntoLex core:
>> (a) stricter definition: "A lexical entry can define its language using
>> the properties lime:language or dct:language (see Metadata module). It is
>> recommended to create different lexical entries for different languages."
>> (b) broader definition: "A lexical entry can define one or multiple
>> languages using the properties lime:language or dct:language (see Metadata
>> module)."
>> [insert right after "A Lexical Entry thus needs to be associated with at
>> least one form, and has at most one canonical form (see below)."]
>>
>> This is a clarification for the following passages from Lime:
>> "note that all entries in the same lexicon should be in the same
>> language" (which does not say what happens if the same lexical entry occurs
>> in multiple lexicons -- actually, this doesn't seem to be ruled out by
>> Lime).
>> "The language property indicates the language of a lexicon, a lexical
>> entry, a concept set or a lexicalization set." (whether this says anything
>> about cardinality constraints depends on the generic or exhaustive
>> interpretation of the determiner, so this is ambiguous)
>> "Beyond using the lime:language property, which has a Literal as a range,
>> it is recommended to use the Dublin Core language property"
>>
>> Independently from what we will eventually decide, it makes sense to put
>> a note on the language property into OntoLex core because the property
>> occurs in diagram and examples, but not in the text.
>>
>> From the feedback I got so far I expect a general preference for (a), so
>> this seems to be the default assumption. Personally, I am more in favor of
>> the broader definition (b) because it does not invalidate any resources
>> created in accordance with (a), it consistent with our earlier use for
>> multilingual and etymological databases (which (a) is not), because we
>> arrive at a more compact modelling and because it minimizes the dependency
>> from non-core modules (which will make data less comprehensible for future
>> users). Maybe others can give some feedback here.
>>
>> Best,
>> Christian
>>
>> Am Mi., 5. Jan. 2022 um 10:38 Uhr schrieb Jorge Gracia del Río <
>> jogracia@unizar.es>:
>>
>>> Dear Christian,
>>>
>>> What about this other approximation? That is, creating a
>>> "language-agnostic" lexicog:entry per known record in the dictionary, and
>>> then instantiate lexical entries to account for the language specific
>>> information:
>>>
>>> :sze_concept a ontolex:LexicalConcept;
>>>      skos:definition "unit of weight, approx 0.04 g" .
>>>
>>> :sze_sux a ontolex:LexicalEntry;
>>>     ontolex:canonicalForm [
>>>         ontolex:writtenRep "𒊺"@sux-Xsux;
>>>         ontolex:writtenRep "sze"@sux-Latn
>>>     ] .
>>>
>>> :sze_akk a ontolex:LexicalEntry;
>>>     ontolex:canonicalForm [
>>>        ontolex:writtenRep "𒊺"@akk-Xsux;
>>>        ontolex:writtenRep "uţţatu"@akk-Latn
>>>     ] .
>>>
>>> : sze_concept  ontolex:isEvokedBy :sze_sux:,  sze_akk  .
>>>
>>> :sze_entry a lexicog:Entry ;
>>>      lexicog:describes sze_sux, :sze_akk .
>>>
>>>
>>> Best regards,
>>>
>>> Jorge
>>>
>>> El mié, 8 dic 2021 a las 14:54, Christian Chiarcos (<
>>> christian.chiarcos@gmail.com>) escribió:
>>>
>>>> Dear all,
>>>>
>>>> just for clarification, the following is what I would like to do:
>>>>
>>>> :sze_le a ontolex:LexicalEntry;
>>>> ontolex:canonicalForm [
>>>> ontolex:writtenRep "𒊺"; # or: ontolex:writtenRep "𒊺"@sux-Xsux, ontolex:writtenRep
>>>> "𒊺"@akk-Xsux
>>>> ontolex:writtenRep "sze"; # transliteration
>>>> ontolex:writtenRep "sze"@sux-Latn; # transcription
>>>> ontolex:writtenRep "uţţatu"@akk-Latn # transcription
>>>> ]; ontolex:sense [ rdfs:comment "unit of weight, approx 0.04 g" ].
>>>>
>>>> The alternative with lexicog:Entry (and without duplicating
>>>> LexicalEntries) would be
>>>>
>>>> :sze_le a lexicog:Entry;
>>>> lexicog:describes [ a ontolex:Form;
>>>> ontolex:writtenRep "𒊺";
>>>> ontolex:writtenRep "sze"; # transliteration
>>>> ontolex:writtenRep "sze"@sux; # transcription
>>>> ontolex:writtenRep "uţţatu"@akk # transcription ... IMHO different
>>>> language tags should be unproblematic for forms
>>>> ]; lexicog:describes [ a ontolex:LexicalSense; rdfs:comment "unit of
>>>> weight, approx 0.04 g"].
>>>>
>>>> The latter way of modelling should be in line with the documentation,
>>>> but it makes large parts of OntoLex-Lemon redundant and others (e.g.,
>>>> canonicalForm) inapplicable, I would prefer to avoid that.
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>> Am Di., 7. Dez. 2021 um 16:32 Uhr schrieb Christian Chiarcos <
>>>> christian.chiarcos@gmail.com>:
>>>>
>>>>> Dear all,
>>>>>
>>>>> for different use cases, I came across the need to provide one lexical
>>>>> entry for multiple languages.
>>>>>
>>>>> In one group of cases (esp., etymological dictionaries), this can be
>>>>> circumvented by using lexicog:Entry, instead, and then point to
>>>>> language-specific lexical entries. (Though this is very inelegant,
>>>>> unnecessarily verbose and clearly a departure from/obfuscation of the
>>>>> original structure of the lexical resource, but technically, it is a
>>>>> possibility.)
>>>>>
>>>>> However, in another case (dictionaries/glossaries for cuneiform
>>>>> languages), we have the problem that we cannot always tell what language a
>>>>> text (and thus, a word) is in. This is because of the multilingual
>>>>> situation of Sumerian and Akkadian during the 3rd m. BC, because of the use
>>>>> of ideographic signs, because of the laziness of scribes to often not write
>>>>> morphemes, but just the stem of a word, and because of the habit of
>>>>> Akkadian and Hittite scibes to just write Sumerian (or Akkadian) words
>>>>> instead of their native tongue because these were more established in the
>>>>> writing tradition. Although there are phonological or morphological
>>>>> complements that can reveal the language, these are not systematically
>>>>> used, so that we have uncertainties about the language of individual words
>>>>> or even entire texts. However, if these texts form the basis for a glossary
>>>>> or dictionary, these uncertainties percolate to the glossary, especially if
>>>>> it is corpus-based. The Electronic Penn Sumerian dictionary thus does not
>>>>> distinguish Sumerian and Akkadian forms and just groups everything under
>>>>> the same head word and just provides Sumerian and Akkadian readings of the
>>>>> same sign. (The selection of texts is such that a Sumerian reading is more
>>>>> likely, but it is not always necessary.) In some cases in this dictionary,
>>>>> it is even marked that there are doubts that a word is Sumerian in the
>>>>> first place (http://oracc.museum.upenn.edu/epsd2/cbd/sux/o0023151.html
>>>>> ).
>>>>>
>>>>> Such data does not allow to create distinct lexical entries for both
>>>>> (or, in case of Hittite texts, three) languages that would just go under
>>>>> the same lexicog:Entry, because we cannot decide which information (other
>>>>> than the possible Sumerian and Akkadian interpretations of the same
>>>>> Cuneiform writtenRep) belongs to which lexical entry.
>>>>>
>>>>> For this reason, we are currently considering to have
>>>>> language-agnostic lexical entries for a future CDLI glossary (
>>>>> https://cdli.ucla.edu/), where language information is provided only
>>>>> at the form (or even, within the writtenRep), but not at the lexical entry.
>>>>> Note that there is no constraint in the OntoLex core model that requires a
>>>>> single language per lexical entry.
>>>>>
>>>>> What OntoLex says about language is not in the core model, but in
>>>>> Lime: "note that all entries in the same lexicon should be in the same
>>>>> language and that the language of the lexicon and entry should be
>>>>> consistent with the language tags used on all forms". This a comment (in
>>>>> parenthesis, in accompanying text, and if assumed to be relevant for the
>>>>> definition of ontolex:LexicalEntry, in the wrong place), formulated as a
>>>>> recommendation and not part of any definition.
>>>>>
>>>>> If we consider this statement to be nevertheless binding, the CDLI
>>>>> solution would be to create a dictionary with senses and lexicog:Entrys,
>>>>> but without ontolex:Entrys. I would prefer not to. (I would still prefer to
>>>>> avoid multilingual lexical entries in cases in which language-specific
>>>>> information is provided, and thus to keep the recommendation in place, as
>>>>> is, but this is not the case here.)
>>>>>
>>>>> Best,
>>>>> Christian
>>>>>
>>>>