TemplateSlotsWidget behavior for non-:SLOT-valued slots

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

TemplateSlotsWidget behavior for non-:SLOT-valued slots

Richard Dunlap

In a metaclass :CLASS-A, :SLOT-B has multiple cardinality, value type
Instance of Class-C (if it turns out to matter, in my exact situation
there are multiple acceptable classes).  Notably, Class-C is *not* a
subclass of :SLOT.

A user builds an instance Class-A1 of :CLASS-A, and subclasses Class-A1
to Subclass-A1.  Using an appropriate slot widget, the user adds an
instance of Class-C to the list of values for Class-A1's :SLOT-B.  I
would like for that value to be inherited by Subclass-A1.

1) From a modeling perspective, is that a reasonable expectation?

2) Is there a slot widget that will allow a user to view and override
the inherited values in Subclass-A1?  The only widget I can find that
allows view and override of inherited values is the TemplateSlotsWidget
(or variations thereof) which assumes that the slot contains :SLOTs and
is a subslot of :DIRECT-TEMPLATE-SLOTS.  However, it's not appropriate
to make Class-C a :SLOT and :SLOT-B a subslot of :DIRECT-TEMPLATE-SLOTS
-- there are no associated values that should be filled in when Class-A1
is instantiated. (Trying this with the cute hack of setting Class-C's
maximum cardinality to 0 fails to eliminate the field from the instance
form for Class-A1, though it *does* correctly forbid a value from being
filled in.)

Assuming the answer to (1) is yes and (2) is no, a clear next step is to
write a slot widget along the lines of TemplateSlotsWidget to handle
inheritance and overrides.  I'm not too concerned about taking that step
-- just trying to keep from reinventing something.

Thanks!

-- Dr. Richard Dunlap
    Applied Systems Intelligence, Inc.

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

Reply | Threaded
Open this post in threaded view
|

Re: TemplateSlotsWidget behavior for non-:SLOT-valued slots

Richard Dunlap

Richard Dunlap wrote:

> In a metaclass :CLASS-A, :SLOT-B has multiple cardinality, value type
> Instance of Class-C (if it turns out to matter, in my exact situation
> there are multiple acceptable classes).  Notably, Class-C is *not* a
> subclass of :SLOT.
>
> A user builds an instance Class-A1 of :CLASS-A, and subclasses Class-A1
> to Subclass-A1.  Using an appropriate slot widget, the user adds an
> instance of Class-C to the list of values for Class-A1's :SLOT-B.  I
> would like for that value to be inherited by Subclass-A1.
>
> 1) From a modeling perspective, is that a reasonable expectation?
>

Following up on my own question; I just had the epiphany that -- no,
this is *not* necessarily a reasonable expectation, just by thinking
about slots like :NAME and :DOCUMENTATION that *shouldn't* inherit.

It looks like my two options are: embedding the class instances inside
of container slots or developing a :DIRECT-TEMPLATE-CLASSES metaslot
with corresponding widget.  Is there a third?  Thanks!

-- Dr. Richard Dunlap
    Applied Systems Intelligence, Inc.


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

Reply | Threaded
Open this post in threaded view
|

Re: TemplateSlotsWidget behavior for non-:SLOT-valued slots

Tania Tudorache

Richard,

please see my answers inline.

Tania

Richard Dunlap wrote:

>Richard Dunlap wrote:
>  
>
>>In a metaclass :CLASS-A, :SLOT-B has multiple cardinality, value type
>>Instance of Class-C (if it turns out to matter, in my exact situation
>>there are multiple acceptable classes).  Notably, Class-C is *not* a
>>subclass of :SLOT.
>>
>>A user builds an instance Class-A1 of :CLASS-A, and subclasses Class-A1
>>to Subclass-A1.  Using an appropriate slot widget, the user adds an
>>instance of Class-C to the list of values for Class-A1's :SLOT-B.  I
>>would like for that value to be inherited by Subclass-A1.
>>
>>1) From a modeling perspective, is that a reasonable expectation?
>>
>>    
>>
>
>Following up on my own question; I just had the epiphany that -- no,
>this is *not* necessarily a reasonable expectation, just by thinking
>about slots like :NAME and :DOCUMENTATION that *shouldn't* inherit.
>
>  
>
To answer your question: From the modeling perspective, :SLOT-B is an
own slot at the level of class Class-A1 (and its subclasses) and own
slot values are not inherited.
Only template slots are inherited at subclasses together with their
facets (for example, allowed classes). The :NAME and  :DOCUMENTATION
slots are also own slots at class level, and hence their values are not
inherited in subclasses.

>It looks like my two options are: embedding the class instances inside
>of container slots or developing a :DIRECT-TEMPLATE-CLASSES metaslot
>with corresponding widget.  Is there a third?  Thanks!
>  
>
Both options don't seem a natural way of modeling. Can't you use
template slots instead of own-slots in your model, especially if you
need inheritance? Usually there are different ways of modeling the same
problem or domain and it is better to choose one in which you don't get
to the limit of the language or of the tool.

If you really want to use own slots with inheritance, you can implement
the inheritance behavior for own slot in your application. This means
overriding some methods, like getOwnSlotValues, so that you will return
the collection of the own slot values collected from the superclasses
and the values defined at your class. I have done this and it is
do-able, but you get a lot of overhead with consistency checking. You
would also have to define the exact behavior of inheritance and
implemented accordinlgy. For example, what happens if you get as own
slots values the same value twice: one coming from the inherited own
slot value and one for the local own slot.

All these things are already solved for you if you use template slots
rather than own slots.

If you would detail a little bit more the problem that you want to
model, maybe we can give you ideas for alternative modeling solutions.

Tania

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