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: Tue, 30 Oct 2012 10:39:25 +0100
Message-ID: <508FA04D.7070805@cit-ec.uni-bielefeld.de>

Dear all,

thanks for the contributions of Guido, Aldo et al. Apologies for the
silence in the last days. Some times I do other things than ontolex
(ehm) ;-)

It seems that we are converging on a two-level formalization:

Layer 1: senses are constants representing a linguistic meaning

Pro: i) cognitive simplicity, ii) LOD-compliance (navigate from lexical
entry to concept and from concept to lexical entry), iii) easy retrieval
of all lexicalizations of a concept without subsumption reasoning, iv)
easy to implement (DB, simple RDF store without reasoning, etc).
Contra: i) limited joint reasoning over lexicon and ontology

Layer 2: senses are (sub-classes)

Pro:  i) joint reasoning over lexicon and ontology, ii) senses are
subclasses (in line with the lemon model)
Contra: i) increased cognitive complexity, ii) no shortcut possible anymore

We will need to state how both layers are related to each other in some
sort of "glue theory".

I think this is a proposal that we can discuss on Friday, possibly
finally agreeing to follow this path. The implications of this will have
to be worked out of course in the near future.

Concerning the axiomatization of lexical relations: we could axiomatize
lexical relations also in layer one, i.e.

\forall s_1, s_2  Sense(s_1) & Sense(s_2) & synonyms(s_1,s_2)
\rightarrow \forall l LinguisticContext(l) & partOf(s_1,l) \rightarrow
semEquivalent(l[s_1/s_2],l).

where l[s_1/s_2] is that linguistic context where s_1 is replaced by
s_2. Of course, the question is what semEquivalent means, but that is
not somehting that I even intend to formalize or capture in this WG.

I will make a concrete proposal that we can discuss and agree on (or
not) on Friday.

Best regards,

Philipp.

Am 26.10.12 14:42, schrieb Guido Vetere:
> Aldo Gangemi <aldo.gangemi@cnr.it> wrote on 26/10/2012 10:04:29:
>
> > 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"? ;)
>
> exactly :-)
>
> > 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.
> >
>
> Sorry, I meant 'ideally, there are many solutions' etc.
>
> >
> >> 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?
> >
>
> I'm totally with you and our friend Maurizio. Let's go on with data
> structures for now.
>
> >
> >> 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.
> >
>
> Just to make it clear, I'm not advocating the logical formalisation of
> lexical relations in general, I'm just (trivially) saying that if you
> want to exploit standard DL reasoning on senses with respect to
> ontology classes, then you'd better treat senses as classes rather
> than instances. Of course, if you are not interested in the premise,
> then the consequence is irrelevant to you.
>
> > 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.
> >
>
> Agree with you and John.
>
>
> 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
> _________________________________________________
>
>
> 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
>
> (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 Tuesday, 30 October 2012 09:39:58 UTC

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