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

Re: Issues about the semantics of the ontology-lexicon interface [was: Re: Why not to shortcut the "sense" object]

From: Guido Vetere <gvetere@it.ibm.com>
Date: Tue, 23 Oct 2012 14:55:26 +0200
To: public-ontolex@w3.org
Message-ID: <OF6A85A613.012E98CC-ONC1257AA0.0046419D-C1257AA0.0047019B@it.ibm.com>
Philipp,

you are right, but I don't think that there it would make sense to have 
senses referring to Nothing (i.e. the Absurd). Maybe we could have senses 
whose referent is unknown, but this would be a normal case of 
incompleteness. 

As for your difficult question, it is difficult indeed! :-)

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 (0)6 59662137                 +39 (0)461 312312

Mobile: +39 3357454658
_________________________________________________



Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de> 
23/10/2012 13:55

To
public-ontolex@w3.org
cc

Subject
Re: Issues about the semantics of the ontology-lexicon interface    [was: 
Re: Why   not to shortcut the "sense" object]






Hi Guido,

      thanks for the very clear exposition. What you say makes actually a 
lot of sense.

In essence, you are saying: Using a constant as range of the referTo 
problem is problematic because it prevents joint reasoning over lexicon 
and ontology. And you give an example in which one would like to infer 
subsumption relations between senses on the basis of ontological knowledge 
about the classes they refer to. 

On the other hand, if I am not mistaken, M2 creates problems if I want to 
retrieve all lexicalizations of a given concept. It would require 
subsumption reasoning, i.e. if I would like to know all possible ways to 
lexicalize the concept "cat", I would have to retrieve all the "senses" 
that fullfill the concept Sense AND refersTo ONLY Cat. By which I would 
also get back all Sense that refer to nothing. Dangerous ;-)

So maybe we should then retrieve all sense that satisfy the concept Sense 
AND refersTo ONLY Cat AND exists refersTo.Top

It seems quite complicated to me to do this just to retrieve the 
lexicalizations of a concept. Allthough, one could hide this behind 
appropriate APIs etc. 

So it seems that in M2, it is easy to retrieve all lexical entries that 
satisfy a certain semantic property. While in M1 it is easy to retrieve 
all sense or lexicalizations of a given concept, would you agree?

Best regards,

Philipp.



Am 23.10.12 12:19, schrieb Guido Vetere: 
Philipp, 

sorry for being late and maybe too short on this. 

Let's consider this use case: 

A user has a lexical resource L that she wants to link with a pre-existing 
ontology O. The lexical resource L doesn't specify meronymy, while the 
ontology O has contains the role 'part'. According to the model (the one 
we outlined so far), the user introduces an instance of Sense for each 
definition in L, then for each sense in L she finds one or more 
corresponding concept in O, and put them into a relationship (let's call 
it 'referTo' and let's keep it logically opaque for now) with the sense. 

The user wants to retrieve all the senses s in L related to the parts of a 
given class c in O, e.g. all the nouns corresponding to parts of 
'aircraft' ('fuselage','wings', etc). In other words, the user wants to 
exploit the information encoded in the ontology to infer a 'semantic 
field' relative to a lexicon. 

Let's specify two different models: 

M1) Senses are instances of the class Semse, and 'referTo' is an object 
property that has domain in Sense and ranges on URIs corresponding to 
class names in O. 
With such a model, the use case this could be done in two separate steps: 
1) retrieve all the classes whose instances may fill the the relationship 
'part_of' with domain restricted to 'aircraft', then 2) use the list of 
retrieved classes to build a union of conjunctive queries over senses in 
L. Note that 1) would be a second order query; specifically, is a query 
over properties and their restrictions, which would require an approach 
like those described in: De Giacomo, Lenzerini, Rosati: On Higher-Order 
Description Logics. 

M2) Senses are subclasses of Sense, and 'referTo' is a standard first 
order property. Sense-ontology mapping is encoded in structures like: 
        Sense_class ISA Sense AND refersTo ONLY [OntologyClass]. 
