W3C home > Mailing lists > Public > public-ontolex@w3.org > June 2014

Re: Issues with backwards compatibility

From: Francis Bond <bond@ieee.org>
Date: Fri, 13 Jun 2014 20:12:14 +0800
Message-ID: <CA+arSXgoVFgq3qWxJzjVxT3jT8UV9P3ejU965VYP=F1zYVC-Fw@mail.gmail.com>
To: "John P. McCrae" <jmccrae@cit-ec.uni-bielefeld.de>
Cc: Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de>, public-ontolex <public-ontolex@w3.org>
I think phrase is wider than the normal use of MWU.  "a very
interesting book I picked up last Thursday" is a phrase, as is "dog
ate two cats with relish", but they would not normally be called
multi-word units.  Of course, we can define our own meanings, but it
is good not to strain the standard usage too much.



On Fri, Jun 13, 2014 at 7:09 PM, John P. McCrae
<jmccrae@cit-ec.uni-bielefeld.de> wrote:
> Hi,
>
> 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).
>
> Regards,
> John
>
>
> On Thu, Jun 12, 2014 at 11:49 PM, Philipp Cimiano
> <cimiano@cit-ec.uni-bielefeld.de> 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.
>>
>> https://www.w3.org/community/ontolex/wiki/Monnet_OntoLex_Compatibility
>>
>> 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: cimiano@cit-ec.uni-bielefeld.de
>>
>> Forschungsbau Intelligente Systeme (FBIIS)
>> Raum 2.307
>> Universit├Ąt Bielefeld
>> Inspiration 1
>> 33619 Bielefeld
>
>



-- 
Francis Bond <http://www3.ntu.edu.sg/home/fcbond/>
Division of Linguistics and Multilingual Studies
Nanyang Technological University
Received on Friday, 13 June 2014 12:13:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:36:40 UTC