View source for Specification of Requirements/Lexicon-Ontology-Mapping

== Summary on Requirements on the Lexicon-Ontology-Mapping (Synthesis by PC) ==

The lexicon-ontology model '''must''' follow the principle of ''semantics by reference'' in the sense that the meaning of a lexical entry is specified by reference to an individual, class, object property or datatype property in a given ontology as well as a composition of these.

The association between a lexical entry and its meaning in the ontology '''should''' be modulated by ''senses''. A sense in our view a "linguistic sign" representing the disambiguated meaning of a lexical entry when interpreted as a given concept c. Technically, the sense object that stands for this disambiguated sense also reifies the relation between the lexical entry and the concept in question. This disambiguated meaning '''should''' be represented by a logical constant that will reify the association between the lexical entry and the concept in question. This reification '''will''' then allow to express pragmatic information related to the usage of the lexical entry as denoting the concept in question. 

The relation between the lexical entry and the ontology element '''should''' be represented by a path involving two object properties relating the lexical entry to one of its (many) sense and one relating the sense to the corresponding ontological element.  

For the sake of this discussion, let us refer to these properties as hasSense (with inverse isSenseOf) and hasReference (with inverse isReferenceOf). 

In general, the lexicon-model will '''must''' allow for a many-to-many mapping between lexical entries and ontology elements, with a lexical entry referring to different ontological elements (also from different ontologies) and for each ontology element having different lexical entries that lexicalize it.

The lexicon-ontology model '''should''' support reasoning about senses, inferring equivalence (synonym) or subsumption relations between senses by reasoning over the lexicon-ontology interface involving both the lexicon and the ontology. At least, it '''must''' allow to represent such relations.

The lexicon-ontology mapping '''must''' further allow to represent the syntactic behaviour including the syntactic arguments that a lexical entry subcategorizes as well as how these arguments map to semantic arguments of the reference.  More on this will be discussed within the requirements on high-order mappings.

The lexicon model '''must''' thus allow to specify different lexical variants and paraphrases by which a certain class, property or named entity can be expressed. So this requirement essentially states that there should be a M:N mapping between lexical entries and ontology entities. That means, given an ontology entity, there can be many different lexical entries associated to this entity. On the other hand, given a lexical entry, it can be ambiguous in the sense of expressing very different ontological entities.

Take the property dbpedia:artist in from DBpedia. This property has a certain artwork (painting, photo, sculpture etc.) as subject and the actual person that created the artwork as range.

A fact using this property would be:

http://dbpedia.org/resource/Mona_Lisa http://dbpedia.org/property/artist http://dbpedia.org/resource/Leonardo_da_Vinci.

This property can be straightforwardly lexicalized as:

The artist of Mona Lisa is Leonardo da Vinci.

However, there are many other possible lexicalizations of this property, including:

Leonardo da Vinci '''painted''' the Mona Lisa.

Leonardo da Vinci '''created''' the Mona Lisa.

Leonard da Vinci is the '''painter of''' the Mona Lisa.

Leonardo da Vinci is the '''creator of''' the Mona Lisa.

...