Now suppose that the ontology contains: 
        Fuselage ISA part_of only Aircraft; Wing ISA part_of only 
Aircraft; 
And suppose you map your senses like this: 
        Fuselage_sense_1 ISA Sense AND referTo ONLY Fuselage; Wing_sense_1 
ISA Sense AND referTo ONLY Wing; 

You can now define a class 
        Aircraft_sense ISA Sense AND referTo ONLY part_of Aircraft 

Observe that Fuselage_sense_1 and Wing_sense_1 could be automatically 
classified as Aircraft_sense by any standard DL reasoner. 

Hope that this is correct (sorry for not checking before) and helps this 
discussion. 

Regards, 

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 (0)6 59662137                 +39 (0)461 312312

Mobile: +39 3357454658
_________________________________________________ 


Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de> 
19/10/2012 17:09 


To
public-ontolex@w3.org 
cc

Subject
Re: Issues about the semantics of the ontology-lexicon interface   [was: 
Re: Why  not to shortcut the "sense" object]








Guido, all,

 I am not saying it is a final decision, but my proposal is indeed to 
refer to classes and other ontological entities as signs.
As you say, this prevents joint reasoning over lexicon and ontology. 

It would help if you would give concrete examples where this would be 
needed.

Best regards,

Philipp.


Am 17.10.12 10:33, schrieb Guido Vetere: 
Aldo, 
you are right, we cannot discuss philosophical matters here, but on the 
other hand I see basic questions that may have a deep impact on the 
technical soundness of the proposal. For instance, it looks like you see 
ontologies as 'constants from a vocabulary' while I think that 
vocabularies are made of lexical entries + senses, while ontologies are 
theories of what exists. I don't want to start a discussion on 
constructivism vs critical realism here, but for sure we have to choose 
one of the three options: 1) implement a vision like yours, 2) implement a 
vision like mine, 3) implement something that accommodates both. 

Philipp, 
if the final decision is to have signs referring to class names that's 
fine, but still I think that we need to explicit different possible formal 
semantics that people (e.g. resource developers and users) can attach to 
the relation in question, e.g. to support scenarios in which reasoning on 
the correspondence between ontological disjunctions and antonymy of senses 
is needed. 

Cheers, 

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 (0)6 59662137                 +39 (0)461 312312

Mobile: +39 3357454658
_________________________________________________ 

Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de> 
15/10/2012 18:58 


To
public-ontolex@w3.org 
cc

Subject
Re: Issues about the semantics of the ontology-lexicon interface  [was: 
Re: Why not to shortcut the "sense" object]










Dear all,

my understanding is completely in line with what Aldo is saying here. The 
"OntologyEntity" should be seen as a plain constant that "represents" the 
intension in question.

The nice thing is that one can manipulate this constant independent of its 
ontological commitment. This is in line with what Aldo is saying below. So 
punning is not only a syntactic trick, but a principled strategy to refer 
to the symbol that represents a certain ontological commitment.

I attach a short document that I have just created. I am not sure this 
will introduce more confusion. I hope not. I will elaborate this in more 
detail later, but I wanted to provide this for the current thread of 
discussion as quickly as possible. 

I think it is in line with Aldo's position. Aldo?

Philipp.

Am 15.10.12 18:28, schrieb Aldo Gangemi: 
Thx Guido, this discussion is very useful (provided that we do not get 
into the infamous "sumo-threads" where each discussion used to get 
eventually to discussing the nature of matter and life :)). 

On Oct 15, 2012, at 2:37 PM, Guido Vetere <gvetere@it.ibm.com> wrote: 

Aldo, Armando, 

A couple of things about what you said (on the rest, I generally agree). 

