Inconsistent Behavior in Protege 3.2 Build 236

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Inconsistent Behavior in Protege 3.2 Build 236

Steve Wartik
Hi,

I've come across some slot restriction behavior that's puzzling me. Try
the following:

   1. Create classes Foo and Bar, subclasses of :THING.
   2. Create class Foo-Child, subclass of Foo.
   3. Create class Foo-Grandchild, subclass of Foo-Child.
   4. Create clases Bar-Child-1 and Bar-Child-2, subclasses of Bar.
   5. Add slot s to Foo.  Make the range of s an instance of Bar.
   6. In Foo-Child, override s so the range is an instance of Bar-Child-1.
   7. In Foo-Grandchild, remove slot overrides from s. /*Issue:*/ The
      Template Slots table still displays the slot overrides.
   8. In the Template Slots table for Foo-Grandchild, select s and click
      the View Slot Overrides button.
   9. In the pop-up, click the Add Class button in the Allowed-Classes
      list. /*Issue:*/ Nothing happens.

What I would like to do is to make the range of slot s in class
Foo-Grandchild be Bar-Child-2, emulating private variables in classes.
As the steps above show, Protégé's GUI won't let me do so. My readings
of the Protégé documentation lead me to believe the two issues are in
fact the intended behavior.

However, I have observed that I can achieve my desired effect by
altering the PONT file. Protégé will happily load and save the resulting
ontology.

Either Protégé's GUI is too strict or Protégé's CLIPS parser and storage
mechanism are too lax. What's the intended model? Can someone clarify?
Thank you!

Steve Wartik


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent Behavior in Protege 3.2 Build 236

samsontu

Protege's behavior (aside from accepting things you changed in the pont
file) is correct. The behavior you want is explicitly prohibited in
Protege.

User Guide "Overriding Slot Properties at a Class"
http://protege.stanford.edu/doc/users_guide/slots/override_slot.htm
..
Overriding a slot at the class level allows you to be more restrictive
about the slot facets...

You have
Foo
   - s  allowed-class Bar
    Foo-Child
     -s allowed-class Bar-Child-1
       Foo-Grandchild
         -s  allowed-class ??

Slot overrides being "more restrictive" means allowed-class of slot s at
Foo-Grandchild *must* be Bar-Child-1 or a subclass of Bar-Child-1.

7. You can't remove, from Foo-Grandchild, the slot override at Foo-Child
because Foo-Grandchild, as a subclass of Foo-Child, must obey the
restrictions at the Foo-Child level.

9. Nothing happens because you don't have any subclass of Bar-Child-1,
so you can't restrict the range of s any further.

This behavior nicely illustrate why slots are not "private" to
individual classes, and must obey the set/subset semantics of
class/subclass relationships.

Samson


Steven Wartik wrote:

> Hi,
>
> I've come across some slot restriction behavior that's puzzling me. Try
> the following:
>
>    1. Create classes Foo and Bar, subclasses of :THING.
>    2. Create class Foo-Child, subclass of Foo.
>    3. Create class Foo-Grandchild, subclass of Foo-Child.
>    4. Create clases Bar-Child-1 and Bar-Child-2, subclasses of Bar.
>    5. Add slot s to Foo.  Make the range of s an instance of Bar.
>    6. In Foo-Child, override s so the range is an instance of Bar-Child-1.
>    7. In Foo-Grandchild, remove slot overrides from s. /*Issue:*/ The
>       Template Slots table still displays the slot overrides.
>    8. In the Template Slots table for Foo-Grandchild, select s and click
>       the View Slot Overrides button.
>    9. In the pop-up, click the Add Class button in the Allowed-Classes
>       list. /*Issue:*/ Nothing happens.
>
> What I would like to do is to make the range of slot s in class
> Foo-Grandchild be Bar-Child-2, emulating private variables in classes.
> As the steps above show, Protégé's GUI won't let me do so. My readings
> of the Protégé documentation lead me to believe the two issues are in
> fact the intended behavior.
>
> However, I have observed that I can achieve my desired effect by
> altering the PONT file. Protégé will happily load and save the resulting
> ontology.
>
> Either Protégé's GUI is too strict or Protégé's CLIPS parser and storage
> mechanism are too lax. What's the intended model? Can someone clarify?
> Thank you!
>
> Steve Wartik
>
>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>


