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: Aldo Gangemi <aldo.gangemi@cnr.it>
Date: Fri, 26 Oct 2012 10:04:29 +0200
Cc: Aldo Gangemi <aldo.gangemi@cnr.it>, public-ontolex@w3.org
Message-Id: <8A657D28-31F2-412A-AD4A-6DA862936D98@cnr.it>
To: Guido Vetere <gvetere@it.ibm.com>
Dear Guido, some more comments: I think we have cut the problem to the bones now, and can proceed to a concrete list of alternatives.

On Oct 23, 2012, at 5:58 PM, Guido Vetere <gvetere@it.ibm.com> wrote:

> 
> Of course if you can elaborate the axiomatization of sense and sense relationships in the model, then there are many solutions like yours, I was just comparing the specific models we were discussing. 

Ehm, do you mean: "your solution is just one of those that naïve people can easily produce during pasta cooking by using their pinky toes"? ;)
I'd say that my solution is based on a design pattern that works well with this kind of data. If you know about "many" others, please share them with us, so we can evaluate those that fit best.

> 
> However, as part of such axiomatization, you would be expected to introduce logical lexical relations as first order properties (as in fact you did) and to specify, for instance, whether if <s1,synonym_of,s2> implies that lexemes associated to s1 are available as a substitute for those associated to s2, like if they were logically equivalent. In sum, you would have to reconstruct a fragment of the same logic in which your ontology is specified, and to implement part of the standard DL reasoning as (e.g.) SPARQL queries. In sum, I want to 'transform' senses into a full-fledged ontology (by the way, what are them 'originally'?), but you want to reimplement logics in SPARQL! 

It seems you are putting another requirement into your use case, i.e. that lexical relations *must* be formalized within a (FOL or HOL) logic. I am not sure this is something we can achieve in this WG, neither that it is worth doing it just for the sake of jointly reasoning with lexical and ontological data (but see below).
And of course, I do not want to reimplement logics in SPARQL: I'm showing a possible solution for a relatively simple use case, without resorting to DL reasoning gunboats. Maurizio Lenzerini, who you often quote, reminds knowledge engineers to use basic data models like relational DB when you do not really need more than that. I agree with him here: what you call "logical lexical relations" are not necessarily logical in the sense of being in the meta-theory of OWL, at least because we do not commit to a deep formalization of any linguistic/lexical resource, do we?

> 
> Seriously, of course there are pros and cons in every choice, I think that we should just draw a number of possible alternatives. I think that M2 allows a smooth exploitation of ontological axioms on the lexical side without requiring an elaborated semiotic model. It is clear that lexical relationships cannot be trivially mapped to logical ones and that a complete semiotic model should probably provide an account for this. But as far as users in concrete use cases are just interested in exploring the relationship between existing ontologies and (mapped) lexical resources (e.g. to discover how disjunction is reflected on antonymy), M2 is good enough - and could be further refined, but this is for the next game :-) 
> 

You stress the importance of a logical treatment of lexical relations. Good enough, I deem this an important issue, which we are studying e.g. for the FRED text2rdf tool. But here the use case is directly "reasoning on textually-derived data/ontologies", not the one we are discussing here. Also this use case is part of the interface between language and ontologies, but a more challenging one. BTW, it does not concern how we map lexical relations to description logics, but how to represent natural language semantics (and pragmatics) into logic.

Bottom line, I agree on the alternative patterns idea, but with compatibility statements. 
I think this WG can deliver a comprehensive proposal that delivers pairs of requirements/use cases and ontology modules. 
We should also consider the valuable observations of John's about the actual reception/sustainability from average users. We clearly need different layers or modules, with the complication that we need compatibility among them: as John said, clarifying those compatibilities is not trivial.

Ciao
Aldo


> Ciao, 
> 
> 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> wrote on 23/10/2012 15:55:26:
> 
> > Aldo Gangemi <aldo.gangemi@cnr.it> 
> > 23/10/2012 15:55 
> > 
> > To 
> > 
> > Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de> 
> > 
> > cc 
> > 
> > Aldo Gangemi <aldo.gangemi@cnr.it>, public-ontolex@w3.org 
> > 
> > Subject 
> > 
> > Re: Issues about the semantics of the ontology-lexicon interface    
> > [was: Re: Why   not to shortcut the "sense" object] 
> > 
> > Philipp, Guido, 
> > 
> > Guido would like to transform a sense lexicon "on the fly", making 
> > it a full-fledged axiomatized ontology just because it is mapped to 
> > an axiomatized ontology. 
> > Now, we can obtain the same result with a two-step process, which I 
> > recommend usually when such problems arise with heterogeneous knowledge: 
> > 
> > a) use a simple model to query (and modestly reason) over ontology
> > +lexicon: with (a) most ontolex use cases will be satisfied, 
> > including Guido actually (ehm) 
> > b) make a refactoring of the lexicon as an axiomatized ontology by 
> > using a "copycat" process: substitute senses to ontology entities 
> > (or make them equivalent to), and reason in regular DL mode 
> > 
> > For (a), that's my attempt: I designed a simple OWL ontology 
> > (attached) for the example of Guido's, in a way that differs from 
> > both Guido's examples (can be considered an extension of example 1).
> > It implements the basic pattern we are talking about (LexicalItem-
> > hasSense->Sense-representedBy->OntologyEntity), augmented with a 
> > DomainEntity class and some properties between senses: specializes, 
> > and its subproperty meronymicallySpecializes. Now, instead of 
> > attempting any HODL reasoning, more modestly I show how to get a 
> > semantic field with a simple SPARQL query: 
> > 
> > PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> 
> > PREFIX owl: <http://www.w3.org/2002/07/owl#> 
> > PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> 
> > PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> 
> > PREFIX ge: <http://www.ontologydesignpatterns.org/ont/guidoexample3.owl#> 
> > CONSTRUCT { ?s1 ge:meronymicallySpecializes ?s } 
> >  WHERE { 
> >   ?s ge:representedBy ge:Aircraft . 
> >   ?s1 ge:representedBy ?C1 . 
> >   ?C1 rdfs:subClassOf ?R . 
> >   ?R owl:onProperty ge:partOf . 
> >   ?R ?quant ge:Aircraft } 
> > 
> > Now the ball passes to Guido: when should we need (b), if your use 
> > case is satisfied already with (a)? 
> > 
> > Ciao 
> > Aldo 
> > [attachment "guidoexample3.owl" deleted by Guido Vetere/Italy/IBM] 
> > On Oct 23, 2012, at 1:59 PM, Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de
> > > wrote: 
> > 
> > Guido,
> > 
> >  btw. a difficult question to you: how many applications would 
> > require subsumption reasoning between senses.
> > 
> > I wanted to produce a very simple model, but if it turns out that 
> > many applications require joint reasoning over lexicon and ontology,
> > then the simpler model will turn out to be inadequate.
> > 
> > Any thoughts?
> > 
> > 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 keepingonly 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 Friday, 26 October 2012 08:05:08 UTC

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