Re: Changes in synsem and vartrans

Dear Fahad,

  thanks for your comments.... I reply to them below....


Am 16.07.15 um 17:58 schrieb Fahad Khan:
> Hi everyone,
>
> I have a few comments on the final OntoLex spec. Firstly some minor 
> things and then a couple of more general points about the new OntoMap 
> class:
>
> a) The title of §3.2 is still "Semantic Frames" which is a bit 
> confusing given that they don't feature explicitly in the model anymore;

True, I changed this.

> b) The first paragraph of §3.2, "a OntoMap" -> "an OntoMap"
Thanks, changed.

> c) In §3.3 you talk about the diathesis alternation being 'between "X 
> gave Y X" and "X gave X to Y"'...I'm guessing two of those X's should 
> be Z's or at least not X's.

OK, thanks for noticing. I have changed this.

> d) In synsem/example 7 you give two different URI's for the giver, 
> given, and receiver references, once with the example.org 
> <http://example.org> domain, and then with the ontology.org 
> <http://ontology.org> domain (or maybe I've misunderstood something?).

Indeed, I have changed this now and replace everything by ontology.org


>
> The general comments, which given that this Friday's is the last Telco 
> and Philipp wants to freeze the model, are more discussion points in 
> the case that there is time and willingness:
>
> I think having an OntoMap class is a better solution than having the 
> two different sets of arguments, semantic and syntactic, if you're 
> going to be strict about semantics by reference that is and about 
> having all the semantic information in the ontology (though personally 
> speaking I don't think you can be too strict here without making 
> numerous theoretical assumptions about natural language semantics or 
> pissing off the ontology modelling guys who're going to want the 
> ontology to be as language independent as possible, but that's a 
> discussion for another day...).  That being said, I did notice that in 
> the VerbNet lemon-encoding, semantic arguments are explicitly 
> mentioned (using the semArg mapping) -- even if they are identified 
> with syntactic arguments -- and semantic predicates are subclasses of 
> Lexical Sense. With the OntoLex model I guess you would expect 
> semantic predicates to belong to an external ontology or for users to 
> construct their own, but I don't know if users will always want to do 
> this (the lemon version of VerbNet being a case in point).
>
I am not sure about the VerbNet lemon encoding. But the position of 
ontolex is clear: semantics is in the ontology. What is not in the 
ontology does not exist.
If things exist that can be refered to in natural language, then they 
should be part of the ontology. If the ontology has limitations then 
this is not an ontolex problem, but a problem of the ontology...

> Secondly, I don't get why OntoMap necessarily needs to be a subclass 
> of Lexical Sense. Indeed I think that intuitively speaking such a 
> syntactic-semantic mapping seems to play a different role from 
> LexicalSense. Also it may well be the case that two different senses 
> of a word share the same synsem mapping (depending on how fine grained 
> your ontology is), e.g., subject -> Agent, object->Patient; making 
> ontomaps separate senses muddies the water in this case. Additionally 
> synsem/Example 7 seems to bundle lots of different things together and 
> is complicated and hard to understand (for me anyway) largely because 
> :giving_semframe is both mapping the entry to an extension (the class 
> of giving events) and describing its (meaning-influenced) syntagmatic 
> behaviour.  I think it would be easier  (obviously at the cost of 
> concision) at least conceptually if :give had a sense that pointed to 
> <http://example.org/giving> and each of the synBehaviours had a 
> separate OntoMap to the ontology, or even one mapping with submappings 
> describing its argument structure.

The LexicalSense implements the lexicon-ontology interface. A sense is a 
pair of lexical entry and corresponding concept. An OntoMap is a 
subclass that relates a lexical entry with internal structure (e.g. with 
arguments) to a structure in the ontology. Thus, it is clearly a 
subclass of a LexicalSense.
Lexical Senses can not share the same mapping because the arguments of a 
syntactic behaviour are unique for this behaviour, so the mapping to 
ontological arguments needs to be specified for each syntactic 
behaviour... so two senses can not share the same mapping...

I hope this clarifies. Otherwise, we can continue discussing tomorrow. 
Thanks for your input.