--
Samson Tu                    email: [hidden email]
Senior Research Scientist    web: www.stanford.edu/~swt/
Stanford Medical Informatics phone: 1-650-725-3391
Stanford University          fax: 1-650-725-7944
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent Behavior in Protege 3.2 Build 236

Paul Prueitt
In reply to this post by Steve Wartik



This is lovely example.

In making the range of s an instance of Bar, does one need to create
"instances of the class Bar"?  Or is the language here misleading?

I am assuming that one can not make instances of Bar, because Bar does not
occupy the lowest position on the tree branch?

right

I have a follow up.. smiles





-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Steven
Wartik
Sent: Monday, January 23, 2006 12:37 PM
To: [hidden email]
Subject: [protege-discussion] Inconsistent Behavior in Protege 3.2 Build
236


Hi,

I've come across some slot restriction behavior that's puzzling me. Try
the following:

   1. Create classes Foo and Bar, subclasses of :THING.
   2. Create class Foo-Child, subclass of Foo.
   3. Create class Foo-Grandchild, subclass of Foo-Child.
   4. Create clases Bar-Child-1 and Bar-Child-2, subclasses of Bar.
   5. Add slot s to Foo.  Make the range of s an instance of Bar.
   6. In Foo-Child, override s so the range is an instance of Bar-Child-1.
   7. In Foo-Grandchild, remove slot overrides from s. /*Issue:*/ The
      Template Slots table still displays the slot overrides.
   8. In the Template Slots table for Foo-Grandchild, select s and click
      the View Slot Overrides button.
   9. In the pop-up, click the Add Class button in the Allowed-Classes
      list. /*Issue:*/ Nothing happens.

What I would like to do is to make the range of slot s in class
Foo-Grandchild be Bar-Child-2, emulating private variables in classes.
As the steps above show, Protégé's GUI won't let me do so. My readings
of the Protégé documentation lead me to believe the two issues are in
fact the intended behavior.

However, I have observed that I can achieve my desired effect by
altering the PONT file. Protégé will happily load and save the resulting
ontology.

Either Protégé's GUI is too strict or Protégé's CLIPS parser and storage
mechanism are too lax. What's the intended model? Can someone clarify?
Thank you!

Steve Wartik


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html



-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent Behavior in Protege 3.2 Build 236

Timothy Redmond


>
> I am assuming that one can not make instances of Bar, because Bar  
> does not
> occupy the lowest position on the tree branch?
>

This is not right.  Just because

    Bar-Child-1 \subseteq Bar

doesn't mean that there can't be members of Bar that are not in Bar-
Child-1.

--------------------------------
Timothy Redmond, PhD
Research Staff
Stanford Medical Informatics
Medical School Office Building X-215
251 Campus Drive
Stanford, CA 94305
[hidden email]



