Re: Why not to shortcut the "sense" object

On Fri, Oct 12, 2012 at 6:35 PM, Armando Stellato <stellato@info.uniroma2.it
> wrote:

> 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.
>
Sorry it isn't clear: the long chain is TBMK agreed upon (Lexical Entry ->
meaning -> Sense -> representedBy -> OntologyEntity)*... we are questioning
whether we need the short chain (Entry ---means--> OntologyEntity) as well.
I say it is not worth it.

Regards,
John

* or (Word -> sense -> Sememe/Acceptation -> characterizes ->
rdf:Resource/skos:Concept/owl:Entity) or some combination of these terms.

****
>
> ** **
>
> Have a nice we!****
>
> ** **
>
> Armando****
>
> ** **
>
> ** **
>
> *From:* Guido Vetere [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 <jmccrae@cit-ec.uni-bielefeld.de>*
> Sent by: johnmccrae@gmail.com ****
>
> 12/10/2012 16:35 ****
>
> To****
>
> public-ontolex <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)
> ****
>