Re: Issues with backwards compatibility


The term "Phrase" is for me preferable to MultiWordUnit as it is more
linguistic, less technical, shorter and the same as the *lemon* model. I
would also introduce a disjoint class "Word" as this is useful for saying
an entry isn't a multi-word unit. If we do I don't think it hurts to
include "Affix" as well to cover all our bases (that is Phrase for >1
words, Word for =1 word and Affix for <1 words).

I have no objection to extending the use of confidence to senses (other
than my existing objections to confidence being too poorly defined at the
moment ;).

I was discussing some use cases that required incompatibility in the case
of diachronic changes in meaning, but thinking more about, it is quite
narrow and perhaps should be pushed to LexInfo 3.0 (or whatever we are
going to do as a more complete but non-standard model).


On Thu, Jun 12, 2014 at 11:49 PM, Philipp Cimiano <> wrote:

>  John, all,
>    a few things. I am in favour of introducing the class "MultiWordUnit"
> as a subclass of LexicalEntry, fair enough.
> Concerning the properties "context", "condition" and "incompatibility".
> "context" and "condition" are useful, clearly. But then the property
> "confidence" of a Translation should also be there. I see the three equally
> useful and equaly vague semantically as they could have anyhting as a
> range.
> Concerning "incompatibility": not sure, this seems like one of many
> possible properties that could be defined between senses, so it seems quite
> arbitraty to pick this one out.
> Just my two cents,
> Philipp.
> Am 06.06.14 17:25, schrieb John P. McCrae:
> Hi all,
>  Due to the large number of resources using the previous Monnet *lemon *vocabulary
> it seems natural that we should support users who wish to transition to the
> W3C OntoLex *lemon *vocabulary. As such I was looking into the conversion.
>  There are some areas where the previous model has significant
> differences that we should consider whether to adopt. (Of course I do not
> assume that everything in Monnet Lemon should be transferred across but we
> should attempt to be able to represent relevant use cases already addressed
> by Monnet Lemon).
>  From my analysis, there are two main issues that we should still address
>    - Monnet *lemon* has more sophisticated description of senses, in
>    particular, mechanisms such as contexts
>    <>, conditions
>    <>, definitions,
>    examples and incompatibility
>    <>
>    - Monnet *lemon* allows us to say if a lexical entry is a multi-word
>    expression, affix or word.
> Any comments on whether we should allow this modelling
>  Regards,
>  John
> --
> Prof. Dr. Philipp Cimiano
> Phone: +49 521 106 12249
> Fax: +49 521 106 12412
> Mail:
> Forschungsbau Intelligente Systeme (FBIIS)
> Raum 2.307
> Universit├Ąt Bielefeld
> Inspiration 1
> 33619 Bielefeld

Received on Friday, 13 June 2014 11:10:10 UTC