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 - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
