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

SAPI m59sapi at yahoo.com
Sun Jan 6 20:31:37 PST 2008


I really appreciate your detailed feedback. Abductive reasoning is something
new to me which I would explore further. For now, I like to do something
simple, also no probabilistic or uncertainty handling should be required;
what I am thinking is a 'simple' system which help doctor quickly do the
diagnosis with a few mouse clicks. This might be a system development
project, as you have pointed out. There are a few thousand symptoms in the
database, but typing in 'bronc" would retrieve only the relevant symptoms
for bronchitis, which might be less than 10, so he can check whichever
symptoms which is applicable for the current patient, which should be a few
mouse clicks without having to write DL logic (N&S conditions), the symptoms
he picked (say sym A, C & E) will then be used to retrieve all the past
instances of diagnosis which contains A,C&E, so he might get ABCDE or ABCE
or ACDE which points to 3 different syndromes of bronchitis, this can be
done very easily in SQL query but not thru an owl reasoner. He can then pick
whatever syndrome as his diagnosis and then drill down to the treatment for
this syndrome. He might also want to unchecked one of symptoms (say E which
might represent hasTemperature as the patient's temp is only slightly higher
than normal), he do the query again to find out all syndromes contain A&B
only. Given the fact DL logic is very rigid, but if the GUI allows him to
play with the parameters and quickly identify the possible inference, then
it is still quite helpful to the doctor. But we cannot expect the doctor to
write the N&S conditions like:
   
Bronchitis_Syndrome_A
       <=>  hasSymptom someValuesFrom Cough
            AND  hasSymptom someValuesFrom (union Green_Phlegm  
Yellow_Phlegm)

I would expect a lot of people are using protege as a knowledge acquisition
AND REASONING tool would encounter similiar problems would share how they
have progress into a practical tool

SAPI


Thomas Russ wrote:
> 
> 
> 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:
> 
>     Bronchitis_Syndrome_A
>        <=>  hasSymptom someValuesFrom Cough
>             AND  hasSymptom someValuesFrom (union Green_Phlegm  
> Yellow_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....
> 
>>
>>
>> SAPI
>>
>>
>> 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 lists.stanford.edu
>>>> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>>>>
>>>> Instructions for unsubscribing: http://protege.stanford.edu/doc/
>>>> faq.html#01a.03
>>>
>>> _______________________________________________
>>> protege-owl mailing list
>>> protege-owl at lists.stanford.edu
>>> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>>>
>>> Instructions for unsubscribing:
>>> http://protege.stanford.edu/doc/faq.html#01a.03
>>>
>>>
>>
>> -- 
>> View this message in context:
>> http://www.nabble.com/Get-inferred-property-values-tp14347025p14624642.html
>> Sent from the Protege - OWL mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> protege-owl mailing list
>> protege-owl at lists.stanford.edu
>> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>>
>> Instructions for unsubscribing:
>> http://protege.stanford.edu/doc/faq.html#01a.03
> 
> _______________________________________________
> protege-owl mailing list
> protege-owl at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
> 
> Instructions for unsubscribing:
> http://protege.stanford.edu/doc/faq.html#01a.03 
> 
> 

-- 
View this message in context: http://www.nabble.com/Get-inferred-property-values-tp14347025p14658706.html
Sent from the Protege - OWL mailing list archive at Nabble.com.




More information about the protege-owl mailing list