Re: Issues about the semantics of the ontology-lexicon interface [was: Re: Why not to shortcut the "sense" object]

Hi all,

Concerning the property names, I'm ok with both LexicalEntry – meaning –>
> Sense, and with Sense – representedBy –> OntologyEntity.
> Maybe we could get rid of multiple related uses of the "mean" notion,
> which can be somehow disturbing: Meaning as a class, meaning as a property
> between lexical entries and senses, means as a property between lexical
> entries and ontology entities … it may look like we are playing with words
> … what about following the conventional naming patterns that employs the
> name of the property range? E.g. LexicalEntry – sense –> Sense
> ; LexicalEntry – meansOntologyEntity –> OntologyEntity. The advantage of
> using this apparently redundant naming is that at the instance level, the
> triple become very clear, e.g. Saxophone – sense –>
> wordsense-saxophone-1 ; Saxophone – hasOntologyEntity –> music:Saxophone.
> I also prefer "representedBy" to "characterizes", because the second is
> very generic and not attested in any related literature.
>
We should collect options for naming properties and discuss their relative
pros + cons... and then vote on them.


>
> ---Property chaining over senses---
> Secondly, I agree with the decision to add a property chain in the model,
> which helps resolving the indirection produced by the Sense class: this is
> a good practice (a logical design pattern), used in many contexts. I do not
> see room for John's criticism about it: it does not increase the cognitive
> complexity (on the contrary, it facilitates the use of the model for those
> reluctant to catch on the sense-ontology-entity distinction),
>
Of course it adds computational complexity! It requires that some users
learn an extra property name and the property chain axiom associated with
it... that is computationally complex.
 and the added computational complexity only holds when a DL reasoner
materializes the ABox.
I am assuming that not all consumers of the model are required to
implement/utilize a DL reasoner to interpret the model. This seems would be
quite a strong requirement, and works against the "lexical linked data" use
case. I have yet to see any other need for such a requirement and would not
be keen to introduce it here.

Consider if you will a sort of "reduction ad absurdum" proof... if there is
no "cost" to introducing a property chain, then every model should
introduce every forseeable property chain... which is why if we have
ontolex:translation we need ontolex:translationOfAntonym and
ontolex:antonymOfTranslationOfHypernym etc...  XX => *We should consider
what the costs are of every decision in the model and evaluate if they are
worthwhile!*

I apologize for digging my heels in at such an early stage, but (I feel) it
is important to keep elegance in the model and avoid hacks that may come
back to bite us.

Regards,
John


> ---GCIs on ontology hierarchies---
> Finally, a comment about Guido's observation that "cat#1 INSTANCEOF
> (Sense AND characterizes ONLY Animal)" is the right formalization for an
> example of the representedBy object property values. If I understand well,
> here we have two important issues. The first one can be solved by using
> OWL2, the second poses a more difficult challenge.
> For the first issue, I think that Guido talks about OWL1, but anyway that
> axiom would give us a misinterpretation, because it would tell us that
> cat#1 is a sense that can only be represented by *individuals* from the
> class Animal, which is not what Guido wants I guess. This problem was
> described in detail by W3C SWBPD committee in 2004, and eventually some
> OWL1 solutions were recommended in the "Classes as values" design pattern. However,
> in OWL2 (lucky us) punning makes our lives easier, and a simple (partial!)
> solution is (in Manchester syntax) "cat#1 TYPES (Sense AND representedBy
> VALUE Animal)".
> For the second issue, Guido points out that there are cases in which we
> need to refer to generic subclasses of an ontology entity (if it's a
> class): this cannot be expressed in OWL at all, since we cannot use the OWL
> vocabulary in the position for the domain vocabulary, In other words, the
> following is a wrong axiom even in OWL2: "cat#1 TYPES (Sense AND
> representedBy (subClassOf VALUE Animal)".
> A viable design pattern is to create a property for meaning hierarchies,
> in the vein of skos:broader or wordnet:hypernym, so that we could declare
> e.g.: "cat#1 TYPES (Sense AND representedBy ([skos:broader] VALUE Animal)"
> .
> However, a property like skos:broader typically applies to concepts, and
> senses would probably be compatible. Much less are ontology entities
> compatible, even though SKOS seems to suggest a loose correspondence
> between concepts and rdfs/owl classes. In particular, we should materialize
> ontology class hierarchies as skos:broader hierarchies in order to reason
> over these constructs.
> Another design pattern might resort to a specialized property, such as
> "broadlyRepresentedBy", e.g.: "cat#1 TYPES (Sense AND
> broadlyRepresentedBy VALUE Animal)". "broadlyRepresentedBy" can be
> a super property of representedBy. Of course, with this second pattern, we
> would lose the sophisticated DL reasoning that one can get with the first.
> Nonetheless, the second seems more practical and simple to apply for
> different levels of expertise.
>
> Ciao
> Aldo
>
>  _____________________________________
>
> Aldo Gangemi
> Senior Researcher
>  Semantic Technology Lab (STLab)
> Institute for Cognitive Science and Technology,
> National Research Council (ISTC-CNR)
> Via Nomentana 56, 00161, Roma, Italy
> Tel: +390644161535
> Fax: +390644161513
> aldo.gangemi@cnr.it
> http://www.stlab.istc.cnr.it
> http://www.istc.cnr.it/people/aldo-gangemi
> skype aldogangemi
> okkam ID: http://www.okkam.org/entity/ok200707031186131660596
>
> On Oct 12, 2012, at 6:55 PM, John McCrae <jmccrae@cit-ec.uni-bielefeld.de>
> wrote:
>
> 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)****
>>
>
>
>

Received on Monday, 15 October 2012 15:31:28 UTC