Re: Changes in synsem and vartrans

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;
b) The first paragraph of §3.2, "a OntoMap" -> "an OntoMap"
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.
d) In synsem/example 7 you give two different URI's for the giver, given,
and receiver references, once with the example.org domain, and then with
the ontology.org domain (or maybe I've misunderstood something?).

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

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.

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>
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>:
>
>> 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 <%2B49%20521%20106%2012249>
>> Fax: +49 521 106 6560
>> Mail: 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
> Fax: +49 521 106 6560
> Mail: cimiano@cit-ec.uni-bielefeld.de
>
> Office CITEC-2.307
> Universitätsstr. 21-25
> 33615 Bielefeld, NRW
> Germany
>
>