- From: Armando Stellato <stellato@info.uniroma2.it>
- Date: Mon, 15 Oct 2012 13:03:23 +0200
- To: "'Guido Vetere'" <gvetere@it.ibm.com>
- Cc: "'public-ontolex'" <public-ontolex@w3.org>, "'Armando Stellato'" <stellato75@gmail.com>
- Message-ID: <03ca01cdaac4$b3357770$19a06650$@uniroma2.it>
Hi Guido, in effect the point is that the property would be an object property, with no range restriction. And this would be ok in OWL 2, thanks to punning. The fact that OWL 2 Direct Semantics would treat the different uses of the same name as different objects (as a DL reasoner would require) should not be a problem, as a separate “semantic” (wrt the semantics of the ontology) description of a concept (through a class) and of its connection to language (handling that class name as a separate individual) should not be a problem. This is pretty similar to skos-xl pref/alt/hidden labels (with an inverted pattern, as the described ontology entity is in the subject), as these are object properties with a defined range (the skos-xl:Label) but no constraints on the domain1. Obviously, being an object property, prevents literals to be linked to it (well, in current RDF, literals cannot be subjects of a triple in a any case, but this is helpful for us, as we need to constrain the non-use of literals in the range). Btw, is there a reason we prefer to have the: Lexical Entry -> meaning -> Sense -> representedBy -> OntologyEntity pattern and not the inverse one? That is OntologyEntity -> represents -> Sense -> lexicalEntry -> Lexical Entry (names here do not matter) I would suppose it is because we want to see language as an entry to an ontology, but don’t if this has been argumented previously, or if it needs argumentation at all J Cheers, Armando 1 in skos/skos-xl, a concept (ideally seen as the subject of labeling properties in skos) is an individual wrt the OWL vocabulary, however, both skos and skos-xl labeling properties are meant to be used widely also in OWL From: Guido Vetere [mailto:gvetere@it.ibm.com] Sent: Friday, October 12, 2012 11:09 PM To: Armando Stellato Cc: 'public-ontolex'; Armando Stellato Subject: RE: Why not to shortcut the "sense" object Armando, I assumed a DL (e.g. a language of the OWL family) as the logic backbone of the model, and interpreted arrows as domain\range restrictions on roles (properties). Maybe I was wrong. But if the backbone is RDF, then I'm fuzzy about what arrows\resources represent. Sorry for asking such a basic question, but how is it? Guido Vetere Manager, Center for Advanced Studies IBM Italia _________________________________________________ Rome Trento Via Sciangai 53 Via Sommarive 18 00144 Roma, Italy 38123 Povo in Trento, Italy +39 (0)6 59662137 +39 (0)461 312312 Mobile: +39 3357454658 _________________________________________________ "Armando Stellato" <stellato@info.uniroma2.it> Sent by: Armando Stellato <stellato75@gmail.com> 12/10/2012 18:35 To Guido Vetere/Italy/IBM@IBMIT, "'public-ontolex'" <public-ontolex@w3.org> cc Subject RE: Why not to shortcut the "sense" object >From what I got, and hope not to be wrong (it’s useful also for me to clarify as I missed a couple of calls on September), OntologyEntity is a generic rdf:Resource of one of the main entities in the main vocabularies (aka: OWL and SKOS, thus: property, class, individual, skos concept…). Another question to John from my side: from your email it seemed to be against stating the propertyChain axiom on (means, <meaning,representedBy>) implying that the direct Entry ---means--> OntologyEntity from "Lexical Entry -> meaning -> Sense -> representedBy -> OntologyEntity" but then the sentence: “Here the difference is 1 named elements vs. 3 named elements, but as stated above, at least half of users (data consumers) will have to understand all 4 names...” instilled some doubt in my interpretation… Are you voting against the larger structure as a whole (thus keeping only the Entry ---means--> OntologyEntity structure), or against the propertyChain axiom? I really got the second, though I’m not even sure how adding the p.chain axiom (or not doing it) would change anything for the user or consumer. I’m sure I’m missing something, so sorry in advance for my potential misinterpretation. Have a nice we! Armando From: Guido Vetere [ <mailto:gvetere@it.ibm.com> mailto:gvetere@it.ibm.com] Sent: Friday, October 12, 2012 6:08 PM To: public-ontolex Subject: Re: Why not to shortcut the "sense" object All, I apologize for missing the call today. Here just some short remark. "Entry ---means--> OntologyEntity" means that if you want to predicate on the meaning relationship (e.g. to associate some grammatical constraint) you have to resort on a meta predicates (e.g. OWL Annotations). "Lexical Entry -> meaning -> Sense -> representedBy -> OntologyEntity" sounds good, but instead of 'representedBy' I would say 'characterizes' or something alike, meaning that a linguistic sense gives a (cultural) shape to an entity. Moreover, it is not clear to me (maybe you discussed about that) whether OntologyEntity is a first order TOP concept (e.g. equivalent to OWL Thing). In this case, note that in order to tell that the instance of Sense 'cat#1' (i.e. the first sense of the lemma 'cat') represents an Animal, you have to write something like: cat#1 INSTANCEOF (Sense AND characterizes ONLY Animal). Is it correct? If there is something that I can do, please let me know. Regards, Guido Vetere Manager, Center for Advanced Studies IBM Italia _________________________________________________ Rome Trento Via Sciangai 53 Via Sommarive 18 00144 Roma, Italy 38123 Povo in Trento, Italy +39 (0)6 59662137 +39 (0)461 312312 Mobile: +39 3357454658 _________________________________________________ John McCrae < <mailto:jmccrae@cit-ec.uni-bielefeld.de> jmccrae@cit-ec.uni-bielefeld.de> Sent by: <mailto:johnmccrae@gmail.com> johnmccrae@gmail.com 12/10/2012 16:35 To public-ontolex < <mailto:public-ontolex@w3.org> public-ontolex@w3.org> cc Subject Why not to shortcut the "sense" object Hi all, As discussed today in the telco there is a proposal to introduce a shortcut replacing "Entry ---sense--> Sense ---representedBy--> OntologyEntity" with "Entry ---means--> OntologyEntity", while this is theory sounds good, I contend that in practice it is not worth the effort. (This is based on practical experience with the lemon model). * It does not make the model easier to use: It is clear that for data producers this proposal simplifies the matter (as less links and URIs are required), however for data consumers it complicates the models (as they need to understand both methods of linking and be able to infer equivalence between the two methods). Thus, if EaseOfUse = (% of Consumers) × EaseOfUse(Consumer) + (% of Producers) × EaseOfUse(Producer), hence if we assume there will be approx. as many producers as consumer then we need only ask is it worth "is the extra effort for the producer less than that for the consumer", i.e., "would you rather implement a system that infers similarity across multiple representations, or use extra links and URIs"? * It does not make the model easier to understand: While, I understand that the sense object is nebulous and difficult per se to understand, I would still argue that the clearest measure of how easy to understand a model is, is the number of named elements it has (as many users may not need to deeply understand the meaning of a sense, but be happy to know that "translation", "antonymy" and "register" go there). Here the difference is 1 named elements vs. 3 named elements, but as stated above, at least half of users (data consumers) will have to understand all 4 names... if we assume out of the producers 70% do not need to represent senses (and thus any associated properties, "translation", "antonymy", "register") then the average number of links a user will need to understand is 4 × 0.5 + 3 × 0.5 × 0.3 + 1 × 0.5 × 0.7 = 2.8... so it makes the model all of 7% easier to understand! Worse, this figure is overgenerous as: I expect there to more data consumers than producers and I expect at least 50% of users to require sense modelling. Regards, John IBM Italia S.p.A. Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI) Cap. Soc. euro 347.256.998,80 C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153 Societą con unico azionista Societą soggetta all’attivitą di direzione e coordinamento di International Business Machines Corporation (Salvo che sia diversamente indicato sopra / Unless stated otherwise above) IBM Italia S.p.A. Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI) Cap. Soc. euro 347.256.998,80 C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153 Societą con unico azionista Societą soggetta all’attivitą di direzione e coordinamento di International Business Machines Corporation (Salvo che sia diversamente indicato sopra / Unless stated otherwise above)
Received on Monday, 15 October 2012 11:04:03 UTC