As for the name of the arrow (property?) linking senses and concepts, Aldo 
is right, maybe 'characterize' is not appropriate in this context (indeed, 
the notion comes from mathematics) and is not likely to be accepted by the 
community. But 'representedBy', if read from left to right (a sense is 
represented by a concept), could be even worse, since, in the mainstream 
of western semiotics, signs represent things and stand for them (aliquid 
pro aliquo), and not the other way around. Maybe we could adopt the 
classic (e.g. Odgen-Richard) 'refers to', even if the binding with the 
'referential function' may be inappropriate. It looks like a trivial 
naming detail, but it may have an impact on the way people grasp the 
intended meaning of the model. 

The reason why I like "representedBy", despite its generic ambiguity, is 
that I see ontology entities firstly as constants from a vocabulary. As 
constants, they can perfectly "represent" senses. Indeed, this is quite 
inline even with formal ontology and logic (cf. Nicola Guarino's 2003 
paper on conceptualizations). 
Of course, constants of a vocabulary get a *formal* meaning/interpretation 
that is based on model theory, but this is another story, which gives us 
room to claim that lexical entries can have a (formal) semantics with 
ontology entities. 
In other words, the way the ontology-lexicon interface works seems to be 
the following: 

- a lexical entry has some sense (either local or general/conventional), 
which we can call "lexical meaning" 
- a sense can get ("be represented by", or "be expressed by") a constant 
(ontology entity) in a formal vocabulary 
- that constant has a formal interpretation provided by logical and domain 
axioms: this is a "formal meaning" 

Unfortunately, logicians have substantially identified intension (which is 
the closest relative to lexical meaning) with the constants of a 
vocabulary. Therefore, the only original, operational, and useful semantic 
stuff that we have from logical models is extensional meaning. But we are 
not going to talk about that as well, right? ;). Since we are not doing 
that, ontology entities from OWL/RDF will be inevitably ambiguous, and 
depending on context, sometimes they can be considered as constants, and 
sometimes as meanings. 


