$)CRe: input document for discussion on Friday

$)CPhilipp,

\forall x,y hasSense(x,y) \wedge hasSense(x,z) \wedge representedBy(y,c) 
\wedge representedBy(z,c) \rightarrow x=y

If you mean \forall y,z ... y=z (i.e. whether being 'representedBy' the 
same concept means for two senses being the very same sense) then my 
answer would be definitely no, however this depends on the intended 
meaning of 'representedBy' which is obscure to me. 

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> 
31/10/2012 16:02

To
John McCrae <jmccrae@cit-ec.uni-bielefeld.de>
cc
"public-ontolex@w3.org" <public-ontolex@w3.org>
Subject
Re: input document for discussion on Friday






Hi John, all, 

 see below.

Am 31.10.12 14:34, schrieb John McCrae: 


On Wed, Oct 31, 2012 at 1:16 PM, Philipp Cimiano <
cimiano@cit-ec.uni-bielefeld.de> wrote:
John, all,

 comments back...

Am 31.10.12 12:59, schrieb John McCrae: 
Hi, 

Some comments

ex:lemon rdf:type ontolex:Lex.
ex:lemon ontolex:hasSense lemon_1.
lemon_1 owl:subClassOf <http://dbpedia.org/page/Lemon>.
ex:lemon ontolex:hasSense lemon_2.
Thus :lemon_2 is an individual 
lemon_2 owl:subClassOf ex:DefectiveItem.
Thus :lemon_2 is a class

This leads to a punning of the sense... is this intended?

Yes, intended to capture the dual role of a sense. 



And further (not expressible in OWL2 DL):
"#x; y lex(x; y) "$s Sense(s) ^ hasSense(x; s) ^ representedBy(s; y)

I really don't think we should go beyond OWL2 DL

We will not. This is simply not expressable in OWL2 DL. This is an axiom 
that might need to be ensured in implementations or not at all. To be 
discussed. 


 it is true that it blows up the complexity of the
model. However, it simplifies the usage of the model
Surely this is a contradiction?

No, it's not. The model is in principle more complex, but people use 
always that subset that fits their need. They have their own simple view 
on a complex model. 


I think this can be handled eff ectively by query expansion (as above) in 
any
implementation of an API for the lexicon-ontology model
Not all implementations will be query based... for example OWLAPI isn't

Sure, there will be different ways of implementing this. Query expansion 
is not the only one. Relying on OWL reasoning is another one.
SPARQL construct is another one. And a procedural API-specific 
implementation is another one. We could provide some recommendations on 
this. I am not suggesting that we ignore implementaiton, but that we do 
not put it at the centre of our discussions. 


This can be done through SPARQL-construct 
The construct query is:

CONSTRUCT { ?entry ontolex:hasSense _:sense . 
                             _:sense ontolex:representedBy ?entity }
WHERE { 
    ?entry ontolex:ref ?entity
}

Of course, this leads to issues as the constructed sense is a blank 
node... I believe that like OWL we should advise against the use of blank 
nodes for "concepts" within the lexicon. See 
http://richard.cyganiak.de/blog/2011/03/blank-nodes-considered-harmful/  
http://milicicvuk.com/blog/2011/07/14/problems-of-the-rdf-model-blank-nodes/
 etc.

ex:lemon rdf:type ontolex:Lex.
ex:lemon ontolex:hasSense lemon_1.
lemon_1 ontolex:representedBy <http://dbpedia.org/page/Lemon>.
ex:lemon ontolex:ref <http://dbpedia.org/page/Lemon>. 
 
Then the question certainly is how many senses I get back with the query.
Ideally, I would like to get one sense back.
Yeah technically that is what should happen... however here we have to 
apply the semantics of RDFS, in that the blank node we construct is 
matched to lemon_1. Of course, the downside to this is that this is 
non-polynomial to solve with generic solvers... and tricky in a 
specialized implementation (also I think it is incompatible with OWL2-DL)
One question: do we want to model that for any pair of class and lex, 
there
is at most one sense relating them? Can we do this in OWL?
I would say no, I think we have found use cases for multiple sense between 
the same entry/entity in lemon (but can't remember at the moment... it'll 
come to me)

As for in OWL... is this not it? 

??1.lex.Lex

No, this says that there is exactly one lexicalization per concept ;-)
Yeah that was dumb.... actually, it may not be possible

A good start is 
represents ? represents?)v !U sameRep
sense?)v ? sense !U sameLex

Then the very simple axiom does the trick

"# x,y : sameRep(x,y) !|sameLex(x,y) !f x = y

Right. That goes in the right direction. However, the last rule is not 
expressible in OWL 2 DL unfortunately. Essentially, one has two paths 
between variables x,y in the premise, so no way to represent this as a 
property chain.

I think it is not a huge problem, but ... the thing is that if we infer 
senses (that are existentially quantified), then
we need to equate them with senses that are explicitly stated as 
connecting the same pair of lexical entry and concept. Well, do we 
actually? Or can we live with the fact that in practice there are many 
identical senses the identity of which is not stated?

Btw: this is not per se a problem of blank nodes. We would have the same 
problem if we would skolemize, i.e. introduce a fresh URI. 

I think we should avoid the problem of introducing existentially 
quantified senses, no matter if we introduce them via blank nodes or via a 
skolem constant. 

So, the shortcut should be handled IMHO at retrieval time only. 

Independently of whether the above axioms are representable in OWL, I 
would like to know whether we agree on the fact that:

\forall x,y hasSense(x,y) \wedge hasSense(x,z) \wedge representedBy(y,c) 
\wedge representedBy(z,c) \rightarrow x=y

Is that our understanding of how a sense behaves?

Philipp.
However this is (probably) impossible to represent in OWL:

http://answers.semanticweb.com/questions/2336/preventing-other-individuals-in-a-class-from-inferring-the-same-property#2338

I don't know if there is another way

Regards,
John


Regards,
John

On Wed, Oct 31, 2012 at 9:45 AM, Philipp Cimiano <
cimiano@cit-ec.uni-bielefeld.de> wrote:
Dear all,

 I have compiled a brief document as input for our discussion on Friday. 
We will discuss this proposal on Friday and collect comments and 
objections.

Best regards,

Philipp.

-- 
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




-- 
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



-- 
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
Societa con unico azionista
Societa soggetta all!/attivita di direzione e coordinamento di 
International Business Machines Corporation

(Salvo che sia diversamente indicato sopra / Unless stated otherwise 
above)