- From: Gil Francopoulo <gil.francopoulo@wanadoo.fr>
- Date: Fri, 13 Jun 2014 13:37:48 +0200
- To: public-ontolex@w3.org
- Message-ID: <539AE28C.3060206@wanadoo.fr>
Hi, Excuse me but in English, the notion of "phrase" is rather different from the notion of "multiword unit", see for instance the definition in Crystal (a dictionary of linguistics and phonetics). The span of a multiword unit does not need to match the limits of well formed phrases. The extreme situation is when a multiword unit is not a phrase but a whole sentence like: "there is no free lunch" if the lexicon manager needs to document the meaning of this "element" in his lexicon (other issue: what part of speech ? interjection ?). Gil Le 13/06/2014 13:09, John P. McCrae a écrit : > 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 > <mailto: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 >> <http://lemon-model.net/lemon-cookbook/node11.html>, >> conditions >> <http://lemon-model.net/lemon-cookbook/node30.html>, >> definitions, examples and incompatibility >> <http://lemon-model.net/lemon-cookbook/node14.html> >> * 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 <tel:%2B49%20521%20106%2012249> > Fax:+49 521 106 12412 <tel:%2B49%20521%20106%2012412> > Mail:cimiano@cit-ec.uni-bielefeld.de <mailto:cimiano@cit-ec.uni-bielefeld.de> > > Forschungsbau Intelligente Systeme (FBIIS) > Raum 2.307 > Universität Bielefeld > Inspiration 1 > 33619 Bielefeld > >
Received on Friday, 13 June 2014 11:38:15 UTC