<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-8576
www.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
-~----------~----~----~----~------~----~------~--~---

Reply via email to