On example 7: certainly not the most compact one, but I added this 
example because you challenged us to represent the alternation for X 
gave Y Z" and "X gave Z to Y
I have tried to completely spell out how to do this? What exactly would 
you propose to remove from the example?

Kind regards,

Philipp.
>
> But maybe I've misunderstood the model and if so I'd be very glad for 
> some clarification.
>
> Cheers,
> Fahad
>
> On 7 July 2015 at 15:01, Philipp Cimiano 
> <cimiano@cit-ec.uni-bielefeld.de 
> <mailto:cimiano@cit-ec.uni-bielefeld.de>> wrote:
>
>     Dear Jorge, all,
>
>      you are right that we are violating our principle of using the
>     same name for a property and a class. However, in this case it
>     makes sense as both the class and the property express the same
>     relation but with different modelling paradigms (reification by a
>     class and property respectively). Further, both are related
>     through the corresponding equivalence axiom so that writing x
>     source^-1 translation_reflexive o target implies translation. The
>     other way round it does not work, that's OWL ;-)
>
>     In any case, both translation and Translation are the same
>     relation in principle, so using the almost same names modulo case
>     seems appropriate here.
>
>     Kind regards,
>
>     Philipp.
>
>     Am 07.07.15 um 13:27 schrieb Elena Montiel Ponsoda:
>>     Dear Philipp, all,
>>
>>     As for the synsem module, I think that the changes you are
>>     proposing make complete sense, and I find the name OntoMap quite
>>     intuitive.
>>
>>     As regards the translation property, an alternative to what Jorge
>>     was proposing could be:
>>     equivalentTranslation/isEquivalentTranslationOf (though I am also
>>     not 100% happy with it either...), or maybe just
>>     equivalent/isEquivalentTo...
>>
>>     Talk to you on Friday!
>>     Elena.
>>
>>     El 07/07/2015 a las 12:44, Jorge Gracia escribió:
>>>     Dear Philipp, all
>>>
>>>     In the vartrans module, a "translation" property is defined as a
>>>     shortcut of the "Translation" class [1]. However, the chosen
>>>     identifier violates our rule of not using the same word to
>>>     identify both a class and a property. A new name should be found
>>>     for this property.
>>>     Nevertheless, if such a property is there for backwards
>>>     compatibility only, I see a simpler solution, which is to use
>>>     lexinfo:translation and define it as a sense relation:
>>>
>>>     lexinfo:translation rdfs:subPropertyOf vartrans:senseRel
>>>
>>>     (although I am not 100% happy with this solution, either). Maybe
>>>     we could briefly discuss about this in our next telco.
>>>
>>>     Regards,
>>>     Jorge
>>>
>>>
>>>
>>>
>>>     [1]
>>>     https://www.w3.org/community/ontolex/wiki/Final_Model_Specification#Translation_as_a_relation_between_lexical_senses
>>>
>>>     2015-07-06 10:19 GMT+02:00 Philipp Cimiano
>>>     <cimiano@cit-ec.uni-bielefeld.de
>>>     <mailto:cimiano@cit-ec.uni-bielefeld.de>>:
>>>
>>>         Dear all,
>>>
>>>          I have implemented now all the changes in the vartrans
>>>         module that Manuel, Jorge and Lupe pointed me to. Also the
>>>         ontologies and the examples have been updated...
>>>
>>>         Let me also say that I have done a number of more
>>>         fundamental changes in the synsem module in agreement with
>>>         John. Fortunately, these are rather conceptual changes and
>>>         have little impact on the actual way the model will be used.
>>>         In fact, from the structure these changes are quite backwads
>>>         compatible both with what we had so far as well as with the
>>>         original lemon model.
>>>
>>>         Let me explain a bit the rationale for this....
>>>
>>>         It has been clear that there has been quite some discussion
>>>         on the SemanticFrame class and in particular whether there
>>>         is such a thing as a semantic argument in the model and
>>>         whether semantic arguments are distinct from each other...
>>>
>>>         It seems to me that the main issue has been that the
>>>         SemanticFrame class has been interpreted differently as it
>>>         was supposed to. Essentialy, this class was supposed to
>>>         represent the bindings of arguments of ontological
>>>         predicates to the syntactic arguments they are realized by.
>>>         However, I agree that the name "SemanticFrame" makes one
>>>         think about "Frames" in the tradition of Framenet, which
>>>         actually in our case would play the role of ontological
>>>         "references" rather than of Lexical Senses.
>>>
>>>         Further, it was indeed awkard to say that a SemanticFrame is
>>>         a subclass of LexicalSense.
>>>
>>>         Thus, John came up with a proposal I like quite a lot and
>>>         which I have implemented in the wiki, ontology and examples
>>>         already. The proposal consists in renaming a few classes to
>>>         make their actual role and function better graspable and to
>>>         avoid confusion with other related but not equivalent
>>>         concepts. So here is the proposed renaming:
>>>
>>>         SemanticFrame -> OntoMap (reflecting that it actually
>>>         specifies how the ontological arguments of a predicate "map"
>>>         to syntactic arguments of a syntactic frame and the other
>>>         way round; this thus more or less corresponds to the
>>>         SynSemCorrespondence in KMF).
>>>
>>>         SemanticArgument -> obsolete (not needed anymore)
>>>
>>>         Syntactic Argument and Syntactic Frame -> stay as they are
>>>
>>>         semArg -> ontoCorrespondence (to make clear that it
>>>         establishes a correspondence between an ontological argument
>>>         and a syntactic argument)
>>>
>>>         subframe -> submap (to be consistent with renaming
>>>         SemanticFrame as OntoMap)
>>>
>>>         I hope you all agree with these changes. Please review them
>>>         carefully. We will have chance to discuss them on the 17th
>>>         of Juli where we will have the final telco on the model.
>>>
>>>         I send a separate email to remind us all of the upcoming
>>>         discussion on the LIME module this week.
>>>
>>>         Kind regards,
>>>
>>>         Philipp.
>>>
>>>         -- 
>>>         --
>>>         Prof. Dr. Philipp Cimiano
>>>         AG Semantic Computing
>>>         Exzellenzcluster für Cognitive Interaction Technology (CITEC)
>>>         Universität Bielefeld
>>>
>>>         Tel: +49 521 106 12249 <tel:%2B49%20521%20106%2012249>
>>>         Fax: +49 521 106 6560 <tel:%2B49%20521%20106%206560>
>>>         Mail: cimiano@cit-ec.uni-bielefeld.de
>>>         <mailto:cimiano@cit-ec.uni-bielefeld.de>
>>>
>>>         Office CITEC-2.307
>>>         Universitätsstr. 21-25
>>>         33615 Bielefeld, NRW
>>>         Germany
>>>
>>>
>>>
>>>
>>>
>>>     -- 
>>>     Jorge Gracia, PhD
>>>     Ontology Engineering Group
>>>     Artificial Intelligence Department
>>>     Universidad Politécnica de Madrid
>>>     http://jogracia.url.ph/web/
>>
>
>     -- 
>     --
>     Prof. Dr. Philipp Cimiano
>     AG Semantic Computing
>     Exzellenzcluster für Cognitive Interaction Technology (CITEC)
>     Universität Bielefeld
>
>     Tel:+49 521 106 12249  <tel:%2B49%20521%20106%2012249>
>     Fax:+49 521 106 6560  <tel:%2B49%20521%20106%206560>
>     Mail:cimiano@cit-ec.uni-bielefeld.de  <mailto:cimiano@cit-ec.uni-bielefeld.de>
>
>     Office CITEC-2.307
>     Universitätsstr. 21-25
>     33615 Bielefeld, NRW
>     Germany
>
>

-- 
--
Prof. Dr. Philipp Cimiano
AG Semantic Computing
Exzellenzcluster für Cognitive Interaction Technology (CITEC)
Universität Bielefeld

Tel: +49 521 106 12249
Fax: +49 521 106 6560
Mail: cimiano@cit-ec.uni-bielefeld.de

Office CITEC-2.307
Universitätsstr. 21-25
33615 Bielefeld, NRW
Germany

Received on Thursday, 16 July 2015 18:29:12 UTC