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

Re: Analysis of Senso Comune ontology w.r.t to lemon

From: John McCrae <jmccrae@cit-ec.uni-bielefeld.de>
Date: Thu, 14 Jun 2012 22:39:32 +0200
Message-ID: <CAC5njqrpvMBueHT=Y2JSTMKXmYrXGKXFcR+TM+Bsih1dMcznyg@mail.gmail.com>
To: Guido Vetere <gvetere@it.ibm.com>
Cc: Aldo Gangemi <aldo.gangemi@istc.cnr.it>, Alessandro Oltramari <aoltrama@andrew.cmu.edu>, Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de>, Paul Buitelaar <paul.buitelaar@deri.org>, public-ontolex <public-ontolex@w3.org>
On Thu, Jun 14, 2012 at 9:54 PM, Guido Vetere <gvetere@it.ibm.com> wrote:

> John,
> thanks for your remarks. In general, as I said, our owl ontologies are in
> a draft status, and there are a number of known (but not striking)
> differences w.r.t. the current agreed model.
> Please find my reply below.
> Guido Vetere
> Manager, Center for Advanced Studies IBM Italia
> _________________________________________________
> Rome                                     Trento
> Via Sciangai 53                       Via Sommarive 18
> 00144 Roma, Italy                   38123 Povo in Trento, Italy
> +39 06 59662137                     +39 0461 314031
> Mobile: +39 3357454658
> _________________________________________________
> johnmccrae@gmail.com wrote on 14/06/2012 15:16:29:
> > John McCrae <jmccrae@cit-ec.uni-bielefeld.de>
> > Sent by: johnmccrae@gmail.com
> >
> > 14/06/2012 15:16
> >
> > To
> >
> > Guido Vetere/Italy/IBM@IBMIT, Alessandro Oltramari
> > <aoltrama@andrew.cmu.edu>, Philipp Cimiano <cimiano@cit-ec.uni-
> > bielefeld.de>, Paul Buitelaar <paul.buitelaar@deri.org>, Aldo
> > Gangemi <aldo.gangemi@istc.cnr.it>, public-ontolex <
> public-ontolex@w3.org>
> >
> > cc
> >
> > Subject
> >
> > Analysis of Senso Comune ontology w.r.t to lemon
> >
> > Hi all,
> >
> > I had a look into the Senso Comune. First, I hit the issue that that
> > the OWL files differ from Guido's presentation....
> >
> > I think one of the important issues is that  "MeaningRecord" from
> > Guido's slides is entirely absent from the slides but there is a
> > class called "Acceptation" that I guess is the same class.
> >
> You are right, I personally prefer Acceptation (it: Accezione), to give a
> lexicographical flavour, but others argued that the term is very uncommon
> in English. What's your opinion about that?
Yeah, we had a similar discussion I (and some other members of Monnet)
wanted to call the class "Sememe", but we decided for "lexical sense" on
the grounds that it was a familiar term people would expect to see in the
model, and it was easier to explain the difference in our concept of sense,
which I believe is close to yours of acception

> > Next I could not find the "mapping/punning" relationship between
> > MeaningRecord and Meaning... instead the link between Acceptation
> > and Meaning is via the Expression class.
> >
> I recall you that our mapping occurs between *instances* of Acceptation
> (MeaningRecord) and *classes* which are derived (subclassed) from the class
> Meaning. These mappings can be obtained via punning (a syntactic extension
> of OWL2 that, roughly, allows using the same URI for classes and instances)
> or via the 'classMapping' data property, which ranges over URIs. Another
> (maybe better) option would be using OWL Annotations. We know that this
> allows to set up unintended models (e.g. by mapping with URI whatsoever)
> but I guess that this is a fatal consequence of any model like this..
I didn't think to look for it under datatype properties... I think there is
an issue if you choose to model it that way in that then this is no longer
a link in the linked data sense, punning or annotations are better but have
their issues (punning is difficult for reasoning and annotations have only
a reduced set of axioms that can describe them in OWL2 and none in OWL1),
as I'm sure you know.

> > I also found it quite odd that SC has no direct relationship between
> > Lemmas and Words, however the Inflection class indicated that both
> > "cat" and "cats" would be words (hence word=>form in lemon), which
> > then confused me as this would lead to duplicate modelling of the
> > canonical form of the word (e.g., "cat" would have both a Lemma with
> > headWord="cat"@en and a Word with stringRealization="cat"@en)
> >

