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

RE: Summary of teleconference last Friday

From: Armando Stellato <stellato@info.uniroma2.it>
Date: Wed, 28 Nov 2012 12:19:00 +0100
To: "'Philipp Cimiano'" <cimiano@cit-ec.uni-bielefeld.de>
Cc: <public-ontolex@w3.org>
Message-ID: <001601cdcd5a$2ae9ab80$80bd0280$@uniroma2.it>
> rethinking the lingustic sign, actually it is "sign". We should not call
it
> linguistic in my view as it is something at the interface between the
lexicon
> and the ontology and not only at the linguistic side.
> 
> So I propose we simply call it "a sign that represents the disambiguated
> meaning of a lexical entry when interpreted as concept c.

Fine. I had the same thinking, but in the end thought "linguistic sign is
not that bad": from some point of view, this sign can be seen as something
in the linguistic dimension connecting word senses to objects of the world.
Definitely, ontology entities are sign themselves, which only after
interpretation bring to real world objects, thus "linguistic" didn't sound
so bad to me.

However, in the overall definition:

sense :- a <...> representing the disambiguated meaning of a lexical entry
when interpreted

sign alone is ok.

> Concerning the reasoning: we will only do reasoning between senses and the
> classes they denote, but not infer any relationships between the
ontological
> classes, but only between the senses proper.

I'm not sure I would even like to infer some relationship between linguistic
senses, such as inferring that a wn:Synset is a hyponym of another one, due
to some relationship between classes they are attached to in a given
onto-lex mapping. However, after grounding the basic ontolex vocabulary, and
on the representation of Linguistic Resurces [1], we will have more clear
what we would like to be inferable and what is better to leave out of
inference.
 
[1]
http://www.w3.org/community/ontolex/wiki/Specification_of_Requirements/Linke
d_Data

Cheers,

Armando
Received on Wednesday, 28 November 2012 11:19:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:36:27 UTC