The ontology lexicon model should allow to specify all these different variants by appropriate lexical entries mapping to the same property (http://dbpedia.org/property/artist).

A question that we leave open for now is whether there should be a shortcut path that uses one object property to establish the relation between a lexical entry and its reference. Such a one-property path would reduce the cognitive complexity of the model and facilitate the use of the model by users who do not require a reification of the relation between a lexical entry and its reference.

=== Examples using DBpedia ===

<pre>

@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix lexinfo: <http://www.lexinfo.net/ontology/2.0/lexinfo#> .
@prefix lemon: <http://www.monnet-project.eu/lemon#> .
@prefix isocat: <http://www.isocat.org/datcat/> .
@prefix base: <http://sc.cit-ec.uni-bielefeld.de/lexica/manuell/dbpedia#>.
@prefix : <http://sc.cit-ec.uni-bielefeld.de/lexica/manuell/dbpedia#>.

:lexicon a lemon:Lexicon ;
    lemon:language "en" ;
    lemon:entry :Surfer,
                :team,
                :playFor,
                :player,
                :raceFor,
                :manage,
                :manager,
                :in,
                :elevation, 
                :height,
                :high,
                :tall, 
                :bornIn .



## Person with profession Surfing ##

:Surfer a lemon:Lexicalentry ;
  lemon:canonicalForm [ lemon:writtenRep "surfer"@en ] ;
  lemon:sense [ lemon:subsense [ lemon:reference <http://dbpedia.org/ontology/Person> ;
                                 lemon:isA :arg_surfer ; ] ,
                               [ lemon:reference <http://dbpedia.org/ontology/profession> ;
                                 lemon:subjOfProp :arg_surfer ;
                                 lemon:objOfProp <http://dbpedia.org/resource/Surfing> ] ] ;
  lexinfo:partOfSpeech lexinfo:noun .


## team ##

:team a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "team"@en ; 
                        isocat:DC-1298 isocat:DC-1387 ] ;
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/team> ;
                lemon:subjOfProp :arg1team ;
                lemon:objOfProp  :arg2team ] ;
  lemon:synBehavior [ rdf:type lexinfo:NounPossessiveFrame ;
                      lexinfo:copulativeArg     :arg2team ;  
                      lexinfo:possessiveAdjunct :arg1team ] ;
  lexinfo:partOfSpeech lexinfo:noun .

:playFor a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "play"@en ] ;
  lemon:synBehavior [ rdf:type lexinfo:IntransitivePPFrame ;
		      lexinfo:subject :arg1playFor ;
                      lexinfo:prepositionalObject :arg2playFor ] ;
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/team>;
                lemon:subjOfProp :arg1playFor;
                lemon:objOfProp  :arg2playFor;
                lemon:propertyDomain [ owl:unionOf ( <http://dbpedia.org/ontology/SoccerPlayer>
                                                     <http://dbpedia.org/ontology/BasketballPlayer>
                                                     <http://dbpedia.org/ontology/BaseballPlayer>
                                                     <http://dbpedia.org/ontology/IcehockeyPlayer> ) ] ] ;
  lexinfo:partOfSpeech lexinfo:verb .
:arg2playFor lemon:marker :for .

:player a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "player"@en ] ;
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/team> ;
                lemon:subjOfProp :arg1player ;
                lemon:objOfProp  :arg2player ; 
                lemon:propertyDomain [ owl:unionOf ( <http://dbpedia.org/ontology/SoccerPlayer>
                                                     <http://dbpedia.org/ontology/BasketballPlayer>
                                                     <http://dbpedia.org/ontology/BaseballPlayer>
                                                     <http://dbpedia.org/ontology/IcehockeyPlayer> ) ] ] ;
  lemon:synBehavior [ rdf:type lexinfo:NounPPFrame ;
                      lexinfo:copulativeArg :arg1player ;  
                      lexinfo:prepositionalAdjunct :arg2player ] ;
  lexinfo:partOfSpeech lexinfo:noun .
:arg2player lemon:marker :of .

:raceFor a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "race"@en ] ;
  lemon:synBehavior [ rdf:type lexinfo:IntransitivePPFrame ;
		      lexinfo:subject :arg1raceFor ;
                      lexinfo:prepositionalObject :arg2raceFor ] ;
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/team>;
                lemon:subjOfProp :arg1raceFor;
                lemon:objOfProp  :arg2raceFor;
                lemon:propertyDomain [ owl:unionOf ( <http://dbpedia.org/ontology/Cyclist>
                                                     <http://dbpedia.org/ontology/RaceDriver> ) ] ] ;
  lexinfo:partOfSpeech lexinfo:verb .
:arg2raceFor lemon:marker :for .

:manager a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "manager"@en ; 
                        isocat:DC-1298 isocat:DC-1387 ] ;
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/team> ;
                lemon:subjOfProp :arg1manager ;
                lemon:objOfProp  :arg2manager ; 
                lemon:propertyDomain <http://dbpedia.org/ontology/SportsManager> ] ;
  lemon:synBehavior [ rdf:type lexinfo:NounPossessiveFrame ;
                      lexinfo:copulativeArg :arg1manager ;  
                      lexinfo:possessiveAdjunct :arg2manager ] ;
  lexinfo:partOfSpeech lexinfo:noun .

:manage a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "manage"@en ] ;
  lemon:synBehavior [ rdf:type lexinfo:TransitiveFrame ;
		      lexinfo:subject      :arg1manage ;
                      lexinfo:directObject :arg2manage ] ;
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/team>;
                lemon:subjOfProp :arg1manage;
                lemon:objOfProp  :arg2manage;
                lemon:propertyDomain <http://dbpedia.org/ontology/SportsManager> ] ;
  lexinfo:partOfSpeech lexinfo:verb .


## country, range, city, location ##

:in a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "in"@en ] ;
  lemon:synBehavior [ rdf:type lexinfo:PrepositionFrame ;
                      lexinfo:copulativeSubject    :arg1in;
                      lexinfo:prepositionalAdjunct :arg2in ];
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/country>;
                lemon:subjOfProp :arg1in;
                lemon:objOfProp  :arg2in ] ,
              [ lemon:reference <http://dbpedia.org/ontology/range>;
                lemon:subjOfProp :arg1in;
                lemon:objOfProp  :arg2in ] ,
              [ lemon:reference <http://dbpedia.org/ontology/city>;
                lemon:subjOfProp :arg1in;
                lemon:objOfProp  :arg2in ] ,
              [ lemon:reference <http://dbpedia.org/ontology/location>;
                lemon:subjOfProp :arg1in;
                lemon:objOfProp  :arg2in ] ;
  lexinfo:partOfSpeech lexinfo:preposition .