> Once again, our notion of Lemma is strictly lexicographic: it represents
> the section of the dictionary where a lexeme (more precisely, a bunch of
> etymological consistent senses of a lexeme) is described. The headword,
> hence, is just the string that allows you to find the entry in the
> dictionary. In fact, headwords can contain numbers, as in the case of
> homonymous terms. On the contrary, Word is a MorphologicalForm, i.e. a
> linguistic units with a lexical root and a number of grammatical features.
> They are linked by 'derivation' relations, hence we have a notion of 'base
> form', which, however, is not to be confused with Lemma. The relation
> between Lemmas, MeaningRecords and the corresponding Words is complicated
> indeed. For instance (trivially) not all the meanings of a lemma accept the
> same inflexion. Hence, we chose (after long discussions) to avoid a direct
> link between the two classes. Instead, if needed, we can retrieve all the
> Word's base forms for any lemma via the headword (there can be more than
> one, typically noun and adjective). Also, we set the appropriate
> grammatical restrictions to every Acceptation (e.g. only noun, any number).
> I see... in lemon we opted to say that any abbreviated form or form that
changes part-of-speech constitutes a new lexical entry. The reason is that
different parts of speech have different lexical properties (inflection
etc.) and moreover must be interpreted differently relative to the ontology
(due to the different linguistic structures). I suspect this will need to
be discussed again as it has been our experience that third parties do not
succeed in getting this right with lemon...

> > Based on these guesses (see attached diagram for SC core model as I
> > understand it) I would suppose the following mapping exists:
> > sc:Dictionary = lemon:Lexicon
> Ok
> > sc:Lemma = lemon:LexicalEntry: Represent that part of the dictionary
> > describing this word
> Ok
> > sc:Acceptation/MeaningRecord = lemon:LexicalSense: A meaning a
> > single word or phrase
> Ok
> > sc:Expression =~ lemon:SenseDefinition: A description of the meaningof a
> word
> Ok, but note that Expression is the class of any meaningful and combinable
> linguistic manifestation. A definition (glossa) is in fact one of these.
True, we probably should have a superclass of SenseDefinition that better
matches SC's expression

> > sc:Meaning =~ lemon's Reference: lemon takes a slightly different
> > stance here in not mixing the ontology and lexicon (thus a
> > referenced individual is not an instance of a lemon class) where as
> > SC relies on categorization that are both the referenced ontology
> > class and a sc:Meaning... I'm interested to here both viewpoints on
> > the modelling here
> Actually, SC aims at modelling the semantic counterpart of the lexicon,
> while lemon (if I understand well) aims at mapping with any legacy
> ontology. I would say that SC Meaning has no correspondence in lemon.

Agreed, Reference isn't a named class in lemon... I was attempting to say
there is a loose similarity here

> > sc:LinguisticForm = lemon:LexicalForm: Note here that in SC Word and
> > Phrase subclass Forms where as in lemon Word and Phrase subclass
> > LexicalEntry (sc:Lemma), perhaps someone from SC could comment on this?
> See my comments on Lemma vs Word above.
> > There are also some connection that differ
> > lemon connects entries to forms (sc: lemmas to words) by means of
> > the form property that has no equivalent in SC
> > SC connects forms to definitions by means of characterizes... lemon
> > has no such property
> In general, 'characterize' links reified semiotic concepts (including
> Meanings) with their referents, much like 'instance of'. Here the problem
> of logical layering is involved. Not a trivial one .. :-)
> > SC connects expressions to meanings (lemon: definitions to
> > references) by means of the meaning property, lemon would consider
> > this property to be between senses and references (sc: acceptation
> > and meanings). But as Guido's slides suggest he opposite perhaps
> > there is no difference here
> > Furthermore, SC at times seems to go into much more detail hence why
> > it is significantly larger (133 classes, 97 properties) than lemon
> > (31 classes, 57 properties). With lemon we split off a lot of this
> > modelling into another ontology called LexInfo (220 classes, 190
> > properties). As can be seen from attached screen shot this covers
> > similar ground to SC.
> >
> > In summary, it seems that the models cover very similar ground and
> > we should definitely attempt to learn from one another :)
> >
> Sure, and thanks for your remarks!
> > Regards,
> > John McCrae
> >
> > OWL files referenced:
> > http://www.sensocomune.org/ontologies/SensoComune.owl
> > http://www.sensocomune.org/ontologies/SensoComuneLexicon.owl
> > http://www.sensocomune.org/ontologies/SensoComuneSemantics.owl
> > http://www.monnet-project.eu/lemon
> > http://www.lexinfo.net/ontology/2.0/lexinfo[attachment
> > "Screenshot-10.png" deleted by Guido Vetere/Italy/IBM] [attachment
> > "senso-comune-core.png" deleted by Guido Vetere/Italy/IBM]
> IBM Italia S.p.A.
> Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI)
> Cap. Soc. euro 347.256.998,80
> C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153
> Società con unico azionista
> Società soggetta all’attività di direzione e coordinamento di
> International Business Machines Corporation
> (Salvo che sia diversamente indicato sopra / Unless stated otherwise above)
Received on Thursday, 14 June 2012 20:40:03 UTC

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