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] Get inferred property values

Thomas Russ tar at ISI.EDU
Fri Jan 4 18:36:35 PST 2008

On Jan 4, 2008, at 12:47 PM, SAPI wrote:

> Sorry for my long holiday break, coming back to my original  
> questions, the
> ontology consists of disease which hasSyndromes, Syndrome  
> hasSymptoms, it is
> easy to construct a demo, for example, to show people how to infer the
> Syndrome based on instances of hasSymptoms , but beyond that I am  
> struggling
> with some very basic issues to make it a useful tool for real  
> diagnosis:
> 1. How to infer from an instance-based ontology rather than a class- 
> based
> ontology: Judging from Thomas's response it seems that you must put
> everything into the class as N&S conditions,

Well, you need N&S conditions if you want to use the standard DL  
reasoning tools to be able to infer membership.  That's what the tools  
use for their inference, so in the absence of any such definitions,  
there isn't really anything for them to infer.

This doesn't stop you from constructing your own reasoner, and you  
would need to do so if you can't formulate the problem using the  
constructs that the standard OWL reasoners use.  Now, if you go beyond  
OWL a bit (i.e., SWRL), you will get a little bit more leverage, but  
then instead of writing N&S conditions you need to write (horn)  
implication rules instead.

> but in my case, the user would
> be expected to pick the correct instances of symptoms and then  
> clicking a
> button would do the reasoning to get the possible syndromes, he  
> would then
> decide what syndrome this should be.

It's not clear what the "do the reasoning" button is supposed to be  
connected to.  If this is a standard DL reasoner like Pellet, Racer,  
Fact, etc., then you won't get "possible syndromes", since the  
reasoning is always strict.  You will get EXACTLY the syndromes whose  
definitions are satisfied by the collection of symptoms.  There isn't  
any user input to this, since the results follow inexorably from the  
application of strict logical definitions.

Further below, I speak a bit more about reasoning methods.

> His experience would then be used for
> other doctors to infer as well, but it seems that we must convert  
> this to
> classes N&S conditions before this exp can be used.

It seems that this is more something that one would use during system  
development rather than in normal system operation.

> 2. DL logic is very rigid: This means I cannot model in an instance- 
> based
> ontology saying tha Bronchitis Syndrome A hasSymtoms Cough AND  
> (green phelgm
> OR yellow phelgm); then Synd B hasSymtoms Cough AND (no phelgm or  
> white
> phelgm), you must resort to those N&S conditions again to properly  
> define
> this.

It seems to me that that your statement

    Bronchitis Syndrome A (presumably a class)
         has Symptoms Cough AND (green phlegm or yellow phelgm)