## elevation, height ##

:elevation a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "elevation"@en ] ;
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/elevation> ;
                lemon:subjOfProp :arg1elevation ;
                lemon:objOfProp  :arg2elevation ] ;
  lemon:synBehavior [ rdf:type lexinfo:NounPossessiveFrame ;
                      lexinfo:copulativeArg :arg2elevation ;
                      lexinfo:possessiveAdjunct :arg1elevation ] ;
  lexinfo:partOfSpeech lexinfo:noun .

:height a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "height"@en ] ;
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/elevation> ;
                lemon:subjOfProp :arg1height ;
                lemon:objOfProp  :arg2height ;
                lemon:propertyDomain <http://dbpedia.org/ontology/Place> ] ,
              [ lemon:reference <http://dbpedia.org/ontology/height> ;
                lemon:subjOfProp :arg1height ;
                lemon:objOfProp  :arg2height ;
                lemon:propertyDomain <http://dbpedia.org/ontology/Person> ] ;
  lemon:synBehavior [ rdf:type lexinfo:NounPossessiveFrame ;
                      lexinfo:copulativeArg :arg2height ;
                      lexinfo:possessiveAdjunct :arg1height ] ;
  lexinfo:partOfSpeech lexinfo:noun .

:high a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "high"@en ] ;
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/elevation> ;
                lemon:subjOfProp :arg1high ;
                lemon:objOfProp  :arg2high ] ;
  lemon:synBehavior [ rdf:type lexinfo:AdjectivePredicateFrame ;
                      lexinfo:copulativeSubject :arg1high ;
                      lexinfo:attributiveArg :arg1high ] ;
  lexinfo:partOfSpeech lexinfo:adjective .

