Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-owl] HOW: Show/query/assert deduced facts in Protege?

Timothy Redmond tredmond at
Thu Jan 31 15:57:34 PST 2008

On Jan 30, 2008, at 11:28 AM, Johann Petrak wrote:

> I never got an answer to my email "Assert deduced inverse properties?"
> on this list, so I try again, stating the question in a bit more
> general way:

I apologize for our absence on this list.  The group has been a little  
overwhelmed for a bit.  Unfortunately I don't know really good answers  
to your questions.

> It is easy in Protege (I am using version 3.3.1) to use a reasoner
> to create the inferred class hierarchy and then assert some or
> all of the ingerred classes.
> It is also possible to show individuals that are inferred
> to belong to a class.
> However, there are many other things a reasoner can induce,
> e.g. from the definition of a property of having an inverse
> and the existence of prop(A,B) it will infer inverse_of_prop(B,A)


> However, I do not see a way to make Protege show this, and
> even less a way to make it assert this kind of inferred
> information.
> Am I missing something here? How has this to be done?

I don't think that you are missing anything.  My impression is that  
there is no way to make the gui show these inferences.  Protege 4 does  
have some interesting capabilities along these lines (in the DL Query  
tab) but it does not include the case that you are talking about  
(reasoning about property values of individuals).

I think that your main option here is to interact with the reasoner  
directly.  Depending on your inclinations, perhaps make a plugin and  
contribute it.

> And is there a way to do a SPARQL query on the inferred
> graph from within Protege?
> For example, if a property was defined to have an inverse
> only after that property was already asserted for individuals,
> the inverse property will not have been asserted for those ...
> when I query the ontology using the SPARQL tab, I only get
> the asserted, and the inferred inverse properties are not found.

SPARQL isn't very desirable in this context.  It is really just does  
syntactic exploration and inference is another matter.

> What is the general opinion of what should be asserted in an
> ontology that could also be inferred?
> For instance, Protege DOES assert the inverse property once
> it has been defined, although it can be inferred.
> Other things are not asserted automatically -- why?

My opinion is that an ontology editor should not show any inference  
except when it is explicitly asked for (e.g. the user invokes a  
reasoner).  The reason for this is that

(1) it is never clear when to stop (it is confusing to people who  
don't understand why Protege doesn't do X, Y, Z inferences also...) and

(2) it is the likely source of developer confusion and bugs.  For  
example, if a fact is removed you need to remember to remove the  
inferred facts but maybe they were actually asserted, etc. and

(3) each new inference slows the editor yet again.

But as a practical matter this ideal is hard to stick to.  Users often  
demand more.  Even for Protege 4, which has a very clean  
implementation, Matthew gave into user demand for the CheeseyPizza  

    CheeseyPizza = Pizza and (hasTopping some CheeseTopping)


               CheeseyPizza subClassOf Pizza

Many ontologies look very messy when this inference is not applied.


> Cheers,
>   Johann
> _______________________________________________
> protege-owl mailing list
> protege-owl at
> Instructions for unsubscribing:

More information about the protege-owl mailing list