- From: Aldo Gangemi <aldo.gangemi@cnr.it>
- Date: Fri, 8 May 2015 12:17:17 +0200
- To: Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de>
- Cc: Aldo Gangemi <aldo.gangemi@cnr.it>, Elena Montiel Ponsoda <emontiel@fi.upm.es>, public-ontolex@w3.org
- Message-Id: <0F09088E-3597-4F22-A92C-4389EBD0EE64@cnr.it>
Hi, not sure I can attend today’s telecon, some comments below. > On May 7, 2015, at 10:52:20 PM , Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de> wrote: > > Hi Elena, all, > > I try to answer your comments below... > > Regards, > > Philipp. > > Am 07.05.15 um 16:59 schrieb Elena Montiel Ponsoda: >> Dear Philipp, all >> >> We had read carefully the core module and would like to make the following comments: >> >> · Definition of LexicalEntry class: “The class lexical entry represents a single unit of analysis in the lexicon comprising a collection of forms that are morphologically related or have a single pronunciation and have the same set of meanings.” >> o Why morphologically related “or” have a single pronunciation? Isn’t the use of “or” a bit inaccurate? >> o Regarding the fact of having “a single pronunciation”, what happens with a word like “advertisement” with an American and a British pronunciation? Why should we have two lexical entries for this? In fact, the same lexical entry would be pointing to two different lexical forms with different phonetic representations, right? > > Well, exactly because of the "colour" example you mention below. The pronunciation of "colour" and "color" is the same, but they are not morphologically related, are they? We do not want to have two lexical entires, that's why we need the "OR" in the definition. > > For the case of "advertisement": it would be one entry with *one* form and two different pronunciations of this form. We can add this example if it help. Why are you implying that the definition requires to have two entries? It is one entry with one form and two pronunciations of the latter. > >> · We would like to suggest this definition: The class lexical entry represents a single unit of analysis in the lexicon comprising a collection of forms with the same set of meanings and morphologically related. > > see above >> · In the following sentence: “Lexical entries are further specialized into Word, Affix (e.g., suffix, prefix or circumfix) and MultiwordExpression for example”, we would suggest to include infix as an example of Affix and change “or” by “and”, since you are providing some examples. >> · As for the definition of Affix, we would suggest “The class affix represents is a morpheme (suffix, prefix, circumfix, etc.) that is attached to a word stem to form a new word.”, rephrasing Wikipedia… J > > That's fine. I will adopt it. >> · Below example 2, you say: “one for the British English written representation "colour" and one for the American English written representation”, we would add “color”, i.e., the American Eng. Repr. > > I do not understand, sorry. >> · General comment: The entities in ontolex.owl ontology do not have rdfs:label, is there a reason for that? In fact, we think there should be rdfs:labels in different languages. > Right, I will add the labels. Fortunately, this is not a principled problem ;-) > >> · The explanation below example 4 “Each form should have exactly one written representation per language tag, but there are no restrictions on the number of associated phonetic representations”, could be debatable… Why do we need to be so restrictive? “exactly one”? > > Yes, this is something to talk about. Agree, it is better to relax this contraint, unless we can imagine reasoning advantages from the functionality deriving from it. >> · Below OtherForm: “For example we may specify non-canonical forms of the verb ""marry"" as follows:” Double quotation marks! > > OK >> · Below example 10 : “Thus, it is not possible to specify the range of denotes in OWL”, we think that this statement is inaccurate or too categorical, since one could say owl:Thing. Moreover, in the definition of LexicalSense, the range as been defined as being owl:Thing > > owl:Thing is the class comprising all owl:individuals, it does not include classes or properties... however using a property or class as reference makes an individual technically, so probably it is fine to add the axiom. In any, case owl:Thing is the default, so we do not need to add it. I think that for this generic denotation we need rdfs:Resource rather than owl:Thing. The literature is not keen about accepting logical primitive classes as subclasses of owl:Thing by punning, because that design creates complexity issues, even with punning. > >> · Comment regarding the inclusion of properties in the core: why do we make explicit properties such as “morphologicalPattern” in the LexicalEntry class, and cannot include the property “usage” in the LexicalSense class? We think the inclusion of that property would make clearer what the purpose of having LexicalSense in the model is. For a complete categorization of the types of usages we would then be pointing to an external model… > > We can. >> · As for the Definition property you say that the domain can be a LexicalConcept or a LexicalSense, but this is neither reflected in the figure above nor in the LexicalSense and LexicalConcept descriptions. > > I added this without consulting anybody else as I understood that was a request from the community. The picture has to be updated. definition has owl:Thing in the range, but this has issues because, if a definition is a gloss, we should have a Gloss or Definition class (while there is a datatype property gloss in wordnet schema). Anyway, if so, the range should be a Gloss/Definition class. Also: what if a named graph is provided as a definition? or any other structured form in a semantic lexicon? I’d extend the range to rdfs:Resource, in order to enable any URI to work as a definition identifier. We should also explain that literals are not acceptable. An alternative is to accept literals as values for a datatype property definition, but in that case, any kind of structured definition will be referenced as a literal, not by a URI. >> · Below the class LexicalSense: “Via the lexical sense object we can attach additional properties to a pair of lexical entry and ontological predicate that it denotes to describe under which conditions (context, register, domain, etc.) it is valid to regard the lexical entry as having the ontological entity as meaning. For example, we may wish to express the usages of the word "consumption" in terms of the topic and diachronic usage of the word.”: and the ontological predicate it denotes... in terms of the topic and its diachronic usage > > What is the point here? I do not understand either >> · It is unclear why Lexicon is a subclass of void:Dataset (sorry if this has been discussed previously) > > Yes, we discussed this to be able to attach metadata properties to a Lexicon as a dataset. I agree on this choice, if a dataset can be expressed in any data model or language. Aldo >> · In LexicalConcept: there is a spelling mistake in sublcas >> >> We hope they help! >> >> Elena, Lupe & Jorge >> >> El 04/05/2015 a las 22:19, Philipp Cimiano escribió: >>> Dear all, >>> >>> the core module is now ready for the final discussion this week. Please check the current version of the specification: >>> >>> https://www.w3.org/community/ontolex/wiki/Final_Model_Specification#Core <https://www.w3.org/community/ontolex/wiki/Final_Model_Specification#Core> >>> >>> The ontologies and code of examples is available here: >>> >>> https://github.com/cimiano/ontolex.git <https://github.com/cimiano/ontolex.git> >>> >>> Please send me any final issues / changes you would like to have implemented in the specification by Thursday. >>> >>> Looking forward to our discussion on Friday! >>> >>> Access details are here, as usual: https://www.w3.org/community/ontolex/wiki/Teleconference,_2015.5.8,_16-17_pm_CET <https://www.w3.org/community/ontolex/wiki/Teleconference,_2015.5.8,_16-17_pm_CET> >>> >>> Best 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 <mailto:cimiano@cit-ec.uni-bielefeld.de> > > Office CITEC-2.307 > Universitätsstr. 21-25 > 33615 Bielefeld, NRW > Germany
Received on Friday, 8 May 2015 10:17:54 UTC