:tall a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "tall"@en ] ;
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/elevation> ;
                lemon:subjOfProp :arg1tall ;
                lemon:objOfProp  :arg2tall ;
                lemon:propertyDomain <http://dbpedia.org/ontology/Place> ] ,
              [ lemon:reference <http://dbpedia.org/ontology/height> ;
                lemon:subjOfProp :arg1tall ;
                lemon:objOfProp  :arg2tall ;
                lemon:propertyDomain <http://dbpedia.org/ontology/Person> ] ;
  lemon:synBehavior [ rdf:type lexinfo:AdjectivePredicateFrame ;
                      lexinfo:copulativeSubject :arg1tall ;
                      lexinfo:attributiveArg :arg1tall ] ;
  lexinfo:partOfSpeech lexinfo:adjective .


## birthYear, birthPlace ##

:bornIn a lemon:LexicalEntry ;
  lemon:canonicalForm [ lemon:writtenRep "born"@en ] ;
  lemon:synBehavior [ rdf:type lexinfo:AdjectivePPFrame ;
                      lexinfo:copulativeSubject    :arg1bornIn;
                      lexinfo:prepositionalAdjunct :arg2bornIn ];
  lemon:sense [ lemon:reference <http://dbpedia.org/ontology/birthYear>;
                lemon:subjOfProp :arg1bornIn;
                lemon:objOfProp  :arg2bornIn ] ,
              [ lemon:reference <http://dbpedia.org/ontology/birthPlace>;
                lemon:subjOfProp :arg1bornIn;
                lemon:objOfProp  :arg2bornIn ] ,
              [ lemon:reference [ owl:propertyChain ( <http://dbpedia.org/ontology/birthPlace> <http://dbpedia.org/ontology/country> ) ] ;
                lemon:subjOfProp :arg1bornIn;
                lemon:objOfProp  :arg2bornIn ] ;
  lexinfo:partOfSpeech lexinfo:adjective .
:arg2bornIn lemon:marker [ lemon:canonicalForm [ lemon:writtenRep "in"@en ] ] .


#### Marker ####

:of  lemon:canonicalForm [ lemon:writtenRep "of"@en ] .
:for lemon:canonicalForm [ lemon:writtenRep "for"@en ] .

</pre>

= Need for an object between Lexical Entry and Ontology =

Naively we could just map lexical entries directly to ontology elements with a link, e.g.,

  lexicon:Cat-noun-entry ontolex:means ontology:cat .

This object is not necessary for polysemy

  lexicon:Cat-noun-entyr ontolex:means ontology:cat_(Domestic Animal) , ontology:Computer_Aided_Tomography .
 
There are a few issues that quickly arise, for example, for example the informal term "puss"

  lexicon:Puss-noun-entry ontolex:means ontology:cat ;
     ontolex:register ontolex:informal .

Is unsuitable as it suggest that the noun "puss" is informal for all meanings (not true, see http://en.wiktionary.org/wiki/puss), even worse mapping would be

  lexicon:Puss-noun-entry ontolex:means ontology:cat .
     dbpedia:cat ontolex:register ontolex:informal .

Would lead to counting "cat" as also informal. For this reason both Lemon and Senso Comune introduced an intermediate object (see http://www.loa.istc.cnr.it/Papers/lexicon_oltramari-vetere.pdf), called a Lexical Sense (lemon) or Acceptation/Meaning (Senso Comune). Which can then be linked to the ontology. Assuming there is no disagreement, can I propose the following structure for mapping, with an intermediate object

  lexicon:Puss-noun-entry ontolex:sense lexicon:Puss-noun-sense1 .
  lexicon:Puss-noun-sense1 ontolex:refersTo ontology:cat ,
     ontolex:register ontolex:informal .

We should also consider how to name this object, to clarify its role:

* (Lexical) Sense
* Meaning
* Acceptation
* Sememe

=== In Senso Comune ===
[http://www.sensocomune.it Senso Comune] makes a distinction between Acceptation (information in a dictionary) and Meaning (social object). Meanings are classified w.r.t. a set of (few) ontological categories (i.e. categories of real world entities).

Example:

 Cat type LexicalEntry, Cat_1 type Acceptation, accept (Cat_1,Cat), POS(Cat_1,NOUN), glossa(Cat_1, "small domestic feline"), meaning (Cat_1,Cat_meaning), 
 Cat_meaning subclass (Meaning  AND characterizes ONLY Animal)  

Note the use of Cat_meaning as a class name and a value for the attribute 'meaning' (punning).

This model gives Senso Comune the following featutes:
*Allows integration of different lexicographic sources ('acceptations' of a given source may require specific attributes, such as usage marks, etc, which are not appropriate for the corresponding acceptations in different sources);
*Keeps ontology (as a theory of real world entities) clearly separated from linguistic senses (e.g. synonymy does not interfere with class equivalence). 
*Handles linguistic vagueness and facilitates semantic integration.

For example, the adjective 'bald' in the sense of 'lacking hairs' may be encoded as: 

 Bald type LexicalEntry, Bald_1 type Acceptation, accept(Bald_1,Bald), POS(Bald_1,ADJ), glossa(Bald1,"having a scalp wholly or partly lacking hair"),
 meaning (Bald_1, Bald_meaning)), Bald_meaning subclass Meaning AND characterizes ONLY Human.   

In this example, Senso Comune provides the adjective 'bald' with a semantic specification which does not commit to the existence of 'bald things' in the world (but only humans).

= Interpreting mappings =

What does it mean to say that a "lexical entry means an ontology entity"

In particular there are at least the following cases:

* Names/proper nouns: e.g., "Microsoft", "The EU". Names refer to individuals within the ontology
* Class noun and adjectives: e.g., "cat", "British". Most nouns and some adjectives refer to a class within the ontology. A determiner is used in many languages to indicate whether the reference is to the class itself, e.g., "Cats feature in all my examples", or a member of this class, e.g., "Felix is a cat".
* Abstract nouns: e.g., "disagreement", what should they map to in the ontology?
* Stative verbs: e.g., "knows", "requires". Map to properties or (very rarely) complexes (ontology design patterns) over multiple properties.
* Dynamic verbs: e.g., "run", "hit". Possibly map to some ''event'' ontology design pattern??
* Intersective adjectives: e.g., "Belgian". (X is JJ NN |= X is JJ and X is NN)
* Property-modifying adjectives: e.g., "former". (Exists P : X is JJ NN |=  P(X,NN))
* Scalar adjectives: e.g., "big". These relate to a dimension (e.g., "size" for "big")... unclear how to model in ontology
* Adverbs: Should follow adjective but modify the objects of dynamic verbs.

How to model these?

= Form-dependent meaning =

Some words, for each "wares", have a sense that is constructed only by a single form of the word and  in Italian 'acqua' (water) and 'acque' (thermal treatments).

= What meaning can be modelled?  =

1. Is there any semantic aspect of a word sense (I prefer lexical unit) that cannot be represented in an ontological model?

It may not be easy but I think you can, if you allow semantics in the ontology that incorporates probabilities and prototypicality. 
I think that any formalization of lexical meaning can be turned into an ontological meaning, simply because it is a formalization.
if it is not a formalization then the lexical meaning is ill-defined and we need to do more (empirical) work to learn about the word and its usage.


2. Do you want to model any semantic aspect that characterizes a word sense also in the ontology?

This is another question. If we want to model pure logical reasoning, there may be many lexical aspects (not just the pragmatic knowledge) that we do not need
in the ontology. We do not need to represent “buy” and “sell” separately to reason over de financial transaction process.


3. What do we do with the situations that lexicons are far more richer than any ontology available and thus we cannot provide sufficient ontological labels to model the lexicons.

This is a more practical and pragmatic question. If the lexicon is so large, complex and rich, why not use a two-layered solution where lexical relations take the burden off the ontology and the ontology takes the burden of deeper reasoning (need to define how deep we need to go). So in the lexicon, I can say that one word is the informal word for “eat” and another word is the neutral label for “eat”. In the ontology, we just have “eat”. Many lexicalized concepts are either pragmatic variants or can be defined using intersecting
properties as described by Philipp for “bald”.

= Features for lexicon =

# dialect, age-group, formal, informal registers, etc.... 
#* probably not in OWL
# relations between different meanings (polysemy relations) such a specialization, generalization, metonymy, metaphor -> 
#* probably not in OWL
# morphological properties (including, tense, gender, number, etc., diminutives and other derived forms, aspects)
#* probably not in OWL
# pronunciation
#* probably not in OWL
# syntax:
#* probably not in OWL but: verb syntax needs to be mapped to argument structure and argument structure map to event structure in the ontology: buy and sell are variants with different syntactic mappings to the same event structure. Other examples are “teach” and “learn” (in some languages expressed by the same verb).
#* Same for countability which is partially semantic and partially a form choice.
# collocational contraints, e.g. blow your nose and clear your throat
#* probably not in OWL
# probability of packaging: complex concepts are phrased typically as e.g. adjective noun, compound, prepositional phrase, verb phrase, etc..
#* probably not in OWL
# subjectivity relations and connotations
#* partly this can be in the ontology reflected in the form of a social role but it is (usually) not done
# social roles
#* this is a border case: it can and probably should be reflected in the ontology but it is extremely rich  and complex
# some others: gender in many languages, politeness markers, aspectual properties....

= Type A and Type B Modelling =

There are two types of conceptual models:

A) purely intensional conceptual models, like SKOS models, classification schemes, thesauri, synsets, lexical frames, etc.
B) formally interpreted conceptual models, like ontologies, ER schemas, UML class diagrams (under ER-like semantics), etc.

= Key Issues =

== 2-triple path ==

=== Do we have a 2-triple path? ===

For:
*  It's obviously needed, either for making room for lexical senses (definitely to be distinguished from ontology entities), or to be able to talk about senses (reifications of the meaning function) (AG)
*  Model linguistic senses as a class of socially constructed abstractions evoked in linguistic acts, which mediate between 'expressions' (e.g. word labels) and 'real entities' (e.g. ontology concepts) (GV)
* If the LLD use case is valid, then we necessarily need that Sense element, and in case, we should find space for connecting it to ontology entities! (AS)
Against:
* Shouldn’t care if there’s “something about the meaning of a word that we cannot represent with an ontology model” (AS)
* If we want to reuse explicitly these resources, we need to address their semantic layer (AS)

=== Taxonomy of synsets ===

For:
* Synsets are not lexical senses (AG)
* Sense is too much constraining what we could put here

=== Naming of the "lexical entry" ===

Proposals:
* Lexical Entry
** + Continuity with lemon, LexInfo, LIR, LMF (JMc)
* Lexical Unit
** + An entry exists somewhere, and an object may appear as an entry in more “wheres” (AS)
** - Unit not appropriate as may be a term (JMc)
* Lemma
** - Not appropriate as may be a term
* Term
** - Not appropriate as may be a lemma

=== Naming of property between "lexical entry" and "sense" ===

Proposals:
* sense 
** + Continuity with lemon (JMc)
* meaning/means
** 

=== Naming of "sense" ===

Proposals:
* Lexical Sense
** + Continuity with lemon (JMc)
** + Doesn't clash if property is sense (JMc)
* Sense
** + Can be profitably (and yes, ambiguously) figured out as any conceptualization associated with a lexical entry
** - sense evokes the idea of a relationship (AS)
* Meaning
** + Easily understandable to laypeople (JMc)
* Sememe
** - it seems not appropriate (it is atomic) (AS)
** + It fits well because it is atomic (JMc)
** + Avoids preconceptions of other models (JMc)
** - Too technical for lay people (PC, AS)
* Semantic Unit
** + very abstract (no baggage) (AS)
** - Synonym of Sememe (JMc)
* Acceptation
** + Continuity with Senso Comune (GV)
** - Very technical (lexicography) and pretty unknown as [http://www.thefreedictionary.com/acceptation English word]. 
** Consider that Senso Comune makes a distinction between sense-in-a-dictionary (acceptation: information object) and sense-in-a-culture (meaning: social object)

=== Naming of property between "sense" and ontology ===

Proposals:
* Represented By/Represents
** -  if read from left to right (a sense is represented by a concept), could be misleading. In the mainstream of western semiotics, signs represent things and stand for them (aliquid pro aliquo), not the other way around (GV)
** - 'class vs instance' ('intensional' vs 'extensional' readings) is part of the systematic polysemy for many senses, the model could be in conflict with the intuition that cat#1 may in many cases refer to cats in general (AG via GV). 
** + ontology entities are firstly constants from a vocabulary, then they actually 'represent' senses. Secondly, ontology entities are meanings, but only because they have an extensional interpretation of those constants (AG)
** + meaning of a lexical entry e can be best represented by a symbol (constant) in the vocabulary of a given ontology (PC)
* Has Ontology Entity
** + The triple becomes very clear (AG)
** - 'has' is far too generic (GV)
* Reference
** + Continuity with lemon (JMc)
** + hasReference is also a good name, because it catches the extensional interpretation aspect of ontology entities (reference to a set-theoretical entity) (AG)
** - does not convey a relational flavor (GV)
* Characterizes
** + Continuity with Senso Comune (JMc)
** - Recalls a math notion, not attested in linguistic literature
* Refers To
** + Continuity with classic semiotics (GV)
** - Biased by a realistic view of ontology elements (AG)

== 1-triple path ==

=== In addition to two triple path ===

For:
* Property chain in the model, which helps resolving the indirection produced by the Sense class (AG)
* Good practice (a logical design pattern), used in many contexts (AG)
* Facilitates the use of the model for those reluctant to catch on the sense-ontology-entity distinction
Against:
* Reduces cognitive complexity for only (likely) a minority of users (JMc)
* Increase in cognitive complexity for majority of users (JMc)
* Requires mechanisms such as SPARQL 1.1 and DL Reasoners (AG)
* From personal experience, actually difficult to implement and unintuitive in mutable models (e.g., removeMeaning must remove all senses) (JMc)