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: Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de>
Date: Wed, 17 Oct 2012 16:06:49 +0200
Message-ID: <507EBB79.2060505@cit-ec.uni-bielefeld.de>
To: public-ontolex@w3.org
Hi John,

  thanks for this summary. This is very valuable for our next 
discussions during the telco.

Cheers,

Philipp.

Am 17.10.12 11:18, schrieb John McCrae:
> Hi all,
>
> I have attempted to collect the main points of the discussion in the 
> Wiki, could you look over the summary and add future points directly 
> in the Wiki
>
> http://www.w3.org/community/ontolex/wiki/Specification_of_Requirements/Lexicon-Ontology-Mapping
>
> Regards,
> John
>
> On Wed, Oct 17, 2012 at 10:33 AM, Guido Vetere <gvetere@it.ibm.com 
> <mailto:gvetere@it.ibm.com>> wrote:
>
>     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 <tel:%2B39%20%280%296%2059662137> +39 (0)461
>     312312 <tel:%2B39%20%280%29461%20312312>
>
>     Mobile: +39 3357454658 <tel:%2B39%203357454658>
>     _________________________________________________
>
>
>     *Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de
>     <mailto:cimiano@cit-ec.uni-bielefeld.de>>*
>
>     15/10/2012 18:58
>
>     	
>     To
>     	public-ontolex@w3.org <mailto: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_
>     <mailto: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 <tel:%2B39%20%280%296%2059662137> +39 (0)461
>     312312 <tel:%2B39%20%280%29461%20312312>
>
>     Mobile: +39 3357454658 <tel:%2B39%203357454658>
>     _________________________________________________
>
>     *Aldo Gangemi <**_aldo.gangemi@cnr.it_*
>     <mailto:aldo.gangemi@cnr.it>*>*
>
>     13/10/2012 14:40
>
>     	
>     To
>     	public-ontolex <_public-ontolex@w3.org_
>     <mailto:public-ontolex@w3.org>>
>     cc
>     	Aldo Gangemi <_aldo.gangemi@cnr.it_
>     <mailto:aldo.gangemi@cnr.it>>, John McCrae
>     <_jmccrae@cit-ec.uni-bielefeld.de_
>     <mailto:jmccrae@cit-ec.uni-bielefeld.de>>, Armando Stellato
>     <_stellato@info.uniroma2.it_ <mailto:stellato@info.uniroma2.it>>,
>     Guido Vetere/Italy/IBM@IBMIT, Philipp Cimiano
>     <_cimiano@cit-ec.uni-bielefeld.de_
>     <mailto: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 <tel:%2B390644161535>
>     Fax: +390644161513 <tel:%2B390644161513>_
>     __aldo.gangemi@cnr.it_ <mailto:aldo.gangemi@cnr.it>_
>     __http://www.stlab.istc.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_
>     <mailto:jmccrae@cit-ec.uni-bielefeld.de>> wrote:
>
>     On Fri, Oct 12, 2012 at 6:35 PM, Armando Stellato
>     <_stellato@info.uniroma2.it_ <mailto: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--> OntologyEntityfrom "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_
>     <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_ <tel:%2B39%20%280%296%2059662137>_+39 (0)461
>     312312_ <tel:%2B39%20%280%29461%20312312>
>
>     Mobile: _+39 3357454658_ <tel:%2B39%203357454658>
>     _________________________________________________
>
>     *John McCrae <**_jmccrae@cit-ec.uni-bielefeld.de_*
>     <mailto:jmccrae@cit-ec.uni-bielefeld.de>*>*
>     Sent by: _johnmccrae@gmail.com_ <mailto:johnmccrae@gmail.com>
>
>     12/10/2012 16:35
>
>     	
>     To
>     	public-ontolex <_public-ontolex@w3.org_
>     <mailto: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 <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>
>
>
>     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
Received on Wednesday, 17 October 2012 14:07:24 UTC

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