- From: Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de>
- Date: Thu, 18 Jun 2015 00:27:35 +0200
- To: Fahad Khan <anasfkhan81@gmail.com>, "John P. McCrae" <jmccrae@cit-ec.uni-bielefeld.de>
- CC: Manuel Fiorelli <manuel.fiorelli@gmail.com>, "public-ontolex@w3.org" <public-ontolex@w3.org>
- Message-ID: <5581F457.3090202@cit-ec.uni-bielefeld.de>
Dear Fahad, all, summarizing my position here: SyntacticArguments and SemanticArguments are different things intensionally, no doubt. SemanticArguments are all those things that are in the range of semArg (that is are arguments of a SemanticFrame) SyntacticArgument are all those things that are in the range of synArg (that is are arguments of a SyntacticFrame) In principle, I think it would have been appropriate to add the LMF SynsemCorrespondence construction between syntactic and semantic arguments, but this is unnecessary overhead and is extremely verbose. Thus, for pragmatic reasons, we have opted in the model for mapping syntactic arguments and semantic arguments together by instantiating them with the same individual. So we have individuals that at the same time play the role of syntactic and semantic arguments and essentially are thus there to bind them together. One can see this as a way to implement the SynsemCorrespondence in LMF in a very concise way. I do not think there is an issue with having them intensionally separate but extensionally coincident... The "morning star" and the "evening star" are intensionally different, but extensionally equivalent (in some worlds), but maybe not in all. I will correct all the smaller issues Fahad and John have identified.... Greetings, Philipp. Am 12.06.15 um 15:10 schrieb Fahad Khan: > 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 > <mailto: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 <mailto: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 <mailto: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 > <mailto: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 >>> <mailto: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 <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 <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 > > > > > -- > Manuel Fiorelli > > > > > -- > Manuel Fiorelli > > > -- -- 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 Wednesday, 17 June 2015 22:28:11 UTC