is precisely the N&S conditions that you seem to be struggling with.   
You create a class definition that would look (in pseudo DL) like:

       <=>  hasSymptom someValuesFrom Cough
            AND  hasSymptom someValuesFrom (union Green_Phlegm  

negation is a bit trickier to get into the mix, partly because of the  
lack of a class for the no-phelgm result and partly (on the reasoning  
side) due to the open-world reasoning, which makes negation hard to  
prove.  You would have to resort to an explicit entry of all of the  
non-observed symptoms, which can be a bit tedious.

> 3. There is no tool to transfer from a relational DB or spreadsheet  
> to class
> based ontology; played with Datamaster but very limited in its  
> flexibility
> in mapping the import from which column to which class
> This is the third time I started from scratch developing the same  
> ontology,
> so I must get it right this time; the first 2 times failed as not  
> enough
> time was spent on how to get the information out or how to use the  
> ontology
> (reasoning requirements); protege seems to be very good in putting  
> in the
> information but not easy to get it out. Its a new field to me and I  
> am not
> sure if I miss anything here or there is a better tool out there, or  
> would
> putting the conditions into the rules engines helps (e.g. SWRL) or I  
> have to
> learn the OWL API to do what I want??

Well, as for reasoning, what you want to be looking for is a system  
that is designed to do "abductive reasoning".  OWL, DL and classical  
logic is used for "deductive reasoning", which is a different  
process.  Briefly, abductive reasoning seeks to find a set of  
plausible explanations for a set of facts.  Deductive reasoning seeks  
to infer (all?) the necessary consequences of a set of facts.  The  
"all?" is in parentheses, because, depending on the expressiveness of  
the logic and the particular reasoner, it may not be possible to get  
all of the consequences.

There has been a fair bit of research over the past 30+ years in  
building diagnostic reasoning systems, and they all generally use  
reasoning methods that are different from the standard DL tools. That  
is not to say DL tools can't help you, but you will have to augment  
the reasoning that they can provide with additional reasoning beyond  
that.  And this hasn't even begun to scratch the surface of the issues  
of uncertain and probabilistic reasoning....

> Thomas Russ wrote:
>> On Dec 14, 2007, at 7:06 AM, m. sapi wrote:
>>> Hello,
>>> I am quite puzzled by all these reasoning stuff offered by Protege
>>> OWL. I am
>>> using the 3.4 beta now, but this question probably apply to
>>> previous versions as
>>> well.
>>> First (1)what is this "Get inferred property values" when you right
>>> click an
>>> individual? it seems just repeating what is shown on the form on
>>> the right.
>>> (2) What I understand is that With class-based reasoning, I can
>>> have a class and
>>> after setting its necessary and sufficient conditions, I can right
>>> click the
>>> class then select "Get inferred subclass" or "get inferred
>>> superclass",
>>> alternatively I can do instance-based reasoning by selecting
>>> "compute individual
>>> belonging to class" or right click the individual then select
>>> "compute types",
>>> but none of these seems to be what I want. As in order to do the
>>> reasoning in
>>> the above cases, there must be a CLASS which I have defined all the
>>> conditions,
>>> this means I need to use "convert individual  to class" function to
>>> convert my
>>> instance to a class, then drag all the conditions under the
>>> "necessary" to the
>>> "sufficient" conditions, the compute types ... Is there a simpler
>>> method
>>> (without convert all indiv to class) where I can just find all
>>> other classes
>>> which had the same properties like the individual in question.
>> Well, unless your classes have definitions, there isn't really
>> anything for the reasoning system to work with.
>> You will need to define, using necessary and sufficient (N&S)
>> conditions, what is required to belong to a class.  Actually, all you
>> really need are sufficient conditions, but there isn't any direct way
>> to enter those in the Protege interface.  The closest method is to
>> create fully defined (possibly anonymous?) subclasses with N&S
>> conditions, so that satisfaction of any subclass will enable
>> recognition of class membership.
>> I'm not quite sure what the structure of your ontology is.  Assuming
>> that the classes you care about have appropriate definitions, then
>> you won't need the "convert individual to class" function.  That
>> would only be necessary if you had defined your classes as instances
>> in the first place, and now you realize that you really need them to
>> be classes.
>> You will have to make sure that the restrictions in the class
>> definitions are in the N&S position in order for recognition to take
>> place.  But the "compute individuals belonging to class" or "compute
>> types" seems exactly like the reasoning that you would want for a
>> particular case.  They will use the sufficient conditions on the
>> class definition to identify those individuals that meet the criteria
>> for the class.  This may mean that you will need to move restrictions
>> which are only under necessary conditions under N&S, though.  There
>> isn't really any way around that, since necessary conditions do not
>> allow inference about membership.  They only tell you what must be
>> true of a particular individual.
>> For example, it could be that you define having the property "weight"
>> is a necessary condition for a person.  But there are lots of other
>> things, like cows, automobiles, bricks, etc. that also have a
>> "weight" property, so clearly that is not a sufficient condition for
>> being a person.
>>> I am doing a medical diagnosis system, as I entered a new disease
>>> case with
>>> certain symptoms, I want to quickly identify what type of disease
>>> class this
>>> might possible belongs to, hopefully it might match some of the
>>> cases I have
>>> already entered, but I do not want to spend all the time converting
>>> all the
>>> previous diseases cases (individuals) to classes. Sorry if the
>>> question is not
>>> very clear.
>> I think that in particular for medical diagnosis, having multiple
>> sufficient classes which are then made subclasses of the disease/
>> diagnosis in question would be most useful.  That would then let you
>> define at a fairly fine-grained level what the minimum required set
>> of symptoms and test values are needed to fulfill the diagnosis.
>> This strikes me as better than a pure necessary & sufficient case,
>> since you may easily have situations where not ALL symptoms of a
>> particular disease are present.
>> Of course, if you try to make this a real system, rather than just
>> for demonstration, you will quickly run into the limitations of a
>> purely logic-based approach, namely the inability to handle
>> uncertainty in the reasoning.  All of the reasoning support in OWL is
>> strict in nature, so you can't have shades of meaning or uncertainty.
>>> M Sapi.
>>> _______________________________________________
>>> protege-owl mailing list
>>> protege-owl at
>>> Instructions for unsubscribing:
>>> faq.html#01a.03
>> _______________________________________________
>> protege-owl mailing list
>> protege-owl at
>> Instructions for unsubscribing:
> -- 
> View this message in context:
> Sent from the Protege - OWL mailing list archive at
> _______________________________________________
> protege-owl mailing list
> protege-owl at
> Instructions for unsubscribing:

More information about the protege-owl mailing list