Re: Reminder, telco today on decomposition module

Hi,

So I have been going through the spec and there still seem to be some
issues in the decomp and synsem module.

1. The 'SemanticArgument' and 'SyntacticArgument' are still in the text but
not in the diagram. I propose we remove them from the text as they are very
confusing. Currently, the axioms in the text are as follows:

A SemanticFrame has its semArg as only Argument.
The range of semArg is however SemanticArgument.
A SyntacticFrame is not related to a SyntacticArgument, apart from being
the domain of synArg.
The SyntacticArgument and SemanticArgument are not related to each other.
They are also not related to Argument in the Wiki but appear to be subsets
of Argument in the OWL file

As such it seems clear, that SemanticArgument and SyntacticArgument are
totally unclear. This will create significant difficulties for anyone
attempting to learn this model, for absolutely no real benefit. (or even
potentially negatives for people who 'expect to see semantic argument and
syntactic argument', as this will encourage them to model arguments as they
expect not as we have defined them).

Is there any reason to keep them in? And if we really must, can we add a
clear axiom Argument ≡ SemanticArgument ≡ SyntacticArgument

2. I reworked the decomposition section mostly following existing comments
(thanks to Elena, Philipp, Manuel), I hope it is much clearer now.

Regards,
John


On Wed, Jun 10, 2015 at 5:50 PM, Manuel Fiorelli <manuel.fiorelli@gmail.com>
wrote:

> Dear Philipp, All
>
> as I promised, here is my comments on the decomp module.
>
> -----
>
> The diagram still needs to be updated.
>
> -----
>
> In the definition box of subterm.
>
> "The property subterm relates a compound lexical entry to one "
>
> do we want to also include "multi-word"?
>
> -----
>
> In Example1,
>
> ":itis_lex_canonical_form ontolex:writtenRep "itis"@en."
>
> the language tag should be @es.
>
> -----
>
> In Example2,
>
> ":autonoma_lex a lexinfo:Noun;"
>
> I think the lexical entry should be a lexinfo:Adjective.
>
> "ontolex:otherForm :autonoma_lex__femenine_singular_form."
>
> there is an underscore more than necessary between lex and femenine.
>
> It seems to me that "femenine" is misspelled.
>
> -----
>
> You write:
>
> "However, we can not specify which exact form of the entry (in the case of
> the above example the singular femenine form autónoma instead of the
> canonical form autónomo) is part of the compound lexical entry"
>
> I would add the other point that you cannot represent the position of the
> subterm in the compound lexical entry.
>
> ----
>
> In Example decomp/example3,
>
> you have two triples:
>
> "
> lexinfo:gender :femenine;
> lexinfo:masculine :masculine.
> "
>
> I think that the second one is erroneous. Also in the first one, femenine
> is misspelled and it requires the lexinfo prefix.
>
> -------
>
> You write:
>
> "If we want to specify the order of the components, we can use the RDF
> properties rdf:_1, rdf:_2, etc. to specify the absolute order, in addition
> to the constituent properties."
>
> I would reinforce the idea that subterm nor constituent support the
> representation of the order. Not sure if it is the case to explicitly tell
> (for less expert users) that the order of the triples is not relevant in an
> RDF description.
>
> -------
>
> In Example 5:
>
> there is the triple
>
> ":knows_component decomp:correspondsTo :knows_component."
>
> I think that the object should be :knows instead.
>
> I would add a canonical form for the lexical entry. Not sure if the
> lexical entry should be called :knows or :know
>
> Do we want to use a more specific type for the frame?
>
> ------
>
> With respect to example5, is it relevant to give more phrase structures?
> For instance, is it relevant to give the passive "Y known by X". Or are we
> only giving the "canonical" phrase structure? Actually, the syntactic
> arguments are subject and direct object, thus I am inclined to say that
> they should not be associated with the elements of a passive construction.
>
> ------
>
> There is no more the example on AfricanSwineFever, which was interesting
> because it was an example of hierarchical decomposition.
>
> ------
>
> 2015-06-09 14:56 GMT+02:00 Manuel Fiorelli <manuel.fiorelli@gmail.com>:
>
>> Hi Philipp, All
>>
>> Here are my comments on the Synsem module. The comments on decomp will
>> follow in the next days.
>>
>> ---
>>
>> In the diagram, the association named "subframe" should be applied to
>> SemanticFrame rather than to sense. The same holds true for the property
>> condition.
>>
>> ---
>>
>> In the wiki, it is mostly used the property name synBehaviour, despite
>> in the definition box it appears as synBehavior. In the ontology, the
>> property is named synBehavior with a label equal to "syntactic
>> behaviour".
>>
>> I do not have a strict opinion on which orthography to use, but I am
>> surprised that the (human readable) name and the label use two different
>> orthographies.
>>
>> ----
>>
>> Just above the definition box of synArg, there is the following sentence:
>>
>> "The object property synArg is used to relate a (syntactic) frame to one
>> of its (syntactic) arguments."
>>
>> I would avoid the use of parenthesis around the word syntactic, and
>> instead write "syntactic frame".
>>
>> ----
>>
>> In the definition box of Class: Syntactic Argument and Class: Syntactic
>> Argument, should there be a superclass Argument? (at least it is present
>> in the ontology)
>>
>> ----
>>
>> In the definition box of Class: Semantic Frame, the axiom should use SemanticArgument
>> instead of Argument
>>
>> -----
>>
>> Concerning Example synsem/example3, I would make it explicit the fact
>> that the binding between the syntactic and semantic arguments is realized
>> by unifying them.
>>
>> ------
>>
>>
>> In Example synsem/example7, you use rdfs:subProperty, while the correct
>> one is rdfs:subPropertyOf.
>>
>> the the semantic argument giving_event seems unbound. Is this a case in
>> which we should use the property isA?
>>
>> ----
>>
>> I would expand the description of Example synsem/example8, to indicate
>> the function of synsem:isA. Also, if I am right on the previous point, I
>> think that there is a slight difference between the use of isA in this
>> example and its use in example 7.
>>
>> ----
>>
>> In the wiki you use "*X ∈ ∃inverse father.Thing"*. Although it is
>> probably a bad name, I would write a perhaps clearer "*X ∈ ∃
>> fatherOf.Thing*". However, I am not sure.
>>
>> ----
>>
>> Do we want to add an example for symsem:isA? Maybe we can expand the
>> example in the table:
>>
>> Class Unary predicate City(x), ?x rdf:type dbpedia-owl:City
>>
>> ---
>>
>> If we want to represent an event verb, we can take the example from the
>> BIO ontology:
>> http://vocab.org/bio/0.1/.html#Graduation
>>
>> 2015-06-09 7:20 GMT+02:00 Philipp Cimiano <
>> cimiano@cit-ec.uni-bielefeld.de>:
>>
>>>  Dear all (there were two crucial typos in my email from yesterday ;-)
>>>
>>> I have *now* completely *updated* the synsem and decomp modules
>>> according to what we have discussed in the last three weeks. I have
>>> synchronized the description in the wiki with the ontologies and the
>>> examples.
>>>
>>> Here are a few todos:
>>>
>>> 1) All: please check that the points you have raised recently have been
>>> considered to a satisfactory extent; let me know otherwise.
>>> 2) Fahad: please check the new examples for the synsem module. Are they
>>> better?
>>> 3) Lupe/Elena/Manuel (not Armando): please check the examples in the
>>> decomp section. Do they solve the issues we discussed? Let me know please.
>>>
>>> John and me are still working on some specific examples...
>>>
>>> Kind regards,
>>>
>>> Philipp.
>>>
>>> Am 08.06.15 um 22:44 schrieb Philipp Cimiano:
>>>
>>> Dear all,
>>>
>>>  I have not completely updates the synsem and decomp modules according
>>> to what we have discussed in the last three weeks. I have synchronized the
>>> description in the wiki with the ontologies and the examples.
>>>
>>> Here are a few todos:
>>>
>>> 1) All: please check the the points you have raised recently have been
>>> considered to a satisfactory extent; let me know otherwise.
>>> 2) Fahad: please check the new examples for the synsem module. Are they
>>> better?
>>> 3) Lupe/Elena/Armando: please check the examples in the decomp section.
>>> Do they solve the issues we discussed? Let me know please.
>>>
>>> John and me are still working on some specific examples...
>>>
>>> Kind regards,
>>>
>>> Philipp.
>>>
>>> Am 02.06.15 um 10:53 schrieb John P. McCrae:
>>>
>>>  Yes I think you are right, we should expand the description of subterm
>>> as it is the preferred primary mechanism of relating terms
>>>
>>>  Regards,
>>>  John
>>>
>>> On Fri, May 29, 2015 at 3:07 PM, Elena Montiel Ponsoda <
>>> emontiel@fi.upm.es> wrote:
>>>
>>>>  Philipp,
>>>>
>>>> I know it is too late for this, but Lupe and I were having a look at
>>>> the model, and we are struck by the following doubt:
>>>>
>>>> What is the benefit of having the property subterm pointing to another
>>>> LexicalEntry? What is it that you can say with that property that cannot be
>>>> said with Components??
>>>> In the paragraph below you talk about the limitations of subterm, but
>>>> you do not say what the benefits of having it are, or what you can
>>>> represent with that property that cannot be represented by Components, etc.
>>>>
>>>> "The use of the property *subterm* has two limitations. First, we can
>>>> not indicate inflectional properties of the lexical entry when appearing as
>>>> a subterm of another term. Further and most importantly we can not indicate
>>>> the order of subterms within a compound lexical entry. For this, the model
>>>> defines the the class Component, which represents a part of a lexical entry
>>>> and allows to add additional information describing the use of the lexical
>>>> entry in a compound. A component is declared as a subclass of rdf:sequence
>>>> as it can be understood as an ordered list of sub-components."
>>>>
>>>> We think that an explanation on this sense is needed.
>>>> Talk to you in a minute!
>>>>
>>>> Best,
>>>> Elena.
>>>>
>>>> El 29/05/2015 a las 10:48, Philipp Cimiano escribió:
>>>>
>>>> Dear all,
>>>>
>>>>  this is a gentle reminder for our telco on the decomposition module
>>>> today at 16:00 CET.
>>>>
>>>> Access details can be found here:
>>>>
>>>>
>>>> https://www.w3.org/community/ontolex/wiki/Teleconference,_2015.5.29,_16-17_pm_CET
>>>>
>>>> I have added to the agenda all points raised by Manuel (thanks
>>>> Manuel!). I have not received any other issues to discuss.
>>>>
>>>> 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
>>> Fax: +49 521 106 6560
>>> Mail: 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
>>>
>>>
>>
>>
>> --
>> Manuel Fiorelli
>>
>
>
>
> --
> Manuel Fiorelli
>

Received on Thursday, 11 June 2015 15:30:16 UTC