This leads to the more basic question about the logic nature of this 
relation, i.e. of what kind of logical things fill the pattern: Lexical 
unit --meaning--> Sense --refers to--> Ontological concept. If we give 
this graph a DL interpretation, as I tried to do, nodes could be first 
order unary predicates and arrows (restricted) first order binary 
predicates. In this reading, instances of Sense (e.g. cat#1) would be 
related to instances of Concepts (e.g. my cat). Aldo suggests that this 
model would be in conflict with the intuition that cat#1 may in many cases 
refer to cats in general, i.e. the whole class of cats. However, 'class vs 
instance' ('intensional' vs 'extensional', if you whish) is part of the 
systematic polysemy for many senses, if not for senses in general. 
Dictionary developers might want to use the same sense of 'cat' both for 
'the cat is on the mat' and 'the cat is a feline'. Now, it is true that an 
axiom of the form cat#1 TYPE (Sense AND refersTo ONLY Cat) would not 
capture the intensional reading of the sense, but, conversely, setting 
'refers to' to range on class names, as Aldo suggests, would not capture 
the extensional one. 

Maybe there is a misunderstanding here. When I read your "cat#1" I'm 
interpreting it as a sense of the word "cat", not as a particular cat. 
Now, if I interpret you right, cat#1 would be a Sense that is represented 
by some OntologyEntity. 
On the contrary, if you mean a particular cat, I'm not following you 
anymore: why a cat should be a Sense? 


In general, using class names as values for the property in question, e.g. 
by using OWL 2 punning, raises the question of providing the property with 
some extra formal semantics, since punning, as you know, is just a 
syntactic trick. As Aldo says, problems like this have been tackled by 
other specifications already, such as SKOS.  However, we here face the 
problem of dealing with any legacy ontology, which rely on standard 
set-theoretic semantics, instead of 'ad hoc' conceptual frameworks. Thus, 
we should come up with a model that preserves both the intended formal 
meaning of standard ontologies and the complexity of linguistic 
signification, which is not an easy task, and cannot be pursued just by 
naming conventions. 

You're right in general, but I think that this is too much for this 
Community Group: after all, we do not want to solve the harsh problems of 
higher-order logics applied to natural language semantics. 
Anyway, punning is not much a trick (despite its name), but a regular 
logical way of interpreting constants in a theory by partitioning their 
interpretations. The fact that those interpretations do not interact as in 
a rocketing HOL is simply due to the limitations we accept for having a 
Web Ontology Language, which is in addition considered way too expressive 
? 


In my opinion, much depends on what 'Sense' represents in our basic 
pattern. I understand well, this concept is currently associated to either 
definitions in dictionaries or synsets in wordnets, thus being a mostly 
lexicographic notion. A different ontology could model Sense as a class of 
socially constructed abstractions evoked in linguistic acts, independent 
from dictionaries and wordnets. In the former case, Sense could be a leaf 
class, and what we link through arrows are instances. In latter case, I 
think that 'Sense' should rather be the root of a class hierarchy, and 
what we link to lexemes should be Sense's subclasses, whose instances, in 
turn, represent meanings in their textual occurrences.  By the way, Senso 
Comune embraces an ontology like this.  So a good question to start with 
would be: what do we mean when we say 'Sense'? 

My impression is that we cannot (and shouldn't in my opinion) attempt to 
solve that kind of issues; on the contrary, it's very useful to abstract 
out of them. 
A sense can be profitably (and yes, ambiguously) figured out as any 
conceptualization associated with a lexical entry, be it an entry, a 
definition/gloss, an ID, a paraphrase, a reference to some other 
disambiguating source, or even (please do not shoot me) formal meanings 
and cognitive objects studied by neurolinguistics. 
In the particular community of linked data and the semantic web, we can 
refrain from discussing too much what a sense is, and begin to see how 
interesting are the links emerging out of those apparently different 
creatures. 

Ciao 
Aldo 


Cheers, 

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 (0)6 59662137                 +39 (0)461 312312

Mobile: +39 3357454658
_________________________________________________ 
Aldo Gangemi <aldo.gangemi@cnr.it> 
13/10/2012 14:40 


To
public-ontolex <public-ontolex@w3.org> 
cc
Aldo Gangemi <aldo.gangemi@cnr.it>, John McCrae <
jmccrae@cit-ec.uni-bielefeld.de>, Armando Stellato <
stellato@info.uniroma2.it>, Guido Vetere/Italy/IBM@IBMIT, Philipp Cimiano 
<cimiano@cit-ec.uni-bielefeld.de> 
Subject
Issues about the semantics of the ontology-lexicon interface [was: Re: Why 
not to shortcut the "sense" object]












Hi all, I lagged behind in the last month, because of my recent 
installation in Paris. Yesterday I was traveling back from Galway (EKAW) 
and couldn't attend, apologies for that. 
I have followed the recent discussion, and that's my contribution. I have 
renamed the thread, because it is now spanning over different topics 
related to the semantics ig the O-L interface. 

---Senses--- 
Concerning Philipp's summary, firstly I agree with the decision (?not yet 
approved, it seems?) of creating the intermediate Sense class: 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). 
Concerning the name, I vote for "sense", because sememes, acceptations, 
and others, are either very technical for the layman, or even wrong, as 
Philipp reminds us about the original notion of sememe. The only real 
alternative would be "meaning", but I'd rather keep that term for the 
top-level class of a meaning taxonomy, as I suggest in the following. 

In a previous mail, I proposed to consider also an additional solution, 
i.e. to create a taxonomy of meanings, which has ontology entities (as 
formal semantic objects) and lexical senses as special subclasses. The two 
solutions are compatible, and if we realize that a meaning taxonomy might 
be useful, it can be introduced anyway. 
Think of the sense-synset issue raised by Philipp: I agree that synsets 
are not lexical senses, if we assume that a lexical sense should be 
expressed by only one lexical unit (cardinality exactly 1), but still they 
are senses, and it's completely reasonable to put synsets (as well as many 
other creatures of lexical semantics, including sememes, acceptations, 
frames, semantic verb classes, etc.) in a meaning taxonomy. 

