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

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?

 
> 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 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).

> 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.

> 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. 

> 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)