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

Bill Dickinson dickinsw at verizon.net
Sun Jan 6 21:53:56 PST 2008


But it is possible to integrate uncertainty by using (importing) PR-OWL (a 
probabilistic upper ontology) into your project.  Check out the work of 
Kathryn Laske and Paulo da Costa - they offer PR-OWL, an OWL upper ontology 
based on their probabilistic reasoning work.  There are others that employ 
Bayesian nets.  I would attach the papers here but I don't know if that's 
allowed.


Bill Dickinson
----- Original Message ----- 
From: "Thusitha Mabotuwana" <thusitha at cs.auckland.ac.nz>
To: <protege-owl at lists.stanford.edu>
Sent: Sunday, January 06, 2008 10:55 PM
Subject: Re: [protege-owl] Get inferred property values


> "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" -
>
> I wonder if ongoing work such as:
> 1. f-SWRL: A Fuzzy Extension of SWRL -
> www.image.ece.ntua.gr/php/savepaper.php?id=407 and
> 2. Uncertainty and the Semantic Web -
> http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=1705434&isnumber=35989
>
> will be of any help? In the 1st ref. I don't quite understand the
> logic, but the
> examples in Section 4 certainly look like something I'd like to
> consider at some
> stage for my work.
>
>
>
>
>
> Quoting Thomas Russ <tar at ISI.EDU>:
>
>>
>> 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
>>
>
>
>
> _______________________________________________
> 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
> 




More information about the protege-owl mailing list