Concerning the property names, I'm ok with both LexicalEntry ? meaning ?> 
Sense, and with Sense ? representedBy ?> OntologyEntity. 
Maybe we could get rid of multiple related uses of the "mean" notion, 
which can be somehow disturbing: Meaning as a class, meaning as a property 
between lexical entries and senses, means as a property between lexical 
entries and ontology entities ? it may look like we are playing with words 
? what about following the conventional naming patterns that employs the 
name of the property range? E.g. LexicalEntry ? sense ?> Sense ; 
LexicalEntry ? meansOntologyEntity ?> OntologyEntity. The advantage of 
using this apparently redundant naming is that at the instance level, the 
triple become very clear, e.g. Saxophone ? sense ?> wordsense-saxophone-1 
; Saxophone ? hasOntologyEntity ?> music:Saxophone. 
I also prefer "representedBy" to "characterizes", because the second is 
very generic and not attested in any related literature. 

---Property chaining over senses--- 
Secondly, I agree with the decision to add a property chain in the model, 
which helps resolving the indirection produced by the Sense class: this is 
a good practice (a logical design pattern), used in many contexts. I do 
not see room for John's criticism about it: it does not increase the 
cognitive complexity (on the contrary, it facilitates the use of the model 
for those reluctant to catch on the sense-ontology-entity distinction), 
and the added computational complexity only holds when a DL reasoner 
materializes the ABox. 
One mild problem here might be that we are making slightly different 
assumptions when we name "representedBy" the property between senses and 
ontology entities, but "means" the property between lexical entries and 
ontology entities. Since we do not have a rich axiomatization behind these 
names, we might be pragmatic and ignore the problem, however I deem 
important to justify it a little bit in the documentation. In practice, 
this approach seems to suggest that senses are actually "represented" by 
ontology entities, and this is clear and intuitive. It also suggests that 
lexical entries actually "mean" ontology entities, but this is far less 
clear and intuitive, since in no obvious way words mean stuff in 
ontologies ? it's much better to say that words have conceptualizations 
that are represented in ontologies. Indeed this is the way we talk of 
lexical senses :). That's why my above suggestion was "hasOntologyEntity", 
which however I admit ti be too generic. In principle, the compositional 
name that best fits the property chain would be 
"hasSenseRepresentedByOntologyEntity", but it's way too long, specially 
for those willing to use that property as a shortcut. Other suggestions? 

---GCIs on ontology hierarchies--- 
Finally, a comment about Guido's observation that "cat#1 INSTANCEOF (Sense 
AND characterizes ONLY Animal)" is the right formalization for an example 
of the representedBy object property values. If I understand well, here we 
have two important issues. The first one can be solved by using OWL2, the 
second poses a more difficult challenge. 
For the first issue, I think that Guido talks about OWL1, but anyway that 
axiom would give us a misinterpretation, because it would tell us that 
cat#1 is a sense that can only be represented by *individuals* from the 
class Animal, which is not what Guido wants I guess. This problem was 
described in detail by W3C SWBPD committee in 2004, and eventually some 
OWL1 solutions were recommended in the "Classes as values" design pattern. 
However, in OWL2 (lucky us) punning makes our lives easier, and a simple 
(partial!) solution is (in Manchester syntax) "cat#1 TYPES (Sense AND 
representedBy VALUE Animal)". 
For the second issue, Guido points out that there are cases in which we 
need to refer to generic subclasses of an ontology entity (if it's a 
class): this cannot be expressed in OWL at all, since we cannot use the 
OWL vocabulary in the position for the domain vocabulary, In other words, 
the following is a wrong axiom even in OWL2: "cat#1 TYPES (Sense AND 
representedBy (subClassOf VALUE Animal)". 
A viable design pattern is to create a property for meaning hierarchies, 
in the vein of skos:broader or wordnet:hypernym, so that we could declare 
e.g.: "cat#1 TYPES (Sense AND representedBy ([skos:broader] VALUE Animal)
". 
However, a property like skos:broader typically applies to concepts, and 
senses would probably be compatible. Much less are ontology entities 
compatible, even though SKOS seems to suggest a loose correspondence 
between concepts and rdfs/owl classes. In particular, we should 
materialize ontology class hierarchies as skos:broader hierarchies in 
order to reason over these constructs. 
Another design pattern might resort to a specialized property, such as 
"broadlyRepresentedBy", e.g.: "cat#1 TYPES (Sense AND broadlyRepresentedBy 
VALUE Animal)". "broadlyRepresentedBy" can be a super property of 
representedBy. Of course, with this second pattern, we would lose the 
sophisticated DL reasoning that one can get with the first. Nonetheless, 
the second seems more practical and simple to apply for different levels 
of expertise. 

