OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

lexidma message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [lexidma] Module-by-module proposal


Hi Michal,

On 31/05/2021 11:14, Michal MÄchura wrote:
Hi John,

1/ You model the headword as an attribute, and the inflected forms as a child of an entry. This can lead to some issues as it is not possible to provide further information about the lemma form (e.g., a label) and leads to the lemma often being repeated in the entry. This is actually what LMF does so it is not unprecedented but I am not keen on it.

You have misunderstood what I mean by "attribute". You apparenly think it means an XML attribute, but that's not what "attribute" means in in my proposal. The object model we are building here is more abstract than that. I am calling an "attribute" everything that has an arity of "exactly one". Maybe I should have called it something else, like "property", to avoid this terminological trap. Or maybe kill the distiction between "children" and "attributes" altogether!

I agree with you that in an XML implementation of this object model, headwords should be implemented as XML elements (not as XML attributes), for exactly the reasons you describe.
Okay, I guess this makes sense. But we should distinguish between objects and values as all serialization schemes do this in practice.

2/ I am not sure about allowing PartOfSpeech, Pronunciation and InflectedForm as children of Sense. Having senses of an entry with different part-of-speech values is something that some models explicitly avoid, we would also need to figure out how this inherits from the Entry's PartOfSpeech. I don't think we should have Pronunciation and InflectedForm at all, as senses with different pronunciations or inflections are homographs and we really should insist that homographs are distinct at the Entry level.

I am not sure of it either, it does smell of bad practice: sloppy separation between form and function. We could go the radical route and prohibit it altogether. On the other hand it is what lexicographers sometimes want to do. This always makes me think of the Czech word "jeÅÃb" 'crane which has two different plurals depending on whether it's the animal or the machine: I don't think lexicographers would welcome the idea of having to create two separate entries for these. This is not an exception, I could probably dig out other examples from oher languages. So the question is: do we want to force lexicographers to re-analyze all sense-specific morphosyntax as homonmy?
I would say so... but what do others think here?

3/ There seems to be no way to record properties of entries such as noun gender in the model.

That's what the Label object type would be for, in my proposal.

4/ Pronunciation probably needs a scheme and a variety property. See this recent paper (Sec 3.3) for a discussion of this: https://www.aclweb.org/anthology/2021.gwc-1.11.pdf

For scheme, probably, yes. For variety, if by that you mean things like 'British'Â versus 'American', I enviaged that, again, the Label object type would do that.
Okay... so label is very overloaded in terms of what it represents. My feeling is I would prefer some more specific categories for common annotations.

5/ I don't see the logic of having the name TranslationPartOfSpeech (etc.) as distinct from PartOfSpeech (and why not SensePartOfSpeech to be consistent?)

The logic is that there would be one set of these types for the source language and another set for the target language. Each would take its allowed values from seprate controlled vocabularies.

6/ It is odd that a sense group has a part-of-speech value. What is the purpose of this?

Same reason as why senses have parts of speech: it's sense-specific mophosyntax, and it is one of the criteria by which a lexicographer might group senses into sense groups.

Okay.

Regards,

John


M.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]