Re: [lexidma] Working draft

[John McCrae <john.mccrae@insight-centre.org>]

On 12/10/2021 16:12, Michal MÄchura wrote:

Re: conflating gender etc, into part of speech

Okay, I donât like all this âconflatingâ, it seems like a hack to me that is not really necessary.

Another option would be to have a more generic âlabelâ type and (optionally) use a controlled vocabulary to tell us what kind of label it is: part of speech or gender or whatever. That would still allow conflating but would also allow ânot-conflatingâ.

In fact, our sense-level usage labels do this already, so for consistency we should probably do it for our entry-level grammar labels too.

    I would recommend a key/value style representation of linguistic
    properties. This is the approach taken in all other models and would
    connect with other controlled vocabulary mechanisms (CLARIN, GOLD,
    LexInfo etc.)

---

Re: collocations

Yeah, but as you see we often get full sentences as âcollocationsâ and in many dictionaries the definitions rely significantly on context.

That Irish-English dictonary youâre looking at (Ã DÃnaillâs FGB from 1977) is exceptional in that it makes no clear distinction between collocations and example sentences and other kinds of multiword units that appear inside the articles. The bold/italic type is not a consistent guide either. I know this dictionary well, I had a hand in its retrodigitization a while back. :-) If somebody wanted to convert FGB into DMLex I would advise them to either treat all those things as example sentences, or else to manually decide for each one whether or not it deserves to be its own (sub)entry. And either way, this dictionary is on the periphery of Lexidmaâs interests because itâs an old paper one. I get the impression that modern born-digital dictionaries tend to be more clear on whether something is or isnât a (sub)entry.

I wouldn't say that it is just FGB. I think the practice is very common in bilingual dictionaries. For example, Collins Italian-English dictionary* has many full phrases. I was looking at the print version but the online one is similar:

https://www.collinsdictionary.com/dictionary/italian-english/questo

* The first bilingual dictionary I could find on my shelf :)

---

A simple solution would be to just have a single Relation object and use the controlled vocabulary model to define the types of relations?

Thatâs doable, yes. But still, I think we need separate Relation subtypes depending on their arity and directionality. Like, a synonymy relation can have two or more participants and is undirected, an antonymy relation must have exactly two participants and is also undirected, a hyperym/hyponym relation has two participants and is directed.

I see. What is the reason to care about symmetry and arity? It only seems useful if you are going to add some kind of reasoning or validation methodology, which would add many more complexities to the model.

Regards,

John

M.

Ãt 12. 10. 2021 vÂ14:48 odesÃlatel John McCrae <john.mccrae@insight-centre.org> napsal:

Hi Michal,

Thanks.

On 12/10/2021 10:42, Michal MÄchura wrote:

We have no way to represent fine-grained morphosyntactic information, including gender of nouns and categories of inflections. For example the annotation on this entry and its inflected form âboiseâ

For gender (and other properties) of nouns (and other word classes) the idea is that implementers would conflate them with part-of-speech labels: they would create a âmasculine nounâ part-of-speech label, a âfeminine nounâ part-of-speech label, and so on.

For inflection categories, for example to say that this noun belongs in such-and-such inflectional paradigm, there my suggestion would again be to conflate this with the part-of-speech label, for example âfeminine noun of the second declensionâ.

Note that in DMLex, implementers can use the Controlled Vocabularies module to tell the world what their home-baked part-of-speech labels map to in some external data category ontology, for example to LexInfo.

For inflected forms, thatâs what the InflectedForm object type is for (but no tildas please).

Okay, I don't like all this 'conflating', it seems like a hack to me that is not really necessary.

We cannot give citations for sources of information, as is typical in historical dictionaries (see image)

True. This would be a good candidate for a module.

There is no etymology information (as discussed in the call). See example in Merriam-Webster:

True again, and again itâs a candidate for a module.

Okay, I will try to make some pull requests for candidate modules.

I am not sure how we intend to implement collocations (see example in FoclÃir Gaeilge-BÃarla)

My idea was that each collocation would be treated as an entry (with the full-form collocation as its headword, for example âlÃn boiseâ), and this entry would be connected to its âmotherâ entry through SubentryRelation.

To my mind, this is the only reasonable way to handle collocations if we want to avoid embedded subentries and headword overriding (see my report on subentrying earlier in Lexidma and also my presentation on recursion at eLex recently).

Yeah, but as you see we often get full sentences as 'collocations' and in many dictionaries the definitions rely significantly on context. I think the solution above may work, but we should certainly try it on some real dictionary data to see how practical it is.

No modelling for hypernym relations

I was thinking most lexicographers would be happy enough to model hypernymy and hyponymy through SimilarityRelation in the Crossreferencing module. But, by all means, feel free to propose a more detailed inventory of relation types for this module if you want.

I think that the distinction between synonyms and hypernyms is quite important and few dictionaries would like to conflate these. A simple solution would be to just have a single Relation object and use the controlled vocabulary model to define the types of relations?

On a general note, Iâm sure people from both inside and outside Lexidma will have a lot of questions like these; how do I handle nound gender in DMLex, how do I handle collocations in DMLex, and so on. The standard itself is probably not the right place to answer them. So, perhaps we should think about producing some sort of a âcookbookâ to go with the standard as an additional, less formal guide to implementing DMLex.

I agree. Examples will need to be documented somewhere.

Regards,

John

M.