(Irene) > By this I mean if a resource will be asserted or inferred to be a member of > both classes, > there will be a consistency violation even if there is only one disjoint > statement. Understood. Thank you.
(Scott) > Composer will suppress some redundant triples (you can turn this off > by choosing the Complete Mode box in Configure Inferencing...). Thank you. Regards, Anthony On Nov 5, 1:42 pm, Scott Henninger <[EMAIL PROTECTED]> wrote: > Irene's statements are correct. The disjoint classes OWL standard > states that "It guarantees that an individual that is a member of one > class cannot simultaneously be an instance of a specified other > class." Asserting that a class is disjoint with another is sufficient > to ensure this reasoning. However, it does no harm to manually assert > the inverse disjoint class. E.g. the semantics of 'Male > owl:disjointWith Female' is the same as 'Female owl:disjointWith > Male'. > > Composer will suppress some redundant triples (you can turn this off > by choosing the Complete Mode box in Configure Inferencing...). This > has no effect in this case, but may be necessary to display other > types of inferences. > -- Scott > > On Nov 5, 12:04 pm, "Irene Polikoff" <[EMAIL PROTECTED]> wrote: > > > > > <Then if I understand you correctly one is required to assert both the > > Male->Female and Female->Male disjointedness.> > > > Only if having both assertions is (for whatever reason) important to your > > application. > > > As far as the inferencer is concerned, I believe all the appropriate > > reasoning will work without having both. By this I mean if a resource will > > be asserted or inferred to be a member of both classes, there will be a > > consistency violation even if there is only one disjoint statement. > > > Irene Polikoff > > Executive Partner, TopQuadrant > > tel: 914-777-0888/ cell: 914-329-8576www.topquadrant.com > > > -----Original Message----- > > From: [email protected] > > > [mailto:[EMAIL PROTECTED] On Behalf Of > > SemanticsQuest > > Sent: Wednesday, November 05, 2008 12:50 PM > > To: TopBraid Composer Users > > Subject: [tbc-users] Re: TBC loses <owl:disjointWith> inferrence > > > Scott, > > > Thanks for the reply. > > > > Pellet and SwiftOWLIM, for example, do not make this inference... > > > ...This is now resolved by relying on the reasoner for inferences. > > Then if I understand you correctly one is required to assert both the > > Male->Female and Female->Male disjointedness. > > > Perhaps this next comment is best left for the Pellet user group. > > However, I will make it here in the interest of completeness for this > > thread, and I appreaciate feedback from TBC forum memebers. I find it > > unusual that a logic-based reasoning engine would not infer that Female is > > disjoint with Male when the Male->Female disjointedness is asserted. How > > could there be any other logical conclusion? > > > Thanks. > > > Regards, > > > Anthony > > > On Nov 5, 10:38 am, Scott Henninger <[EMAIL PROTECTED]> > > wrote: > > > Anthony; Yes this is a known issue for the versions of TBC you > > > mention. The next release of TBC will address this and other issues > > > by not making "trivial" inferences such as owl:inverseOf, making > > > symmetric properties inverse of itself, synchronizing domain and range > > > of inverse properties, disjointness, etc. The overall decision is to > > > leave inferences to the reasoning engines Composer interfaces with. > > > The inference that all named class has at least one named superclass > > > (e.g. owl:Thing) will be retained. > > > > In this case, while one could expect that if we assert 'Male > > > owl:disjointWith Female' that 'Female owl:disjointWith Male' will be > > > inferred. Pellet and SwiftOWLIM, for example, do not make this > > > inference. Hence the problem you cite. Composer makes the inference, > > > the reasoner does not, and when the inferences are retracted, Composer > > > has trouble knowing which inferences to retract. This is now resolved > > > by relying on the reasoner for inferences. > > > > In terms of reasoning with owl:disjointWith, the key is that it > > > defines that an instances cannot be a member of disjoint classes. > > > Stating disjointness only needs to be done once. > > > -- Scott > > > > On Nov 5, 8:04 am, SemanticsQuest <[EMAIL PROTECTED]> wrote: > > > > > Hello, everyone. > > > > > I tested this with TBC versions 2.5.3 & 2.6.2, and the behavior is > > > > the same. > > > > > There are 2 classes: Male and Female. Male is asserted to be > > > > disjoint with Female. > > > > > Once I assert the Male to Female disjointedness relation, TBC > > > > automatically infers a Female to Male disjointedness relation, as > > > > expected. It does not yet appear in the Inference panel, which is > > > > also expected. After I run the Pellet inference engine, the Female > > > > to Male disjointedness relation appears in the Inference panel, as > > expected. > > > > > Here's where it becomes problematic. > > > > > Once I reset the inferences, the inferred Female to Male > > > > disjointedness relation disappears both from the Female Class Form > > > > and the Inference panel, as expected. Unfortunately, when I re-run > > > > the Pellet inference engine the Female to Male disjointedness > > > > relation appears neither in the Female Class Form nor the Inference > > > > panel, which is not expected. > > > > > The aforementioned inferrence is "lost". > > > > > I'd appreciate your feedback. > > > > > Regards, > > > > > Anthony- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/topbraid-composer-users?hl=en -~----------~----~----~----~------~----~------~--~---