Ciao 
Aldo 

_____________________________________ 

Aldo Gangemi 
Senior Researcher 
Semantic Technology Lab (STLab) 
Institute for Cognitive Science and Technology, 
National Research Council (ISTC-CNR) 
Via Nomentana 56, 00161, Roma, Italy 
Tel: +390644161535 
Fax: +390644161513 
aldo.gangemi@cnr.it 
http://www.stlab.istc.cnr.it 
http://www.istc.cnr.it/people/aldo-gangemi 
skype aldogangemi 
okkam ID: http://www.okkam.org/entity/ok200707031186131660596 

On Oct 12, 2012, at 6:55 PM, John McCrae <jmccrae@cit-ec.uni-bielefeld.de> 
wrote: 

On Fri, Oct 12, 2012 at 6:35 PM, Armando Stellato <
stellato@info.uniroma2.it> wrote: 
>From what I got, and hope not to be wrong (it?s useful also for me to 
clarify as I missed a couple of calls on September), OntologyEntity is a 
generic rdf:Resource of one of the main entities in the main vocabularies 
(aka: OWL and SKOS, thus: property, class, individual, skos concept?). 
Another question to John from my side: from your email it seemed to be 
against stating the propertyChain axiom on (means, 
<meaning,representedBy>) implying that the direct Entry ---means--> 
OntologyEntity from "Lexical Entry -> meaning -> Sense -> representedBy -> 
OntologyEntity"  but then the sentence: ?Here the difference is 1 named 
elements vs. 3 named elements, but as stated above, at least half of users 
(data consumers) will have to understand all 4 names...? instilled some 
doubt in my interpretation? 
  
Are you voting against the larger structure as a whole (thus keeping only 
the Entry ---means--> OntologyEntity structure), or against the 
propertyChain axiom? I really got the second, though I?m not even sure how 
adding the p.chain axiom (or not doing it) would change anything for the 
user or consumer. I?m sure I?m missing something, so sorry in advance for 
my potential misinterpretation. 
Sorry it isn't clear: the long chain is TBMK agreed upon (Lexical Entry -> 
meaning -> Sense -> representedBy -> OntologyEntity)*... we are 
questioning whether we need the short chain (Entry ---means--> 
OntologyEntity) as well. I say it is not worth it. 

Regards, 
John 

* or (Word -> sense -> Sememe/Acceptation -> characterizes -> 
rdf:Resource/skos:Concept/owl:Entity) or some combination of these terms. 
  
Have a nice we! 
  
Armando 
  
 
From: Guido Vetere [mailto:gvetere@it.ibm.com] 
Sent: Friday, October 12, 2012 6:08 PM
To: public-ontolex
Subject: Re: Why not to shortcut the "sense" object 
 
All, 

I apologize for missing the call today. Here just some short remark. 

"Entry ---means--> OntologyEntity" means that if you want to predicate on 
the meaning relationship (e.g. to associate some grammatical constraint) 
you have to resort on a meta predicates (e.g. OWL Annotations). 

"Lexical Entry -> meaning -> Sense -> representedBy -> OntologyEntity" 
sounds good, but instead of 'representedBy' I would say 'characterizes' or 
something alike, meaning that a linguistic sense gives a (cultural) shape 
to an entity. Moreover, it is not clear to me (maybe you discussed about 
that) whether OntologyEntity is a first order TOP concept (e.g. equivalent 
to OWL Thing). In this case, note that in order to tell that the instance 
of Sense 'cat#1' (i.e. the first sense of the lemma 'cat') represents an 
Animal, you have to write something like: 

