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] hasValue restriction on owlclass doesn't fill in individual property value in protégé

Pas Filip pasfilip at gmail.com
Sat Oct 18 05:58:32 PDT 2008


Thanks a lot for the provided info it does make sense what you explain.
The thing is that i'm using owl api and wasn't using the reasoner to
retrieve the property values.
I've updated the application to retrieve the property values through the
reasoner and now I get all the property values
I was expecting to receive for a given individual.

Thanks again for the info!

On Fri, Oct 17, 2008 at 6:32 PM, Thomas Russ <tar at isi.edu> wrote:

>
> On Oct 17, 2008, at 3:50 AM, Pas Filip wrote:
>
> > Hello,
> >
> > I get some behavior using protégé which I don't really understand.
> > Can someone explain why it works the way it does?
> >
> > I define 2 classes: someClass and typeClass
> > I define a couple of individuals of typeClass.
> > (Type1,Type2,Type3,Type4)
> > I restrict all of the possible values of typeClass to the
> > enumeration of individuals of typeClass.
> > I define an object property hasTypeClass which is set on someClass
> > and has range any typeClass.
> > Then I define someClass1, someClass2, someClass3, someClass4. each
> > of these someClasses gets an additional restriction hasTypeClass
> > Type1, hasTypeClass Type2 etc...
> >
> > Now when I go to the individuals pane and create a new Individual
> > the field hasTypeClass  for the individuals
> > (someClass1,someClass2,someClass3,someClass4)  is not editable,
> > marked in red and shows the respective value (Type1,Type2,Type3 or
> > Type4).
> > After this I save the ontology and I check out the xml and notice
> > that there are no values set for the relation hasTypeClass on the
> > individuals (of class someClass1,etc...).
>
> That is because the value is not set as an explicit assertion, but is
> rather derived through inference.  As such, adding an explicit
> assertion would be at best redundant and at worst could lead to
> inconsistencies as you continue to edit the ontology (see below for
> more details).
>
> > What is the reason for this that It's impossible to fill in the
> > value through the editor? To actually fill in the value I have to :
> > a) Change the owl xml file manually.
> > b) remove the restrictions from the classes temporarily, then create
> > the individuals and then put the restrictions back.
>
> The editor is trying to be helpful.  Since the value is functional,
> you can only have a single value.  Since that value is determined by
> inference to already be present, and in fact is required to be
> present, there is thought to be no point in letting you edit it.  The
> only allowable correct value is already there.
>
> > Is there some workaround I should be using instead for this, why is
> > the behavior implemented like this?
> > I would expect that if I say all individuals of someClass1 must have
> > Type1 for property hasTypeClass that protégé would update the
> > individuals that have been created unde someClass1.
>
> The reason for not propagating the inferred values into explicit
> assertions in the OWL file is that it makes updating easier.  Since
> there isn't any method of showing that the value assertions were the
> result of inference, if one were to modify the ontology by, say,
> removing or changing the restriction on the class, then you would get
> an inconsistent ontology -- because the new inferred value would
> conflict with the explicitly asserted value.
>
> So, the general principle is to keep the asserted and the inferred
> information separate, and not to (generally) save the inferred
> information in the OWL source file.  It appears that you can force the
> assertion of inferred information by running the appropriate reasoning
> request and then selecting the results in the classification results
> pane and using the tool bar to assert the inferences.  I don't know if
> this will affect instances in response to hasValue restrictions.  A
> quick look seems to indicate it doesn't....
>
> Anyway, it isn't clear that you really need to do that, anyway.
>
> Is this problem stopping you from getting a program working?
>
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/protege-owl/attachments/20081018/19f3e405/attachment.html>


More information about the protege-owl mailing list