Re: Reminder, telco today on decomposition module

Dear John, All

I have re-read the spec of the decomp module after the editing by John. You
can find my comments below. I anticipate that the biggest comment is about
better clarifying the difference between the properties subterm and
constituent. As a side comment, I do agree with Fahad that it could be nice
to have an explanation of the approach taken for modeling the mapping
between syntactic and semantic arguments. However, I am unsure about how we
should balance in the spec the description of our approach ("what we did")
and the description of alternative approaches ("why we did it" or "why we
didn't do this way"). At least I would make it clear that the expected
usage mode is to unify syntactic and semantic arguments.

----

I don't fully understand the difference between decomp:subterm and
decomp:constituent. In their definition boxes, you use "composed of" in the
former case and "constituted by" in the latter case.

In my understanding, decomp:subterm relates a lexical entry to any entry
that "lexically occurs" within the former (as an example1). This relation
is general enough to also give all the components of a lexical entry (as an
example 2), but you are not required to do so. Conversely, using
decomp:constituent, you are supposed to give the decomposition of a lexical
entry into its building blocks.

----

In Example decomp/example1 and Example decomp/example2, I would add the
canonical forms of the multi-word/compound lexical entry, to avoid the
misunderstanding that the use of decomposition makes unnecessary the
representation of the forms associated with the decomposed lexical entry.

----

In the section "Components":

In the sentence:

"The subterm property allows us to state that a term is part of a word, but
it does not specify the actual decomposition of a term"

before the comma:

"term" is the part
"word" is the whole

however, after the comma it seems to me that "term" becomes the whole.

----

In section "Phrase Structure":

The sentence:

"In addition we may combine this with the synsem module to give the phrase
structure tree of a frame. This is done by making the frame the target of
the corresponds to property and including components in the tree that
correspond to individual arguments. "

I would make it explicit that we are talking about syntactic frames.

In Example 7, you should use the class synsem:SyntacticFrame


2015-06-12 15:10 GMT+02:00 Fahad Khan <anasfkhan81@gmail.com>:

> Dear Philipp, All,
>
> I've re-read the specifications and I think the examples now are much
> clearer and that they explain the model better. However there is some
> confusion (for me at least) under the description of the Syntactic Argument
> class where it is written that the class represents "a slot that needs to
> be filled for a certain syntactic or *semantic* structure"; I'm not sure
> whether this was meant or whether is a typo, because it implies that
> syntactic and semantic arguments are essentially the same, and therefore
> what's the point of having two separate classes? Also the
> ObjectProperty:Marker description is said to indicate the marker of a
> semantic argument, but then its domain is listed as "Syntactic Argument".
>
> As to John's last email...I think there is a tension here between how you
> normatively expect the model to be utilised (how it was designed to be
> used) and how researchers who are used to working with semantic and
> syntactic arguments as two separate kinds of theoretical entity will mostly
> likely want to use it (which IMO will be more like LMF). On the other hand,
> I think you explained the thinking behind your design for the model quite
> well in a previous email -- the one where you compared Models A to D. It
> would be useful to have something like this in the specfications, a
> paragraph explicitly addressing and explaining this design decision, albeit
> briefly, and giving some theoretical background.
>
> Cheers,
> Fahad
>
> On 11 June 2015 at 17:29, John P. McCrae <jmccrae@cit-ec.uni-bielefeld.de>
> wrote:
>
>> 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
>>>
>>
>>
>


-- 
Manuel Fiorelli