cat#1 INSTANCEOF (Sense AND characterizes ONLY Animal). 

Is it correct? 

If there is something that I can do, please let me know. 

Regards, 

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 (0)6 59662137                 +39 (0)461 312312

Mobile: +39 3357454658
_________________________________________________ 

John McCrae <jmccrae@cit-ec.uni-bielefeld.de> 
Sent by: johnmccrae@gmail.com 
12/10/2012 16:35 


To
public-ontolex <public-ontolex@w3.org> 
cc

Subject
Why not to shortcut the "sense" object
 








Hi all, 

As discussed today in the telco there is a proposal to introduce a 
shortcut replacing "Entry ---sense--> Sense ---representedBy--> 
OntologyEntity" with "Entry ---means--> OntologyEntity", while this is 
theory sounds good, I contend that in practice it is not worth the effort. 
(This is based on practical experience with the lemon model). 
It does not make the model easier to use: It is clear that for data 
producers this proposal simplifies the matter (as less links and URIs are 
required), however for data consumers it complicates the models (as they 
need to understand both methods of linking and be able to infer 
equivalence between the two methods). Thus, if EaseOfUse = (% of 
Consumers) × EaseOfUse(Consumer) + (% of Producers) × EaseOfUse(Producer), 
hence if we assume there will be approx. as many producers as consumer 
then we need only ask is it worth "is the extra effort for the producer 
less than that for the consumer", i.e., "would you rather implement a 
system that infers similarity across multiple representations, or use 
extra links and URIs"? 
It does not make the model easier to understand: While, I understand that 
the sense object is nebulous and difficult per se to understand, I would 
still argue that the clearest measure of how easy to understand a model 
is, is the number of named elements it has (as many users may not need to 
deeply understand the meaning of a sense, but be happy to know that 
"translation", "antonymy" and "register" go there). Here the difference is 
1 named elements vs. 3 named elements, but as stated above, at least half 
of users (data consumers) will have to understand all 4 names... if we 
assume out of the producers 70% do not need to represent senses (and thus 
any associated properties, "translation", "antonymy", "register") then the 
average number of links a user will need to understand is 4 × 0.5 + 3 × 
0.5 × 0.3 + 1 × 0.5 × 0.7 = 2.8... so it makes the model all of 7% easier 
to understand! Worse, this figure is overgenerous as: I expect there to 
more data consumers than producers and I expect at least 50% of users to 
require sense modelling.
Regards, 
John 

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) 



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) 



-- 
Prof. Dr. Philipp Cimiano
Semantic Computing Group
Excellence Cluster - Cognitive Interaction Technology (CITEC)
University of Bielefeld

Phone: +49 521 106 12249
Fax: +49 521 106 12412
Mail: cimiano@cit-ec.uni-bielefeld.de

Room H-127
Morgenbreede 39
33615 Bielefeld[attachment "senses.pdf" 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) 


-- 
Prof. Dr. Philipp Cimiano
Semantic Computing Group
Excellence Cluster - Cognitive Interaction Technology (CITEC)
University of Bielefeld

Phone: +49 521 106 12249
Fax: +49 521 106 12412
Mail: cimiano@cit-ec.uni-bielefeld.de

Room H-127
Morgenbreede 39
33615 Bielefeld 

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) 


-- 
Prof. Dr. Philipp Cimiano
Semantic Computing Group
Excellence Cluster - Cognitive Interaction Technology (CITEC)
University of Bielefeld

Phone: +49 521 106 12249
Fax: +49 521 106 12412
Mail: cimiano@cit-ec.uni-bielefeld.de

Room H-127
Morgenbreede 39
33615 Bielefeld

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 Tuesday, 23 October 2012 12:56:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 10:57:26 UTC