- From: Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de>
- Date: Wed, 31 Oct 2012 16:02:23 +0100
- To: John McCrae <jmccrae@cit-ec.uni-bielefeld.de>
- CC: "public-ontolex@w3.org" <public-ontolex@w3.org>
- Message-ID: <50913D7F.5040809@cit-ec.uni-bielefeld.de>
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
> <mailto: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⁻¹ ≡ sameRep
> sense⁻¹ ∘ sense ≡ sameLex
>
> Then the very simple axiom does the trick
>
> ∀ x,y : sameRep(x,y) ∧sameLex(x,y) → 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
>> <mailto: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 <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
>>
>>
>
>
> --
> 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
>
>
--
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, 31 October 2012 15:03:01 UTC