> right
>
> I have a follow up.. smiles
>
>
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Steven
> Wartik
> Sent: Monday, January 23, 2006 12:37 PM
> To: [hidden email]
> Subject: [protege-discussion] Inconsistent Behavior in Protege 3.2  
> Build
> 236
>
>
> Hi,
>
> I've come across some slot restriction behavior that's puzzling me.  
> Try
> the following:
>
>    1. Create classes Foo and Bar, subclasses of :THING.
>    2. Create class Foo-Child, subclass of Foo.
>    3. Create class Foo-Grandchild, subclass of Foo-Child.
>    4. Create clases Bar-Child-1 and Bar-Child-2, subclasses of Bar.
>    5. Add slot s to Foo.  Make the range of s an instance of Bar.
>    6. In Foo-Child, override s so the range is an instance of Bar-
> Child-1.
>    7. In Foo-Grandchild, remove slot overrides from s. /*Issue:*/ The
>       Template Slots table still displays the slot overrides.
>    8. In the Template Slots table for Foo-Grandchild, select s and  
> click
>       the View Slot Overrides button.
>    9. In the pop-up, click the Add Class button in the Allowed-Classes
>       list. /*Issue:*/ Nothing happens.
>
> What I would like to do is to make the range of slot s in class
> Foo-Grandchild be Bar-Child-2, emulating private variables in classes.
> As the steps above show, Protégé's GUI won't let me do so. My readings
> of the Protégé documentation lead me to believe the two issues are in
> fact the intended behavior.
>
> However, I have observed that I can achieve my desired effect by
> altering the PONT file. Protégé will happily load and save the  
> resulting
> ontology.
>
> Either Protégé's GUI is too strict or Protégé's CLIPS parser and  
> storage
> mechanism are too lax. What's the intended model? Can someone clarify?
> Thank you!
>
> Steve Wartik
>
>
> ----------------------------------------------------------------------
> ---
> To unsubscribe go to http://protege.stanford.edu/community/ 
> subscribe.html
>
>
>
> ----------------------------------------------------------------------
> ---
> To unsubscribe go to http://protege.stanford.edu/community/ 
> subscribe.html
>

-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent Behavior in Protege 3.2 Build 236

samsontu
In reply to this post by Paul Prueitt

Paul Prueitt wrote:

> This is lovely example.
>
> In making the range of s an instance of Bar, does one need to create
> "instances of the class Bar"?  Or is the language here misleading?

Sorry, what is the issue? I assumed, when Steve said "Make the range of
s an instance of Bar", he meant he made the value type of s INSTANCE and
the allowed class Bar. What is misleading?

>
> I am assuming that one can not make instances of Bar, because Bar does not
> occupy the lowest position on the tree branch?

You can make direct instances of Bar even if it's not the leaf of a
class tree.

>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Steven
> Wartik
> Sent: Monday, January 23, 2006 12:37 PM
> To: [hidden email]
> Subject: [protege-discussion] Inconsistent Behavior in Protege 3.2 Build
> 236
>
>
> Hi,
>
> I've come across some slot restriction behavior that's puzzling me. Try
> the following:
>
>    1. Create classes Foo and Bar, subclasses of :THING.
>    2. Create class Foo-Child, subclass of Foo.
>    3. Create class Foo-Grandchild, subclass of Foo-Child.
>    4. Create clases Bar-Child-1 and Bar-Child-2, subclasses of Bar.
>    5. Add slot s to Foo.  Make the range of s an instance of Bar.
>    6. In Foo-Child, override s so the range is an instance of Bar-Child-1.
>    7. In Foo-Grandchild, remove slot overrides from s. /*Issue:*/ The
>       Template Slots table still displays the slot overrides.
>    8. In the Template Slots table for Foo-Grandchild, select s and click
>       the View Slot Overrides button.
>    9. In the pop-up, click the Add Class button in the Allowed-Classes
>       list. /*Issue:*/ Nothing happens.
>
> What I would like to do is to make the range of slot s in class
> Foo-Grandchild be Bar-Child-2, emulating private variables in classes.
> As the steps above show, Protégé's GUI won't let me do so. My readings
> of the Protégé documentation lead me to believe the two issues are in
> fact the intended behavior.
>
> However, I have observed that I can achieve my desired effect by
> altering the PONT file. Protégé will happily load and save the resulting
> ontology.
>
> Either Protégé's GUI is too strict or Protégé's CLIPS parser and storage
> mechanism are too lax. What's the intended model? Can someone clarify?
> Thank you!
>
> Steve Wartik
>
>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>
>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>


--
Samson Tu                    email: [hidden email]
Senior Research Scientist    web: www.stanford.edu/~swt/
Stanford Medical Informatics phone: 1-650-725-3391
Stanford University          fax: 1-650-725-7944
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html