bean generator not accessible

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

bean generator not accessible

Maciej Gawinecki-2



The bean generator about which you tell in

JADE TUTORIAL: APPLICATION-DEFINED CONTENT, LANGUAGES AND ONTOLOGIES

should accesible at

1. http://www.swi.psy.uva.nl/usr/aart/beangenerator/

from

2. http://protege.cim3.net/cgi-bin/wiki.pl?ProtegePluginsLibraryByType

but the link 1. does not work.

do you know alternative address ?

best regards

Maciej

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

Reply | Threaded
Open this post in threaded view
|

How to represent attributes with compound values

Bob Calin-Jageman

Here's a puzzle that I'm sure has come up for other Protege users.  I'd
appreciate any advice/comments.

I'm creating an ontology for Neuron types.  Neurons have many attributes
that are reported as both a value and a variance (true for most
scientific measurements).  How do I go about representing compound
attribute values?

Solution 1:  Naming Convention.  One solutions would be to simply add 2
slots for each attribute using a naming convention.  For example, to
record the action potential width, I could have a slot called AP_Width
and a second slot called AP_Width_SD.   This puts both values on the
same form for data entry and keeps the values tightly bound with the
actual instance it describes.  On the other hand, this seems very
clunky, especially as there are probably 50-60 neuron attributes to
track.  Also, it seems to be conceptually sloppy, as there is no
representation that the two slots are actually representing aspects of
the same thing.

Solution 2: Instances of a Class.  I've also tried creating a class
called "Neuron Properties".  This class has two slots: Value and
Variance.  I then make a new subclass for each property (e.g.
AP_Width).  In the Neuron class, I create a slot called "My Properties"
that takes instances of the "Neuron Properties" class.  This makes it
very easy to add new properties to the Neuron class, simply by creating
any new sub-class for "Neuron Properties".  The GUI for this is pretty
crumby, however, even with the instance-tree widget.  Putting the
properties as a seperate instance also makes it impossible to search for
Neurons by attribute value using the current protege search tab and more
difficult using the API .  Finally, I don't see how I can restrict
Neuron instances to have only 1 instance of some property types.

(possible) Solution 3: Types.  Another approach I tried is similar to
#2--I created a "Neuron Properties" class with Value and Variance slots
and then created subclasses for each property (e.g. AP_Width, V_rest,
Input_Resistance).  In the instances tab, I defined a new instance of
the Neuron class.  For each property I wanted to add, I added it as a
"Type".  This looked pretty cool--I added a types as AP_width, V_rest,
and Input_R and the form for the instance just grew to have values and
variances for each of these property classes.  The behavior of this form
was unexpected, however--Whatever I put in for a value was transposed to
*all* the values.  For example, If I put in AP_width of 10ms, the V_rest
and Input_R values also changed to 10ms.  The last edited was always
kept regardless of which I edited.  I don't think I understand this
behavior--I typed the instance to the subclasses (V_rest) not the
"Neuron Properties" superclass, so as members of these distinct
subclasses I would have thought the Neuron instances could have had
unique values.  Perhaps this occured because the value and variance
slots are assigned to the "neuron properties" class?  It's a shame
because this otherwise would seem to provide just the right functionality.

(dream) solution 4: Compound value slot.  Is it possible to add a new
slot-type that takes compound values?

Comments?  Suggestions?

Thanks,

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

Reply | Threaded
Open this post in threaded view
|

Re: bean generator not accessible

Tania Tudorache
In reply to this post by Maciej Gawinecki-2

Hi Maciej,

thank you for pointing that out. It seems that the author moved the
plugin on another website, but did not update the link on the wiki.
I fixed the link on the wiki now: http://acklin.nl/page.php?id=34

Tania


Maciej Gawinecki wrote:

>
>The bean generator about which you tell in
>
>JADE TUTORIAL: APPLICATION-DEFINED CONTENT, LANGUAGES AND ONTOLOGIES
>
>should accesible at
>
>1. http://www.swi.psy.uva.nl/usr/aart/beangenerator/
>
>from
>
>2. http://protege.cim3.net/cgi-bin/wiki.pl?ProtegePluginsLibraryByType
>
>but the link 1. does not work.
>
>do you know alternative address ?
>
>best regards
>
>Maciej
>
>-------------------------------------------------------------------------
>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: How to represent attributes with compound values

samsontu
In reply to this post by Bob Calin-Jageman


My immediate thought is to model "attributes of Neuron" as slots of the
Neuron class. The allowed values of these slots are instances of the
Neuron_Property_Value class, which has slots such as value, unit, and
variance. So you have

class Neuron
  slot AP_Width
  slot V_Rest
  ...

You can edit these slot values using the instanceRowWidget
(single-valued) or InstanceTableWidget (multi-valued).

 From your description, it's not clear whether the neuron property
values  are property values of individual instances or they are mean
values for types of neuron. I am assuming the former. If the latter is
the case, you mean want to use metaclasses, but that's another issue.

Samson

Bob Calin-Jageman wrote:

> Here's a puzzle that I'm sure has come up for other Protege users.  I'd
> appreciate any advice/comments.
>
> I'm creating an ontology for Neuron types.  Neurons have many attributes
> that are reported as both a value and a variance (true for most
> scientific measurements).  How do I go about representing compound
> attribute values?
>
> Solution 1:  Naming Convention.  One solutions would be to simply add 2
> slots for each attribute using a naming convention.  For example, to
> record the action potential width, I could have a slot called AP_Width
> and a second slot called AP_Width_SD.   This puts both values on the
> same form for data entry and keeps the values tightly bound with the
> actual instance it describes.  On the other hand, this seems very
> clunky, especially as there are probably 50-60 neuron attributes to
> track.  Also, it seems to be conceptually sloppy, as there is no
> representation that the two slots are actually representing aspects of
> the same thing.
>
> Solution 2: Instances of a Class.  I've also tried creating a class
> called "Neuron Properties".  This class has two slots: Value and
> Variance.  I then make a new subclass for each property (e.g.
> AP_Width).  In the Neuron class, I create a slot called "My Properties"
> that takes instances of the "Neuron Properties" class.  This makes it
> very easy to add new properties to the Neuron class, simply by creating
> any new sub-class for "Neuron Properties".  The GUI for this is pretty
> crumby, however, even with the instance-tree widget.  Putting the
> properties as a seperate instance also makes it impossible to search for
> Neurons by attribute value using the current protege search tab and more
> difficult using the API .  Finally, I don't see how I can restrict
> Neuron instances to have only 1 instance of some property types.
>
> (possible) Solution 3: Types.  Another approach I tried is similar to
> #2--I created a "Neuron Properties" class with Value and Variance slots
> and then created subclasses for each property (e.g. AP_Width, V_rest,
> Input_Resistance).  In the instances tab, I defined a new instance of
> the Neuron class.  For each property I wanted to add, I added it as a
> "Type".  This looked pretty cool--I added a types as AP_width, V_rest,
> and Input_R and the form for the instance just grew to have values and
> variances for each of these property classes.  The behavior of this form
> was unexpected, however--Whatever I put in for a value was transposed to
> *all* the values.  For example, If I put in AP_width of 10ms, the V_rest
> and Input_R values also changed to 10ms.  The last edited was always
> kept regardless of which I edited.  I don't think I understand this
> behavior--I typed the instance to the subclasses (V_rest) not the
> "Neuron Properties" superclass, so as members of these distinct
> subclasses I would have thought the Neuron instances could have had
> unique values.  Perhaps this occured because the value and variance
> slots are assigned to the "neuron properties" class?  It's a shame
> because this otherwise would seem to provide just the right functionality.
>
> (dream) solution 4: Compound value slot.  Is it possible to add a new
> slot-type that takes compound values?
>
> Comments?  Suggestions?
>
> Thanks,
>
> Bob Calin-Jageman
> -------------------------------------------------------------------------
> 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: How to represent attributes with compound values

Tania Tudorache
Hi Bob,

I think Samon's solution is the best one. You can extend it if you want
to have different types of attributes, like you have described in
Solution 2, and then make the attribute template slots point to the
subclass of "Neuron Properties", like below:

class Neuron
        template slot AP_Width_attribute: allowed classes: "AP_Width"

where "AP_Width" is a subclass of "Neuron Properties". Using Samson's
solution you can also control the cardinality of your attributes. This
was your worry in Solution 2. Also, if you activate "In-place editing"
for the InstanceTableWidget, you have a very convenient way of editing
the composed attribute values.
 
You were also concerned about not being able to use Protege Query tab
directly if you use an instance to hold the compound attribute values.
There is a solution to that, too: you can use Algernon, for example, to
make the queries. One query could look like this:

((:instance Neuron ?neuron)
(AP_Width_attribute ?neuron ?width)
(variance ?width ?var))

In this case, ?var will be bound to the value of the variance in the
compound attribute of Neuron instances.

I have some comments on Solution 3. and 4.

Solution 3 behaved correctly. Your modeling means that a Neuron instance
is also an instance of AP_width and of V_rest which both had the slot
"value" defined in it (because they both subclassed Neuron Properties).
So, you were using multiple inheritance. Even if on the instance form
the "value" own slot showed up twice, they were actually the same slot,
inherited on different paths. So I think this solution was not good for
two reasons: it did not reflect correctly the semantics of your model,
and multiple inheritance should only be used when you know you can live
with its consequences (like, slots inherited on different paths with
different values).

Solution 4 is possible, if you don't use instances. You can define your
own composed type of attribute by using metaslots. You may add to your
attribute type any properties that you like (unit, variance, author,
etc). The problem is that you can edit the properties of your attributes
only at class level. The properties of attributes are lost at instance
level.

Tania


Samson Tu wrote:

>My immediate thought is to model "attributes of Neuron" as slots of the
>Neuron class. The allowed values of these slots are instances of the
>Neuron_Property_Value class, which has slots such as value, unit, and
>variance. So you have
>
>class Neuron
>  slot AP_Width
>  slot V_Rest
>  ...
>
>You can edit these slot values using the instanceRowWidget
>(single-valued) or InstanceTableWidget (multi-valued).
>
> From your description, it's not clear whether the neuron property
>values  are property values of individual instances or they are mean
>values for types of neuron. I am assuming the former. If the latter is
>the case, you mean want to use metaclasses, but that's another issue.
>
>Samson
>
>Bob Calin-Jageman wrote:
>  
>
>>Here's a puzzle that I'm sure has come up for other Protege users.  I'd
>>appreciate any advice/comments.
>>
>>I'm creating an ontology for Neuron types.  Neurons have many attributes
>>that are reported as both a value and a variance (true for most
>>scientific measurements).  How do I go about representing compound
>>attribute values?
>>
>>Solution 1:  Naming Convention.  One solutions would be to simply add 2
>>slots for each attribute using a naming convention.  For example, to
>>record the action potential width, I could have a slot called AP_Width
>>and a second slot called AP_Width_SD.   This puts both values on the
>>same form for data entry and keeps the values tightly bound with the
>>actual instance it describes.  On the other hand, this seems very
>>clunky, especially as there are probably 50-60 neuron attributes to
>>track.  Also, it seems to be conceptually sloppy, as there is no
>>representation that the two slots are actually representing aspects of
>>the same thing.
>>
>>Solution 2: Instances of a Class.  I've also tried creating a class
>>called "Neuron Properties".  This class has two slots: Value and
>>Variance.  I then make a new subclass for each property (e.g.
>>AP_Width).  In the Neuron class, I create a slot called "My Properties"
>>that takes instances of the "Neuron Properties" class.  This makes it
>>very easy to add new properties to the Neuron class, simply by creating
>>any new sub-class for "Neuron Properties".  The GUI for this is pretty
>>crumby, however, even with the instance-tree widget.  Putting the
>>properties as a seperate instance also makes it impossible to search for
>>Neurons by attribute value using the current protege search tab and more
>>difficult using the API .  Finally, I don't see how I can restrict
>>Neuron instances to have only 1 instance of some property types.
>>
>>(possible) Solution 3: Types.  Another approach I tried is similar to
>>#2--I created a "Neuron Properties" class with Value and Variance slots
>>and then created subclasses for each property (e.g. AP_Width, V_rest,
>>Input_Resistance).  In the instances tab, I defined a new instance of
>>the Neuron class.  For each property I wanted to add, I added it as a
>>"Type".  This looked pretty cool--I added a types as AP_width, V_rest,
>>and Input_R and the form for the instance just grew to have values and
>>variances for each of these property classes.  The behavior of this form
>>was unexpected, however--Whatever I put in for a value was transposed to
>>*all* the values.  For example, If I put in AP_width of 10ms, the V_rest
>>and Input_R values also changed to 10ms.  The last edited was always
>>kept regardless of which I edited.  I don't think I understand this
>>behavior--I typed the instance to the subclasses (V_rest) not the
>>"Neuron Properties" superclass, so as members of these distinct
>>subclasses I would have thought the Neuron instances could have had
>>unique values.  Perhaps this occured because the value and variance
>>slots are assigned to the "neuron properties" class?  It's a shame
>>because this otherwise would seem to provide just the right functionality.
>>
>>(dream) solution 4: Compound value slot.  Is it possible to add a new
>>slot-type that takes compound values?
>>
>>Comments?  Suggestions?
>>
>>Thanks,
>>
>>Bob Calin-Jageman
>>-------------------------------------------------------------------------
>>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
|

Limiting relationships on the value of a slot

Bob Calin-Jageman

The replies I had to my last query were extremely helpful (Thanks Tania
and Samson), so I thought I'd seek help on another problem I'm having.

The problem is representing how the value of a slot restricts the values
of other slot.  For example, every address has a city and a state, but
once you choose a state the options for the city become more limited.  
In my specific domain, this problem arises in representing how a
neuron's properties depend on its speces.  For example:

Class - Ganglia.
    Slots: Name.
    Instances: Cerebral, Pedal, Buccal, Abdominal)
Class - Organisms.
    Slots: Name, Nervous_System (Instance of Ganglia)
    Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
Abdominal, Buccal)
Class - Neuron
    Slots: Name, Species (Instance of Organism), Location (Instance of
Ganglia)
    Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.

I want to make it so that the value of a Neuron's species restricts that
range of valid locations.  Note that this is not a problem only for
locations, but for many other relationships we'd like to define.  How do
I represent this is Protege?  Or, is this something that should be done
via application logic?

Bob

One feature request: To make the class name available as a parameter for
a multiple display slot.
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Limiting relationships on the value of a slot

samsontu

You can express mutual restrictions among slot values in Protege using
PAL constraints
(http://protege.stanford.edu/plugins/paltabs/pal-documentation/index.htm)

Bob Calin-Jageman wrote:

> The replies I had to my last query were extremely helpful (Thanks Tania
> and Samson), so I thought I'd seek help on another problem I'm having.
>
> The problem is representing how the value of a slot restricts the values
> of other slot.  For example, every address has a city and a state, but
> once you choose a state the options for the city become more limited.  
> In my specific domain, this problem arises in representing how a
> neuron's properties depend on its speces.  For example:
>
> Class - Ganglia.
>     Slots: Name.
>     Instances: Cerebral, Pedal, Buccal, Abdominal)
> Class - Organisms.
>     Slots: Name, Nervous_System (Instance of Ganglia)
>     Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
> Abdominal, Buccal)
> Class - Neuron
>     Slots: Name, Species (Instance of Organism), Location (Instance of
> Ganglia)
>     Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
>
> I want to make it so that the value of a Neuron's species restricts that
> range of valid locations.  Note that this is not a problem only for
> locations, but for many other relationships we'd like to define.  How do
> I represent this is Protege?  Or, is this something that should be done
> via application logic?
>
> Bob
>
> One feature request: To make the class name available as a parameter for
> a multiple display slot.
> -------------------------------------------------------------------------
> 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: Limiting relationships on the value of a slot

Paul Prueitt


Bob

I am wondering if you can state this question as one being about "slots" in
frames.

My background is quantum cognitive neuroscience "Houk, Hameroff and
Pribram", with some exposure to the research on neurons. So I would likely
qualify as a domain expert in your field.  The idea of a vocabulary about
neuronal structure and function peaks my interest.

I would like to see more discussion here on the formal natures of frames,
slots and  (fillers?), and (or me) less entanglement with the software
issues.  My interest is in translation theory and interoperability.

as discussed at:

http://www.bcngroup.org/beadgames/generativeMethodology/186.htm


In a what, why, how context.  I am interested in the why and the what; and
less about the how the software does or does not allow something to be done.

Sorry about the preamble, but I have seen your interest in neuron ontology
and would like to understand how you are thinking about the notion of a
slot.

You say, for example

> The problem is in representing how the value of a slot restricts the
values
> of other slot.

I would call the value of a slot a "filler"... but I am not sure that this
is aligned with CLIPS (which I understand to be the primary formalism on
which Protege Frames is based.  Could someone correct my language use if I
am making an error?

I would also assume that there are either one of two distinct cases

1) each named slot is a category, ie there can be more than one occurrence
of a slot and with each occurrence there is some modification possible
(which modifications are allowed is a second question)

2) each slot is uniquely assigned to a specific frame , or perhaps to a set
of frames (two, or two or more) and slots cannot be re-used.  They are
contextual.

If #2, we have a distinction between a slot as part of a single frame -
where the frame is the "context"; or the slot as a connection between two or
two or more frames.  In this case the slot is the "context".


I am going to "conjecture " something here... but I am not sure..  The core
problem that you question is struggling with has to do with treating the
"frame" is if it were a class, and one that is part of a sub-class, or
superclass subsumption.

Class-subclass subsumption creates the familiar RDF type triple....  < class
A, subclass, class B >  and this ability of RDF to express this subsumption
is an important part of the description logics.

But in essence, the subsumption is a slot between two frames.  There are no
explicit fillers, however.  The specific subsumption can have qualities and
this we can move towards making this comparison between a "frame slot" in
general and a subsumption.

One can also think of frames as "objects" and do a similarity and
differences analysis of frames in CLIPS and objects in UML or Object
Oriented Modeling.


I would appreciate comments, particular about mistakes that I am making in
the conjecture and the preamble .

Thank you in advance for your time.

Paul Prueitt
Taos New Mexico





-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Samson
Tu
Sent: Friday, March 10, 2006 5:43 PM
To: [hidden email]
Subject: [protege-discussion] Re: Limiting relationships on the value of
a slot



You can express mutual restrictions among slot values in Protege using
PAL constraints
(http://protege.stanford.edu/plugins/paltabs/pal-documentation/index.htm)

Bob Calin-Jageman wrote:

> The replies I had to my last query were extremely helpful (Thanks Tania
> and Samson), so I thought I'd seek help on another problem I'm having.
>
> The problem is representing how the value of a slot restricts the values
> of other slot.  For example, every address has a city and a state, but
> once you choose a state the options for the city become more limited.
> In my specific domain, this problem arises in representing how a
> neuron's properties depend on its speces.  For example:
>
> Class - Ganglia.
>     Slots: Name.
>     Instances: Cerebral, Pedal, Buccal, Abdominal)
> Class - Organisms.
>     Slots: Name, Nervous_System (Instance of Ganglia)
>     Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
> Abdominal, Buccal)
> Class - Neuron
>     Slots: Name, Species (Instance of Organism), Location (Instance of
> Ganglia)
>     Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
>
> I want to make it so that the value of a Neuron's species restricts that
> range of valid locations.  Note that this is not a problem only for
> locations, but for many other relationships we'd like to define.  How do
> I represent this is Protege?  Or, is this something that should be done
> via application logic?
>
> Bob
>
> One feature request: To make the class name available as a parameter for
> a multiple display slot.
> -------------------------------------------------------------------------
> 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



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

Reply | Threaded
Open this post in threaded view
|

Re: Limiting relationships on the value of a slot

Mike Bada
In reply to this post by Bob Calin-Jageman

Hi Bob,

I'd like to first suggest that your instances would be better modeled as
classes:  For example, cerebral ganglia, tritonians, and B17 neurons,
even though they are more specific than ganglia, organisms, and neurons,
respectively, are still all types of things.  Ideally, an instance
refers to a single thing, such as a single cerebral ganglion or a
tritonian, regardless whether or not you actually need to make instances
for specific ganglia or tritonians for your task.

If you instead model these instances as classes, you can then use
overriding of the allowed classes of slots to progressively restrict the
values of the slots down the class hierarchy.  At the level of "neuron",
the allowed class of "location" could be set to "ganglion"; this says
that neurons can be located in ganglia.  Then, for example, at the level
of "B17 neuron" (represented as a subclass of "neuron"), the allowed
classes of "location" could be further restricted to the types of
ganglia (represented as subclasses of "ganglion") in which B17 neurons
can be located; this states that B17 neurons can be located in cerebral
ganglia (or wherever they're located).  At the level of "tritonian B17
neuron" (a subclass of "B17 neuron") this might be further restricted, etc.

Cheers,
Mike

Bob Calin-Jageman wrote:

>The replies I had to my last query were extremely helpful (Thanks Tania
>and Samson), so I thought I'd seek help on another problem I'm having.
>
>The problem is representing how the value of a slot restricts the values
>of other slot.  For example, every address has a city and a state, but
>once you choose a state the options for the city become more limited.  
>In my specific domain, this problem arises in representing how a
>neuron's properties depend on its speces.  For example:
>
>Class - Ganglia.
>    Slots: Name.
>    Instances: Cerebral, Pedal, Buccal, Abdominal)
>Class - Organisms.
>    Slots: Name, Nervous_System (Instance of Ganglia)
>    Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
>Abdominal, Buccal)
>Class - Neuron
>    Slots: Name, Species (Instance of Organism), Location (Instance of
>Ganglia)
>    Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
>
>I want to make it so that the value of a Neuron's species restricts that
>range of valid locations.  Note that this is not a problem only for
>locations, but for many other relationships we'd like to define.  How do
>I represent this is Protege?  Or, is this something that should be done
>via application logic?
>
>Bob
>
>One feature request: To make the class name available as a parameter for
>a multiple display slot.
>-------------------------------------------------------------------------
>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: Limiting relationships on the value of a slot

Tania Tudorache

Hi Bob, Mike,

I would have suggested the same thing as Mike: modeling the concepts as
classes rather than instances. But this still does not solve Bob's
problem. From what I understood he wants at "edit" time to restrict the
values of location if species is already set. So, if the species of B17
is Tritonia, he wants to have the location limited to "Cerebral, Buccal
and Pedal". You can realize this only if you make the B17 be a subclass
of Tritonia. If you set at Tritonia class the allowed classes for
nervous_system to "Cerebral, Buccal and Pedal", and B17 is a subclass of
Tritonia, then you will inherit the allowed locations to B17 also.
However you must check if this modeling is actually what you mean.

In general, there are certain restrictions that are imposed by the
semantics of the representation language, like for example that allowed
classes can only be restricted in subclasses. But, there might other
things that you need to cover by using axioms, constraints, rules etc.
In your case, you need to state a rule: "If species = Tritonia then
locations = {Cerebral, Buccal, Pedal}". You can also formulate a general
rule:
"If Neuron.species= ?species  => Neuron.location =
?species.nervous_system" I used here ?species as a variable and
Neuron.species is the species slot from Neuron class.

You also have to know when you want to check these restrictions. For
example, by using PAL axioms, like Samson suggested, you could check in
the PAL Tab if the restrictions are violated or not. But you don't have
any support at edit time. So for example, when editing the locations for
B17, you will get the list of all locations, not only of the "correct"
locations. In order to get support at edit time you would have to
implement a slot widget, for example.

Bob, I have added your feature request to our list.

Tania

Mike Bada wrote:

>Hi Bob,
>
>I'd like to first suggest that your instances would be better modeled as
>classes:  For example, cerebral ganglia, tritonians, and B17 neurons,
>even though they are more specific than ganglia, organisms, and neurons,
>respectively, are still all types of things.  Ideally, an instance
>refers to a single thing, such as a single cerebral ganglion or a
>tritonian, regardless whether or not you actually need to make instances
>for specific ganglia or tritonians for your task.
>
>If you instead model these instances as classes, you can then use
>overriding of the allowed classes of slots to progressively restrict the
>values of the slots down the class hierarchy.  At the level of "neuron",
>the allowed class of "location" could be set to "ganglion"; this says
>that neurons can be located in ganglia.  Then, for example, at the level
>of "B17 neuron" (represented as a subclass of "neuron"), the allowed
>classes of "location" could be further restricted to the types of
>ganglia (represented as subclasses of "ganglion") in which B17 neurons
>can be located; this states that B17 neurons can be located in cerebral
>ganglia (or wherever they're located).  At the level of "tritonian B17
>neuron" (a subclass of "B17 neuron") this might be further restricted, etc.
>
>Cheers,
>Mike
>
>Bob Calin-Jageman wrote:
>
>  
>
>>The replies I had to my last query were extremely helpful (Thanks Tania
>>and Samson), so I thought I'd seek help on another problem I'm having.
>>
>>The problem is representing how the value of a slot restricts the values
>>of other slot.  For example, every address has a city and a state, but
>>once you choose a state the options for the city become more limited.  
>>In my specific domain, this problem arises in representing how a
>>neuron's properties depend on its speces.  For example:
>>
>>Class - Ganglia.
>>   Slots: Name.
>>   Instances: Cerebral, Pedal, Buccal, Abdominal)
>>Class - Organisms.
>>   Slots: Name, Nervous_System (Instance of Ganglia)
>>   Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
>>Abdominal, Buccal)
>>Class - Neuron
>>   Slots: Name, Species (Instance of Organism), Location (Instance of
>>Ganglia)
>>   Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
>>
>>I want to make it so that the value of a Neuron's species restricts that
>>range of valid locations.  Note that this is not a problem only for
>>locations, but for many other relationships we'd like to define.  How do
>>I represent this is Protege?  Or, is this something that should be done
>>via application logic?
>>
>>Bob
>>
>>One feature request: To make the class name available as a parameter for
>>a multiple display slot.
>>-------------------------------------------------------------------------
>>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: Limiting relationships on the value of a slot

Tania Tudorache

Bob,

you asked for a feature: adding the :NAME slot to the display slots.
Actually, this is also possible in current Protege.

You need to add the :NAME slot as template slot to your class. If you
don't want it to be visible on the instance form, you can set its slot
widget to "none" in the FormsTab.

In this way, the :NAME slot becomes availabe as a display slot. You can
use it also in combination with other slots if you use the "Multiple
slots.." option.

Tania



Tania Tudorache wrote:

>Hi Bob, Mike,
>
>I would have suggested the same thing as Mike: modeling the concepts as
>classes rather than instances. But this still does not solve Bob's
>problem. From what I understood he wants at "edit" time to restrict the
>values of location if species is already set. So, if the species of B17
>is Tritonia, he wants to have the location limited to "Cerebral, Buccal
>and Pedal". You can realize this only if you make the B17 be a subclass
>of Tritonia. If you set at Tritonia class the allowed classes for
>nervous_system to "Cerebral, Buccal and Pedal", and B17 is a subclass of
>Tritonia, then you will inherit the allowed locations to B17 also.
>However you must check if this modeling is actually what you mean.
>
>In general, there are certain restrictions that are imposed by the
>semantics of the representation language, like for example that allowed
>classes can only be restricted in subclasses. But, there might other
>things that you need to cover by using axioms, constraints, rules etc.
>In your case, you need to state a rule: "If species = Tritonia then
>locations = {Cerebral, Buccal, Pedal}". You can also formulate a general
>rule:
>"If Neuron.species= ?species  => Neuron.location =
>?species.nervous_system" I used here ?species as a variable and
>Neuron.species is the species slot from Neuron class.
>
>You also have to know when you want to check these restrictions. For
>example, by using PAL axioms, like Samson suggested, you could check in
>the PAL Tab if the restrictions are violated or not. But you don't have
>any support at edit time. So for example, when editing the locations for
>B17, you will get the list of all locations, not only of the "correct"
>locations. In order to get support at edit time you would have to
>implement a slot widget, for example.
>
>Bob, I have added your feature request to our list.
>
>Tania
>
>Mike Bada wrote:
>
>  
>
>>Hi Bob,
>>
>>I'd like to first suggest that your instances would be better modeled as
>>classes:  For example, cerebral ganglia, tritonians, and B17 neurons,
>>even though they are more specific than ganglia, organisms, and neurons,
>>respectively, are still all types of things.  Ideally, an instance
>>refers to a single thing, such as a single cerebral ganglion or a
>>tritonian, regardless whether or not you actually need to make instances
>>for specific ganglia or tritonians for your task.
>>
>>If you instead model these instances as classes, you can then use
>>overriding of the allowed classes of slots to progressively restrict the
>>values of the slots down the class hierarchy.  At the level of "neuron",
>>the allowed class of "location" could be set to "ganglion"; this says
>>that neurons can be located in ganglia.  Then, for example, at the level
>>of "B17 neuron" (represented as a subclass of "neuron"), the allowed
>>classes of "location" could be further restricted to the types of
>>ganglia (represented as subclasses of "ganglion") in which B17 neurons
>>can be located; this states that B17 neurons can be located in cerebral
>>ganglia (or wherever they're located).  At the level of "tritonian B17
>>neuron" (a subclass of "B17 neuron") this might be further restricted, etc.
>>
>>Cheers,
>>Mike
>>
>>Bob Calin-Jageman wrote:
>>
>>
>>
>>    
>>
>>>The replies I had to my last query were extremely helpful (Thanks Tania
>>>and Samson), so I thought I'd seek help on another problem I'm having.
>>>
>>>The problem is representing how the value of a slot restricts the values
>>>of other slot.  For example, every address has a city and a state, but
>>>once you choose a state the options for the city become more limited.  
>>>In my specific domain, this problem arises in representing how a
>>>neuron's properties depend on its speces.  For example:
>>>
>>>Class - Ganglia.
>>>  Slots: Name.
>>>  Instances: Cerebral, Pedal, Buccal, Abdominal)
>>>Class - Organisms.
>>>  Slots: Name, Nervous_System (Instance of Ganglia)
>>>  Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
>>>Abdominal, Buccal)
>>>Class - Neuron
>>>  Slots: Name, Species (Instance of Organism), Location (Instance of
>>>Ganglia)
>>>  Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
>>>
>>>I want to make it so that the value of a Neuron's species restricts that
>>>range of valid locations.  Note that this is not a problem only for
>>>locations, but for many other relationships we'd like to define.  How do
>>>I represent this is Protege?  Or, is this something that should be done
>>>via application logic?
>>>
>>>Bob
>>>
>>>One feature request: To make the class name available as a parameter for
>>>a multiple display slot.
>>>-------------------------------------------------------------------------
>>>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
>
>
>  
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Limiting relationships on the value of a slot

Bob Calin-Jageman

Tania,
thanks for the reply.

i'm looking for a way to make the *class* name part of the display
slot.  I think your solution would allow me to add the :NAME slot to the
display slot but not the class name.

As for why I want to do this, it is to make the instance tree widget
more useful.  If you have a relationship that allows several
classes/subclasses, the instance tree widget shows related instances by
their display slot, but without any way to distinguish which class each
instance belongs to.  I though that allowing class name to be part of a
compound display slot would help, although it might be simpler to alter
the instance tree widget to have the option of pre-pending the class
name to each related instance.


Bob

Tania Tudorache wrote:

>Bob,
>
>you asked for a feature: adding the :NAME slot to the display slots.
>Actually, this is also possible in current Protege.
>
>You need to add the :NAME slot as template slot to your class. If you
>don't want it to be visible on the instance form, you can set its slot
>widget to "none" in the FormsTab.
>
>In this way, the :NAME slot becomes availabe as a display slot. You can
>use it also in combination with other slots if you use the "Multiple
>slots.." option.
>
>Tania
>
>
>
>Tania Tudorache wrote:
>
>  
>
>>Hi Bob, Mike,
>>
>>I would have suggested the same thing as Mike: modeling the concepts as
>>classes rather than instances. But this still does not solve Bob's
>>problem. From what I understood he wants at "edit" time to restrict the
>>values of location if species is already set. So, if the species of B17
>>is Tritonia, he wants to have the location limited to "Cerebral, Buccal
>>and Pedal". You can realize this only if you make the B17 be a subclass
>>of Tritonia. If you set at Tritonia class the allowed classes for
>>nervous_system to "Cerebral, Buccal and Pedal", and B17 is a subclass of
>>Tritonia, then you will inherit the allowed locations to B17 also.
>>However you must check if this modeling is actually what you mean.
>>
>>In general, there are certain restrictions that are imposed by the
>>semantics of the representation language, like for example that allowed
>>classes can only be restricted in subclasses. But, there might other
>>things that you need to cover by using axioms, constraints, rules etc.
>>In your case, you need to state a rule: "If species = Tritonia then
>>locations = {Cerebral, Buccal, Pedal}". You can also formulate a general
>>rule:
>>"If Neuron.species= ?species  => Neuron.location =
>>?species.nervous_system" I used here ?species as a variable and
>>Neuron.species is the species slot from Neuron class.
>>
>>You also have to know when you want to check these restrictions. For
>>example, by using PAL axioms, like Samson suggested, you could check in
>>the PAL Tab if the restrictions are violated or not. But you don't have
>>any support at edit time. So for example, when editing the locations for
>>B17, you will get the list of all locations, not only of the "correct"
>>locations. In order to get support at edit time you would have to
>>implement a slot widget, for example.
>>
>>Bob, I have added your feature request to our list.
>>
>>Tania
>>
>>Mike Bada wrote:
>>
>>
>>
>>    
>>
>>>Hi Bob,
>>>
>>>I'd like to first suggest that your instances would be better modeled as
>>>classes:  For example, cerebral ganglia, tritonians, and B17 neurons,
>>>even though they are more specific than ganglia, organisms, and neurons,
>>>respectively, are still all types of things.  Ideally, an instance
>>>refers to a single thing, such as a single cerebral ganglion or a
>>>tritonian, regardless whether or not you actually need to make instances
>>>for specific ganglia or tritonians for your task.
>>>
>>>If you instead model these instances as classes, you can then use
>>>overriding of the allowed classes of slots to progressively restrict the
>>>values of the slots down the class hierarchy.  At the level of "neuron",
>>>the allowed class of "location" could be set to "ganglion"; this says
>>>that neurons can be located in ganglia.  Then, for example, at the level
>>>of "B17 neuron" (represented as a subclass of "neuron"), the allowed
>>>classes of "location" could be further restricted to the types of
>>>ganglia (represented as subclasses of "ganglion") in which B17 neurons
>>>can be located; this states that B17 neurons can be located in cerebral
>>>ganglia (or wherever they're located).  At the level of "tritonian B17
>>>neuron" (a subclass of "B17 neuron") this might be further restricted, etc.
>>>
>>>Cheers,
>>>Mike
>>>
>>>Bob Calin-Jageman wrote:
>>>
>>>
>>>
>>>  
>>>
>>>      
>>>
>>>>The replies I had to my last query were extremely helpful (Thanks Tania
>>>>and Samson), so I thought I'd seek help on another problem I'm having.
>>>>
>>>>The problem is representing how the value of a slot restricts the values
>>>>of other slot.  For example, every address has a city and a state, but
>>>>once you choose a state the options for the city become more limited.  
>>>>In my specific domain, this problem arises in representing how a
>>>>neuron's properties depend on its speces.  For example:
>>>>
>>>>Class - Ganglia.
>>>> Slots: Name.
>>>> Instances: Cerebral, Pedal, Buccal, Abdominal)
>>>>Class - Organisms.
>>>> Slots: Name, Nervous_System (Instance of Ganglia)
>>>> Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
>>>>Abdominal, Buccal)
>>>>Class - Neuron
>>>> Slots: Name, Species (Instance of Organism), Location (Instance of
>>>>Ganglia)
>>>> Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
>>>>
>>>>I want to make it so that the value of a Neuron's species restricts that
>>>>range of valid locations.  Note that this is not a problem only for
>>>>locations, but for many other relationships we'd like to define.  How do
>>>>I represent this is Protege?  Or, is this something that should be done
>>>>via application logic?
>>>>
>>>>Bob
>>>>
>>>>One feature request: To make the class name available as a parameter for
>>>>a multiple display slot.
>>>>-------------------------------------------------------------------------
>>>>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
>>
>>
>>
>>
>>    
>>
>
>-------------------------------------------------------------------------
>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: Limiting relationships on the value of a slot

Tania Tudorache

Bob,

you can do this by adding to the template slots the :DIRECT-TYPE slot.
But, you should make this invisible on the forms tab. This is a system
slot and the users should not change the direct type by changing the own
slot values of the :DIRECT-TYPE slot.

As for the other solution, I am sure that an extension of the
InstanceTree would not be hard to implement.

Tania


Bob Calin-Jageman wrote:

>Tania,
>thanks for the reply.
>
>i'm looking for a way to make the *class* name part of the display
>slot.  I think your solution would allow me to add the :NAME slot to the
>display slot but not the class name.
>
>As for why I want to do this, it is to make the instance tree widget
>more useful.  If you have a relationship that allows several
>classes/subclasses, the instance tree widget shows related instances by
>their display slot, but without any way to distinguish which class each
>instance belongs to.  I though that allowing class name to be part of a
>compound display slot would help, although it might be simpler to alter
>the instance tree widget to have the option of pre-pending the class
>name to each related instance.
>
>
>Bob
>
>Tania Tudorache wrote:
>
>  
>
>>Bob,
>>
>>you asked for a feature: adding the :NAME slot to the display slots.
>>Actually, this is also possible in current Protege.
>>
>>You need to add the :NAME slot as template slot to your class. If you
>>don't want it to be visible on the instance form, you can set its slot
>>widget to "none" in the FormsTab.
>>
>>In this way, the :NAME slot becomes availabe as a display slot. You can
>>use it also in combination with other slots if you use the "Multiple
>>slots.." option.
>>
>>Tania
>>
>>
>>
>>Tania Tudorache wrote:
>>
>>
>>
>>    
>>
>>>Hi Bob, Mike,
>>>
>>>I would have suggested the same thing as Mike: modeling the concepts as
>>>classes rather than instances. But this still does not solve Bob's
>>>problem. From what I understood he wants at "edit" time to restrict the
>>>values of location if species is already set. So, if the species of B17
>>>is Tritonia, he wants to have the location limited to "Cerebral, Buccal
>>>and Pedal". You can realize this only if you make the B17 be a subclass
>>>of Tritonia. If you set at Tritonia class the allowed classes for
>>>nervous_system to "Cerebral, Buccal and Pedal", and B17 is a subclass of
>>>Tritonia, then you will inherit the allowed locations to B17 also.
>>>However you must check if this modeling is actually what you mean.
>>>
>>>In general, there are certain restrictions that are imposed by the
>>>semantics of the representation language, like for example that allowed
>>>classes can only be restricted in subclasses. But, there might other
>>>things that you need to cover by using axioms, constraints, rules etc.
>>>In your case, you need to state a rule: "If species = Tritonia then
>>>locations = {Cerebral, Buccal, Pedal}". You can also formulate a general
>>>rule:
>>>"If Neuron.species= ?species  => Neuron.location =
>>>?species.nervous_system" I used here ?species as a variable and
>>>Neuron.species is the species slot from Neuron class.
>>>
>>>You also have to know when you want to check these restrictions. For
>>>example, by using PAL axioms, like Samson suggested, you could check in
>>>the PAL Tab if the restrictions are violated or not. But you don't have
>>>any support at edit time. So for example, when editing the locations for
>>>B17, you will get the list of all locations, not only of the "correct"
>>>locations. In order to get support at edit time you would have to
>>>implement a slot widget, for example.
>>>
>>>Bob, I have added your feature request to our list.
>>>
>>>Tania
>>>
>>>Mike Bada wrote:
>>>
>>>
>>>
>>>  
>>>
>>>      
>>>
>>>>Hi Bob,
>>>>
>>>>I'd like to first suggest that your instances would be better modeled as
>>>>classes:  For example, cerebral ganglia, tritonians, and B17 neurons,
>>>>even though they are more specific than ganglia, organisms, and neurons,
>>>>respectively, are still all types of things.  Ideally, an instance
>>>>refers to a single thing, such as a single cerebral ganglion or a
>>>>tritonian, regardless whether or not you actually need to make instances
>>>>for specific ganglia or tritonians for your task.
>>>>
>>>>If you instead model these instances as classes, you can then use
>>>>overriding of the allowed classes of slots to progressively restrict the
>>>>values of the slots down the class hierarchy.  At the level of "neuron",
>>>>the allowed class of "location" could be set to "ganglion"; this says
>>>>that neurons can be located in ganglia.  Then, for example, at the level
>>>>of "B17 neuron" (represented as a subclass of "neuron"), the allowed
>>>>classes of "location" could be further restricted to the types of
>>>>ganglia (represented as subclasses of "ganglion") in which B17 neurons
>>>>can be located; this states that B17 neurons can be located in cerebral
>>>>ganglia (or wherever they're located).  At the level of "tritonian B17
>>>>neuron" (a subclass of "B17 neuron") this might be further restricted, etc.
>>>>
>>>>Cheers,
>>>>Mike
>>>>
>>>>Bob Calin-Jageman wrote:
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>The replies I had to my last query were extremely helpful (Thanks Tania
>>>>>and Samson), so I thought I'd seek help on another problem I'm having.
>>>>>
>>>>>The problem is representing how the value of a slot restricts the values
>>>>>of other slot.  For example, every address has a city and a state, but
>>>>>once you choose a state the options for the city become more limited.  
>>>>>In my specific domain, this problem arises in representing how a
>>>>>neuron's properties depend on its speces.  For example:
>>>>>
>>>>>Class - Ganglia.
>>>>>Slots: Name.
>>>>>Instances: Cerebral, Pedal, Buccal, Abdominal)
>>>>>Class - Organisms.
>>>>>Slots: Name, Nervous_System (Instance of Ganglia)
>>>>>Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
>>>>>Abdominal, Buccal)
>>>>>Class - Neuron
>>>>>Slots: Name, Species (Instance of Organism), Location (Instance of
>>>>>Ganglia)
>>>>>Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
>>>>>
>>>>>I want to make it so that the value of a Neuron's species restricts that
>>>>>range of valid locations.  Note that this is not a problem only for
>>>>>locations, but for many other relationships we'd like to define.  How do
>>>>>I represent this is Protege?  Or, is this something that should be done
>>>>>via application logic?
>>>>>
>>>>>Bob
>>>>>
>>>>>One feature request: To make the class name available as a parameter for
>>>>>a multiple display slot.
>>>>>-------------------------------------------------------------------------
>>>>>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
>>>
>>>
>>>
>>>
>>>  
>>>
>>>      
>>>
>>-------------------------------------------------------------------------
>>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
|

Engineering ontology

zhanjun li
In reply to this post by Tania Tudorache

Hey all,
I wonder are they any existent engineering ontologies available and
accessible?
I would appreciate if anyone can suggest some resources.

Thanks,

James

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Tania
Tudorache
Sent: Wednesday, March 22, 2006 1:06 PM
To: [hidden email]
Subject: [protege-discussion] Re: Limiting relationships on the value of a
slot


Bob,

you asked for a feature: adding the :NAME slot to the display slots.
Actually, this is also possible in current Protege.

You need to add the :NAME slot as template slot to your class. If you don't
want it to be visible on the instance form, you can set its slot widget to
"none" in the FormsTab.

In this way, the :NAME slot becomes availabe as a display slot. You can use
it also in combination with other slots if you use the "Multiple slots.."
option.

Tania



Tania Tudorache wrote:

>Hi Bob, Mike,
>
>I would have suggested the same thing as Mike: modeling the concepts as
>classes rather than instances. But this still does not solve Bob's
>problem. From what I understood he wants at "edit" time to restrict the
>values of location if species is already set. So, if the species of B17
>is Tritonia, he wants to have the location limited to "Cerebral, Buccal
>and Pedal". You can realize this only if you make the B17 be a subclass
>of Tritonia. If you set at Tritonia class the allowed classes for
>nervous_system to "Cerebral, Buccal and Pedal", and B17 is a subclass
>of Tritonia, then you will inherit the allowed locations to B17 also.
>However you must check if this modeling is actually what you mean.
>
>In general, there are certain restrictions that are imposed by the
>semantics of the representation language, like for example that allowed
>classes can only be restricted in subclasses. But, there might other
>things that you need to cover by using axioms, constraints, rules etc.
>In your case, you need to state a rule: "If species = Tritonia then
>locations = {Cerebral, Buccal, Pedal}". You can also formulate a
>general
>rule:
>"If Neuron.species= ?species  => Neuron.location =
>?species.nervous_system" I used here ?species as a variable and
>Neuron.species is the species slot from Neuron class.
>
>You also have to know when you want to check these restrictions. For
>example, by using PAL axioms, like Samson suggested, you could check in
>the PAL Tab if the restrictions are violated or not. But you don't have
>any support at edit time. So for example, when editing the locations
>for B17, you will get the list of all locations, not only of the "correct"
>locations. In order to get support at edit time you would have to
>implement a slot widget, for example.
>
>Bob, I have added your feature request to our list.
>
>Tania
>
>Mike Bada wrote:
>
>  
>
>>Hi Bob,
>>
>>I'd like to first suggest that your instances would be better modeled
>>as
>>classes:  For example, cerebral ganglia, tritonians, and B17 neurons,
>>even though they are more specific than ganglia, organisms, and
>>neurons, respectively, are still all types of things.  Ideally, an
>>instance refers to a single thing, such as a single cerebral ganglion
>>or a tritonian, regardless whether or not you actually need to make
>>instances for specific ganglia or tritonians for your task.
>>
>>If you instead model these instances as classes, you can then use
>>overriding of the allowed classes of slots to progressively restrict
>>the values of the slots down the class hierarchy.  At the level of
>>"neuron", the allowed class of "location" could be set to "ganglion";
>>this says that neurons can be located in ganglia.  Then, for example,
>>at the level of "B17 neuron" (represented as a subclass of "neuron"),
>>the allowed classes of "location" could be further restricted to the
>>types of ganglia (represented as subclasses of "ganglion") in which
>>B17 neurons can be located; this states that B17 neurons can be
>>located in cerebral ganglia (or wherever they're located).  At the
>>level of "tritonian B17 neuron" (a subclass of "B17 neuron") this might be
further restricted, etc.

>>
>>Cheers,
>>Mike
>>
>>Bob Calin-Jageman wrote:
>>
>>
>>
>>    
>>
>>>The replies I had to my last query were extremely helpful (Thanks
>>>Tania and Samson), so I thought I'd seek help on another problem I'm
having.
>>>
>>>The problem is representing how the value of a slot restricts the
>>>values of other slot.  For example, every address has a city and a
>>>state, but once you choose a state the options for the city become more
limited.

>>>In my specific domain, this problem arises in representing how a
>>>neuron's properties depend on its speces.  For example:
>>>
>>>Class - Ganglia.
>>>  Slots: Name.
>>>  Instances: Cerebral, Pedal, Buccal, Abdominal) Class - Organisms.
>>>  Slots: Name, Nervous_System (Instance of Ganglia)
>>>  Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
>>>Abdominal, Buccal) Class - Neuron
>>>  Slots: Name, Species (Instance of Organism), Location (Instance of
>>>Ganglia)
>>>  Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
>>>
>>>I want to make it so that the value of a Neuron's species restricts
>>>that range of valid locations.  Note that this is not a problem only
>>>for locations, but for many other relationships we'd like to define.  
>>>How do I represent this is Protege?  Or, is this something that
>>>should be done via application logic?
>>>
>>>Bob
>>>
>>>One feature request: To make the class name available as a parameter
>>>for a multiple display slot.
>>>---------------------------------------------------------------------
>>>---- 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
>
>
>  
>

-------------------------------------------------------------------------
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: Engineering ontology

Tania Tudorache

James,

there are some available. Depends on which area of engineering you are
interested in.

One of the well know is the PhysSys ontology developed by Pim Borst for
describing physical systems. I am not sure where to get the sources
from.
http://www.qrg.northwestern.edu/papers/Files/qr-workshops/QR95/Borst_1995_PhysSys_Ontology_Physical_Systems.pdf

I know that the PELAB from Univ. of Linkoeping, also wanted to make an
OWL ontology for describing physical systems based on Modelica,
especially for simultation purposes. I don't know how far they got.
(http://www.ida.liu.se/~adrpo/)

The Engineering Mathematics ontology by T.Gruber and G.Olsen:
http://www-ksl.stanford.edu/knowledge-sharing/papers/engmath.html

In Ontolingua (http://www-ksl-svc.stanford.edu:5915/), you have also
several ontologies for the engineering domain. (Engineering ontology,
assemblies, components, constraints,connections, etc.)

I have just discovered this:
http://cvs.sourceforge.net/viewcvs.py/sigmakee/KBs/Attic/engineering.txt?rev=1.2

You can also look at the PSMTab plugin
(http://protege.stanford.edu/plugins/psmtab/PSMTab.html), where you can
apply reusable problem solving methods (like, design, configuration,
etc) on your own domain.

If you interested in Enterprise Ontologies, lifecycle, etc. then there
are other references.

Please start in future your own thread when you post a message on the
discussion list. Thanks!

Tania



zhanjun li wrote:

>Hey all,
>I wonder are they any existent engineering ontologies available and
>accessible?
>I would appreciate if anyone can suggest some resources.
>
>Thanks,
>
>James
>
>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]] On Behalf Of Tania
>Tudorache
>Sent: Wednesday, March 22, 2006 1:06 PM
>To: [hidden email]
>Subject: [protege-discussion] Re: Limiting relationships on the value of a
>slot
>
>
>Bob,
>
>you asked for a feature: adding the :NAME slot to the display slots.
>Actually, this is also possible in current Protege.
>
>You need to add the :NAME slot as template slot to your class. If you don't
>want it to be visible on the instance form, you can set its slot widget to
>"none" in the FormsTab.
>
>In this way, the :NAME slot becomes availabe as a display slot. You can use
>it also in combination with other slots if you use the "Multiple slots.."
>option.
>
>Tania
>
>
>
>Tania Tudorache wrote:
>
>  
>
>>Hi Bob, Mike,
>>
>>I would have suggested the same thing as Mike: modeling the concepts as
>>classes rather than instances. But this still does not solve Bob's
>>problem. From what I understood he wants at "edit" time to restrict the
>>values of location if species is already set. So, if the species of B17
>>is Tritonia, he wants to have the location limited to "Cerebral, Buccal
>>and Pedal". You can realize this only if you make the B17 be a subclass
>>of Tritonia. If you set at Tritonia class the allowed classes for
>>nervous_system to "Cerebral, Buccal and Pedal", and B17 is a subclass
>>of Tritonia, then you will inherit the allowed locations to B17 also.
>>However you must check if this modeling is actually what you mean.
>>
>>In general, there are certain restrictions that are imposed by the
>>semantics of the representation language, like for example that allowed
>>classes can only be restricted in subclasses. But, there might other
>>things that you need to cover by using axioms, constraints, rules etc.
>>In your case, you need to state a rule: "If species = Tritonia then
>>locations = {Cerebral, Buccal, Pedal}". You can also formulate a
>>general
>>rule:
>>"If Neuron.species= ?species  => Neuron.location =
>>?species.nervous_system" I used here ?species as a variable and
>>Neuron.species is the species slot from Neuron class.
>>
>>You also have to know when you want to check these restrictions. For
>>example, by using PAL axioms, like Samson suggested, you could check in
>>the PAL Tab if the restrictions are violated or not. But you don't have
>>any support at edit time. So for example, when editing the locations
>>for B17, you will get the list of all locations, not only of the "correct"
>>locations. In order to get support at edit time you would have to
>>implement a slot widget, for example.
>>
>>Bob, I have added your feature request to our list.
>>
>>Tania
>>
>>Mike Bada wrote:
>>
>>
>>
>>    
>>
>>>Hi Bob,
>>>
>>>I'd like to first suggest that your instances would be better modeled
>>>as
>>>classes:  For example, cerebral ganglia, tritonians, and B17 neurons,
>>>even though they are more specific than ganglia, organisms, and
>>>neurons, respectively, are still all types of things.  Ideally, an
>>>instance refers to a single thing, such as a single cerebral ganglion
>>>or a tritonian, regardless whether or not you actually need to make
>>>instances for specific ganglia or tritonians for your task.
>>>
>>>If you instead model these instances as classes, you can then use
>>>overriding of the allowed classes of slots to progressively restrict
>>>the values of the slots down the class hierarchy.  At the level of
>>>"neuron", the allowed class of "location" could be set to "ganglion";
>>>this says that neurons can be located in ganglia.  Then, for example,
>>>at the level of "B17 neuron" (represented as a subclass of "neuron"),
>>>the allowed classes of "location" could be further restricted to the
>>>types of ganglia (represented as subclasses of "ganglion") in which
>>>B17 neurons can be located; this states that B17 neurons can be
>>>located in cerebral ganglia (or wherever they're located).  At the
>>>level of "tritonian B17 neuron" (a subclass of "B17 neuron") this might be
>>>      
>>>
>further restricted, etc.
>  
>
>>>Cheers,
>>>Mike
>>>
>>>Bob Calin-Jageman wrote:
>>>
>>>
>>>
>>>  
>>>
>>>      
>>>
>>>>The replies I had to my last query were extremely helpful (Thanks
>>>>Tania and Samson), so I thought I'd seek help on another problem I'm
>>>>        
>>>>
>having.
>  
>
>>>>The problem is representing how the value of a slot restricts the
>>>>values of other slot.  For example, every address has a city and a
>>>>state, but once you choose a state the options for the city become more
>>>>        
>>>>
>limited.
>  
>
>>>>In my specific domain, this problem arises in representing how a
>>>>neuron's properties depend on its speces.  For example:
>>>>
>>>>Class - Ganglia.
>>>> Slots: Name.
>>>> Instances: Cerebral, Pedal, Buccal, Abdominal) Class - Organisms.
>>>> Slots: Name, Nervous_System (Instance of Ganglia)
>>>> Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
>>>>Abdominal, Buccal) Class - Neuron
>>>> Slots: Name, Species (Instance of Organism), Location (Instance of
>>>>Ganglia)
>>>> Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
>>>>
>>>>I want to make it so that the value of a Neuron's species restricts
>>>>that range of valid locations.  Note that this is not a problem only
>>>>for locations, but for many other relationships we'd like to define.  
>>>>How do I represent this is Protege?  Or, is this something that
>>>>should be done via application logic?
>>>>
>>>>Bob
>>>>
>>>>One feature request: To make the class name available as a parameter
>>>>for a multiple display slot.
>>>>---------------------------------------------------------------------
>>>>---- 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
>>
>>
>>
>>
>>    
>>
>
>-------------------------------------------------------------------------
>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: Engineering ontology

Imen Ben Yahia
please can you give links about "Enterprise Ontologies, lifecycle, etc. then
there
are other references."

thanks in advance
Imen

On 3/23/06, Tania Tudorache <[hidden email]> wrote:

>
>
> James,
>
> there are some available. Depends on which area of engineering you are
> interested in.
>
> One of the well know is the PhysSys ontology developed by Pim Borst for
> describing physical systems. I am not sure where to get the sources
> from.
>
> http://www.qrg.northwestern.edu/papers/Files/qr-workshops/QR95/Borst_1995_PhysSys_Ontology_Physical_Systems.pdf
>
> I know that the PELAB from Univ. of Linkoeping, also wanted to make an
> OWL ontology for describing physical systems based on Modelica,
> especially for simultation purposes. I don't know how far they got.
> (http://www.ida.liu.se/~adrpo/)
>
> The Engineering Mathematics ontology by T.Gruber and G.Olsen:
> http://www-ksl.stanford.edu/knowledge-sharing/papers/engmath.html
>
> In Ontolingua (http://www-ksl-svc.stanford.edu:5915/), you have also
> several ontologies for the engineering domain. (Engineering ontology,
> assemblies, components, constraints,connections, etc.)
>
> I have just discovered this:
>
> http://cvs.sourceforge.net/viewcvs.py/sigmakee/KBs/Attic/engineering.txt?rev=1.2
>
> You can also look at the PSMTab plugin
> (http://protege.stanford.edu/plugins/psmtab/PSMTab.html), where you can
> apply reusable problem solving methods (like, design, configuration,
> etc) on your own domain.
>
> If you interested in Enterprise Ontologies, lifecycle, etc. then there
> are other references.
>
> Please start in future your own thread when you post a message on the
> discussion list. Thanks!
>
> Tania
>
>
>
> zhanjun li wrote:
>
> >Hey all,
> >I wonder are they any existent engineering ontologies available and
> >accessible?
> >I would appreciate if anyone can suggest some resources.
> >
> >Thanks,
> >
> >James
> >
> >-----Original Message-----
> >From: [hidden email]
> >[mailto:[hidden email]] On Behalf Of Tania
> >Tudorache
> >Sent: Wednesday, March 22, 2006 1:06 PM
> >To: [hidden email]
> >Subject: [protege-discussion] Re: Limiting relationships on the value of
> a
> >slot
> >
> >
> >Bob,
> >
> >you asked for a feature: adding the :NAME slot to the display slots.
> >Actually, this is also possible in current Protege.
> >
> >You need to add the :NAME slot as template slot to your class. If you
> don't
> >want it to be visible on the instance form, you can set its slot widget
> to
> >"none" in the FormsTab.
> >
> >In this way, the :NAME slot becomes availabe as a display slot. You can
> use
> >it also in combination with other slots if you use the "Multiple slots.."
> >option.
> >
> >Tania
> >
> >
> >
> >Tania Tudorache wrote:
> >
> >
> >
> >>Hi Bob, Mike,
> >>
> >>I would have suggested the same thing as Mike: modeling the concepts as
> >>classes rather than instances. But this still does not solve Bob's
> >>problem. From what I understood he wants at "edit" time to restrict the
> >>values of location if species is already set. So, if the species of B17
> >>is Tritonia, he wants to have the location limited to "Cerebral, Buccal
> >>and Pedal". You can realize this only if you make the B17 be a subclass
> >>of Tritonia. If you set at Tritonia class the allowed classes for
> >>nervous_system to "Cerebral, Buccal and Pedal", and B17 is a subclass
> >>of Tritonia, then you will inherit the allowed locations to B17 also.
> >>However you must check if this modeling is actually what you mean.
> >>
> >>In general, there are certain restrictions that are imposed by the
> >>semantics of the representation language, like for example that allowed
> >>classes can only be restricted in subclasses. But, there might other
> >>things that you need to cover by using axioms, constraints, rules etc.
> >>In your case, you need to state a rule: "If species = Tritonia then
> >>locations = {Cerebral, Buccal, Pedal}". You can also formulate a
> >>general
> >>rule:
> >>"If Neuron.species= ?species  => Neuron.location =
> >>?species.nervous_system" I used here ?species as a variable and
> >>Neuron.species is the species slot from Neuron class.
> >>
> >>You also have to know when you want to check these restrictions. For
> >>example, by using PAL axioms, like Samson suggested, you could check in
> >>the PAL Tab if the restrictions are violated or not. But you don't have
> >>any support at edit time. So for example, when editing the locations
> >>for B17, you will get the list of all locations, not only of the
> "correct"
> >>locations. In order to get support at edit time you would have to
> >>implement a slot widget, for example.
> >>
> >>Bob, I have added your feature request to our list.
> >>
> >>Tania
> >>
> >>Mike Bada wrote:
> >>
> >>
> >>
> >>
> >>
> >>>Hi Bob,
> >>>
> >>>I'd like to first suggest that your instances would be better modeled
> >>>as
> >>>classes:  For example, cerebral ganglia, tritonians, and B17 neurons,
> >>>even though they are more specific than ganglia, organisms, and
> >>>neurons, respectively, are still all types of things.  Ideally, an
> >>>instance refers to a single thing, such as a single cerebral ganglion
> >>>or a tritonian, regardless whether or not you actually need to make
> >>>instances for specific ganglia or tritonians for your task.
> >>>
> >>>If you instead model these instances as classes, you can then use
> >>>overriding of the allowed classes of slots to progressively restrict
> >>>the values of the slots down the class hierarchy.  At the level of
> >>>"neuron", the allowed class of "location" could be set to "ganglion";
> >>>this says that neurons can be located in ganglia.  Then, for example,
> >>>at the level of "B17 neuron" (represented as a subclass of "neuron"),
> >>>the allowed classes of "location" could be further restricted to the
> >>>types of ganglia (represented as subclasses of "ganglion") in which
> >>>B17 neurons can be located; this states that B17 neurons can be
> >>>located in cerebral ganglia (or wherever they're located).  At the
> >>>level of "tritonian B17 neuron" (a subclass of "B17 neuron") this might
> be
> >>>
> >>>
> >further restricted, etc.
> >
> >
> >>>Cheers,
> >>>Mike
> >>>
> >>>Bob Calin-Jageman wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>The replies I had to my last query were extremely helpful (Thanks
> >>>>Tania and Samson), so I thought I'd seek help on another problem I'm
> >>>>
> >>>>
> >having.
> >
> >
> >>>>The problem is representing how the value of a slot restricts the
> >>>>values of other slot.  For example, every address has a city and a
> >>>>state, but once you choose a state the options for the city become
> more
> >>>>
> >>>>
> >limited.
> >
> >
> >>>>In my specific domain, this problem arises in representing how a
> >>>>neuron's properties depend on its speces.  For example:
> >>>>
> >>>>Class - Ganglia.
> >>>> Slots: Name.
> >>>> Instances: Cerebral, Pedal, Buccal, Abdominal) Class - Organisms.
> >>>> Slots: Name, Nervous_System (Instance of Ganglia)
> >>>> Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
> >>>>Abdominal, Buccal) Class - Neuron
> >>>> Slots: Name, Species (Instance of Organism), Location (Instance of
> >>>>Ganglia)
> >>>> Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
> >>>>
> >>>>I want to make it so that the value of a Neuron's species restricts
> >>>>that range of valid locations.  Note that this is not a problem only
> >>>>for locations, but for many other relationships we'd like to define.
> >>>>How do I represent this is Protege?  Or, is this something that
> >>>>should be done via application logic?
> >>>>
> >>>>Bob
> >>>>
> >>>>One feature request: To make the class name available as a parameter
> >>>>for a multiple display slot.
> >>>>---------------------------------------------------------------------
> >>>>---- 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
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >-------------------------------------------------------------------------
> >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
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Engineering ontology

Eman Negm
and any one can give me links about travel ontology and weather ontology also?
   
  thanks alot
  Eman

IBY <[hidden email]> wrote:
  please can you give links about "Enterprise Ontologies, lifecycle, etc. then
there
are other references."

thanks in advance
Imen

On 3/23/06, Tania Tudorache wrote:

>
>
> James,
>
> there are some available. Depends on which area of engineering you are
> interested in.
>
> One of the well know is the PhysSys ontology developed by Pim Borst for
> describing physical systems. I am not sure where to get the sources
> from.
>
> http://www.qrg.northwestern.edu/papers/Files/qr-workshops/QR95/Borst_1995_PhysSys_Ontology_Physical_Systems.pdf
>
> I know that the PELAB from Univ. of Linkoeping, also wanted to make an
> OWL ontology for describing physical systems based on Modelica,
> especially for simultation purposes. I don't know how far they got.
> (http://www.ida.liu.se/~adrpo/)
>
> The Engineering Mathematics ontology by T.Gruber and G.Olsen:
> http://www-ksl.stanford.edu/knowledge-sharing/papers/engmath.html
>
> In Ontolingua (http://www-ksl-svc.stanford.edu:5915/), you have also
> several ontologies for the engineering domain. (Engineering ontology,
> assemblies, components, constraints,connections, etc.)
>
> I have just discovered this:
>
> http://cvs.sourceforge.net/viewcvs.py/sigmakee/KBs/Attic/engineering.txt?rev=1.2
>
> You can also look at the PSMTab plugin
> (http://protege.stanford.edu/plugins/psmtab/PSMTab.html), where you can
> apply reusable problem solving methods (like, design, configuration,
> etc) on your own domain.
>
> If you interested in Enterprise Ontologies, lifecycle, etc. then there
> are other references.
>
> Please start in future your own thread when you post a message on the
> discussion list. Thanks!
>
> Tania
>
>
>
> zhanjun li wrote:
>
> >Hey all,
> >I wonder are they any existent engineering ontologies available and
> >accessible?
> >I would appreciate if anyone can suggest some resources.
> >
> >Thanks,
> >
> >James
> >
> >-----Original Message-----
> >From: [hidden email]
> >[mailto:[hidden email]] On Behalf Of Tania
> >Tudorache
> >Sent: Wednesday, March 22, 2006 1:06 PM
> >To: [hidden email]
> >Subject: [protege-discussion] Re: Limiting relationships on the value of
> a
> >slot
> >
> >
> >Bob,
> >
> >you asked for a feature: adding the :NAME slot to the display slots.
> >Actually, this is also possible in current Protege.
> >
> >You need to add the :NAME slot as template slot to your class. If you
> don't
> >want it to be visible on the instance form, you can set its slot widget
> to
> >"none" in the FormsTab.
> >
> >In this way, the :NAME slot becomes availabe as a display slot. You can
> use
> >it also in combination with other slots if you use the "Multiple slots.."
> >option.
> >
> >Tania
> >
> >
> >
> >Tania Tudorache wrote:
> >
> >
> >
> >>Hi Bob, Mike,
> >>
> >>I would have suggested the same thing as Mike: modeling the concepts as
> >>classes rather than instances. But this still does not solve Bob's
> >>problem. From what I understood he wants at "edit" time to restrict the
> >>values of location if species is already set. So, if the species of B17
> >>is Tritonia, he wants to have the location limited to "Cerebral, Buccal
> >>and Pedal". You can realize this only if you make the B17 be a subclass
> >>of Tritonia. If you set at Tritonia class the allowed classes for
> >>nervous_system to "Cerebral, Buccal and Pedal", and B17 is a subclass
> >>of Tritonia, then you will inherit the allowed locations to B17 also.
> >>However you must check if this modeling is actually what you mean.
> >>
> >>In general, there are certain restrictions that are imposed by the
> >>semantics of the representation language, like for example that allowed
> >>classes can only be restricted in subclasses. But, there might other
> >>things that you need to cover by using axioms, constraints, rules etc.
> >>In your case, you need to state a rule: "If species = Tritonia then
> >>locations = {Cerebral, Buccal, Pedal}". You can also formulate a
> >>general
> >>rule:
> >>"If Neuron.species= ?species => Neuron.location =
> >>?species.nervous_system" I used here ?species as a variable and
> >>Neuron.species is the species slot from Neuron class.
> >>
> >>You also have to know when you want to check these restrictions. For
> >>example, by using PAL axioms, like Samson suggested, you could check in
> >>the PAL Tab if the restrictions are violated or not. But you don't have
> >>any support at edit time. So for example, when editing the locations
> >>for B17, you will get the list of all locations, not only of the
> "correct"
> >>locations. In order to get support at edit time you would have to
> >>implement a slot widget, for example.
> >>
> >>Bob, I have added your feature request to our list.
> >>
> >>Tania
> >>
> >>Mike Bada wrote:
> >>
> >>
> >>
> >>
> >>
> >>>Hi Bob,
> >>>
> >>>I'd like to first suggest that your instances would be better modeled
> >>>as
> >>>classes: For example, cerebral ganglia, tritonians, and B17 neurons,
> >>>even though they are more specific than ganglia, organisms, and
> >>>neurons, respectively, are still all types of things. Ideally, an
> >>>instance refers to a single thing, such as a single cerebral ganglion
> >>>or a tritonian, regardless whether or not you actually need to make
> >>>instances for specific ganglia or tritonians for your task.
> >>>
> >>>If you instead model these instances as classes, you can then use
> >>>overriding of the allowed classes of slots to progressively restrict
> >>>the values of the slots down the class hierarchy. At the level of
> >>>"neuron", the allowed class of "location" could be set to "ganglion";
> >>>this says that neurons can be located in ganglia. Then, for example,
> >>>at the level of "B17 neuron" (represented as a subclass of "neuron"),
> >>>the allowed classes of "location" could be further restricted to the
> >>>types of ganglia (represented as subclasses of "ganglion") in which
> >>>B17 neurons can be located; this states that B17 neurons can be
> >>>located in cerebral ganglia (or wherever they're located). At the
> >>>level of "tritonian B17 neuron" (a subclass of "B17 neuron") this might
> be
> >>>
> >>>
> >further restricted, etc.
> >
> >
> >>>Cheers,
> >>>Mike
> >>>
> >>>Bob Calin-Jageman wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>The replies I had to my last query were extremely helpful (Thanks
> >>>>Tania and Samson), so I thought I'd seek help on another problem I'm
> >>>>
> >>>>
> >having.
> >
> >
> >>>>The problem is representing how the value of a slot restricts the
> >>>>values of other slot. For example, every address has a city and a
> >>>>state, but once you choose a state the options for the city become
> more
> >>>>
> >>>>
> >limited.
> >
> >
> >>>>In my specific domain, this problem arises in representing how a
> >>>>neuron's properties depend on its speces. For example:
> >>>>
> >>>>Class - Ganglia.
> >>>> Slots: Name.
> >>>> Instances: Cerebral, Pedal, Buccal, Abdominal) Class - Organisms.
> >>>> Slots: Name, Nervous_System (Instance of Ganglia)
> >>>> Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
> >>>>Abdominal, Buccal) Class - Neuron
> >>>> Slots: Name, Species (Instance of Organism), Location (Instance of
> >>>>Ganglia)
> >>>> Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
> >>>>
> >>>>I want to make it so that the value of a Neuron's species restricts
> >>>>that range of valid locations. Note that this is not a problem only
> >>>>for locations, but for many other relationships we'd like to define.
> >>>>How do I represent this is Protege? Or, is this something that
> >>>>should be done via application logic?
> >>>>
> >>>>Bob
> >>>>
> >>>>One feature request: To make the class name available as a parameter
> >>>>for a multiple display slot.
> >>>>---------------------------------------------------------------------
> >>>>---- 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
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >-------------------------------------------------------------------------
> >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
>
>

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



               
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low rates.

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

Reply | Threaded
Open this post in threaded view
|

Re: Engineering ontology

Tania Tudorache
In reply to this post by Imen Ben Yahia

You can look at the TOVE project
(http://www.eil.utoronto.ca/enterprise-modelling/tove/) Here is a paper
about it: http://citeseer.ist.psu.edu/126621.html

And  the "Enterprise Ontology"
http://www.aiai.ed.ac.uk/project/enterprise/enterprise/ontology.html

Tania

IBY wrote:

>please can you give links about "Enterprise Ontologies, lifecycle, etc. then
>there
>are other references."
>
>thanks in advance
>Imen
>
>On 3/23/06, Tania Tudorache <[hidden email]> wrote:
>  
>
>>James,
>>
>>there are some available. Depends on which area of engineering you are
>>interested in.
>>
>>One of the well know is the PhysSys ontology developed by Pim Borst for
>>describing physical systems. I am not sure where to get the sources
>>from.
>>
>>http://www.qrg.northwestern.edu/papers/Files/qr-workshops/QR95/Borst_1995_PhysSys_Ontology_Physical_Systems.pdf
>>
>>I know that the PELAB from Univ. of Linkoeping, also wanted to make an
>>OWL ontology for describing physical systems based on Modelica,
>>especially for simultation purposes. I don't know how far they got.
>>(http://www.ida.liu.se/~adrpo/)
>>
>>The Engineering Mathematics ontology by T.Gruber and G.Olsen:
>>http://www-ksl.stanford.edu/knowledge-sharing/papers/engmath.html
>>
>>In Ontolingua (http://www-ksl-svc.stanford.edu:5915/), you have also
>>several ontologies for the engineering domain. (Engineering ontology,
>>assemblies, components, constraints,connections, etc.)
>>
>>I have just discovered this:
>>
>>http://cvs.sourceforge.net/viewcvs.py/sigmakee/KBs/Attic/engineering.txt?rev=1.2
>>
>>You can also look at the PSMTab plugin
>>(http://protege.stanford.edu/plugins/psmtab/PSMTab.html), where you can
>>apply reusable problem solving methods (like, design, configuration,
>>etc) on your own domain.
>>
>>If you interested in Enterprise Ontologies, lifecycle, etc. then there
>>are other references.
>>
>>Please start in future your own thread when you post a message on the
>>discussion list. Thanks!
>>
>>Tania
>>
>>
>>
>>zhanjun li wrote:
>>
>>    
>>
>>>Hey all,
>>>I wonder are they any existent engineering ontologies available and
>>>accessible?
>>>I would appreciate if anyone can suggest some resources.
>>>
>>>Thanks,
>>>
>>>James
>>>
>>>-----Original Message-----
>>>From: [hidden email]
>>>[mailto:[hidden email]] On Behalf Of Tania
>>>Tudorache
>>>Sent: Wednesday, March 22, 2006 1:06 PM
>>>To: [hidden email]
>>>Subject: [protege-discussion] Re: Limiting relationships on the value of
>>>      
>>>
>>a
>>    
>>
>>>slot
>>>
>>>
>>>Bob,
>>>
>>>you asked for a feature: adding the :NAME slot to the display slots.
>>>Actually, this is also possible in current Protege.
>>>
>>>You need to add the :NAME slot as template slot to your class. If you
>>>      
>>>
>>don't
>>    
>>
>>>want it to be visible on the instance form, you can set its slot widget
>>>      
>>>
>>to
>>    
>>
>>>"none" in the FormsTab.
>>>
>>>In this way, the :NAME slot becomes availabe as a display slot. You can
>>>      
>>>
>>use
>>    
>>
>>>it also in combination with other slots if you use the "Multiple slots.."
>>>option.
>>>
>>>Tania
>>>
>>>
>>>
>>>Tania Tudorache wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>Hi Bob, Mike,
>>>>
>>>>I would have suggested the same thing as Mike: modeling the concepts as
>>>>classes rather than instances. But this still does not solve Bob's
>>>>problem. From what I understood he wants at "edit" time to restrict the
>>>>values of location if species is already set. So, if the species of B17
>>>>is Tritonia, he wants to have the location limited to "Cerebral, Buccal
>>>>and Pedal". You can realize this only if you make the B17 be a subclass
>>>>of Tritonia. If you set at Tritonia class the allowed classes for
>>>>nervous_system to "Cerebral, Buccal and Pedal", and B17 is a subclass
>>>>of Tritonia, then you will inherit the allowed locations to B17 also.
>>>>However you must check if this modeling is actually what you mean.
>>>>
>>>>In general, there are certain restrictions that are imposed by the
>>>>semantics of the representation language, like for example that allowed
>>>>classes can only be restricted in subclasses. But, there might other
>>>>things that you need to cover by using axioms, constraints, rules etc.
>>>>In your case, you need to state a rule: "If species = Tritonia then
>>>>locations = {Cerebral, Buccal, Pedal}". You can also formulate a
>>>>general
>>>>rule:
>>>>"If Neuron.species= ?species  => Neuron.location =
>>>>?species.nervous_system" I used here ?species as a variable and
>>>>Neuron.species is the species slot from Neuron class.
>>>>
>>>>You also have to know when you want to check these restrictions. For
>>>>example, by using PAL axioms, like Samson suggested, you could check in
>>>>the PAL Tab if the restrictions are violated or not. But you don't have
>>>>any support at edit time. So for example, when editing the locations
>>>>for B17, you will get the list of all locations, not only of the
>>>>        
>>>>
>>"correct"
>>    
>>
>>>>locations. In order to get support at edit time you would have to
>>>>implement a slot widget, for example.
>>>>
>>>>Bob, I have added your feature request to our list.
>>>>
>>>>Tania
>>>>
>>>>Mike Bada wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Hi Bob,
>>>>>
>>>>>I'd like to first suggest that your instances would be better modeled
>>>>>as
>>>>>classes:  For example, cerebral ganglia, tritonians, and B17 neurons,
>>>>>even though they are more specific than ganglia, organisms, and
>>>>>neurons, respectively, are still all types of things.  Ideally, an
>>>>>instance refers to a single thing, such as a single cerebral ganglion
>>>>>or a tritonian, regardless whether or not you actually need to make
>>>>>instances for specific ganglia or tritonians for your task.
>>>>>
>>>>>If you instead model these instances as classes, you can then use
>>>>>overriding of the allowed classes of slots to progressively restrict
>>>>>the values of the slots down the class hierarchy.  At the level of
>>>>>"neuron", the allowed class of "location" could be set to "ganglion";
>>>>>this says that neurons can be located in ganglia.  Then, for example,
>>>>>at the level of "B17 neuron" (represented as a subclass of "neuron"),
>>>>>the allowed classes of "location" could be further restricted to the
>>>>>types of ganglia (represented as subclasses of "ganglion") in which
>>>>>B17 neurons can be located; this states that B17 neurons can be
>>>>>located in cerebral ganglia (or wherever they're located).  At the
>>>>>level of "tritonian B17 neuron" (a subclass of "B17 neuron") this might
>>>>>          
>>>>>
>>be
>>    
>>
>>>>>          
>>>>>
>>>further restricted, etc.
>>>
>>>
>>>      
>>>
>>>>>Cheers,
>>>>>Mike
>>>>>
>>>>>Bob Calin-Jageman wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>The replies I had to my last query were extremely helpful (Thanks
>>>>>>Tania and Samson), so I thought I'd seek help on another problem I'm
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>having.
>>>
>>>
>>>      
>>>
>>>>>>The problem is representing how the value of a slot restricts the
>>>>>>values of other slot.  For example, every address has a city and a
>>>>>>state, but once you choose a state the options for the city become
>>>>>>            
>>>>>>
>>more
>>    
>>
>>>>>>            
>>>>>>
>>>limited.
>>>
>>>
>>>      
>>>
>>>>>>In my specific domain, this problem arises in representing how a
>>>>>>neuron's properties depend on its speces.  For example:
>>>>>>
>>>>>>Class - Ganglia.
>>>>>>Slots: Name.
>>>>>>Instances: Cerebral, Pedal, Buccal, Abdominal) Class - Organisms.
>>>>>>Slots: Name, Nervous_System (Instance of Ganglia)
>>>>>>Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
>>>>>>Abdominal, Buccal) Class - Neuron
>>>>>>Slots: Name, Species (Instance of Organism), Location (Instance of
>>>>>>Ganglia)
>>>>>>Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
>>>>>>
>>>>>>I want to make it so that the value of a Neuron's species restricts
>>>>>>that range of valid locations.  Note that this is not a problem only
>>>>>>for locations, but for many other relationships we'd like to define.
>>>>>>How do I represent this is Protege?  Or, is this something that
>>>>>>should be done via application logic?
>>>>>>
>>>>>>Bob
>>>>>>
>>>>>>One feature request: To make the class name available as a parameter
>>>>>>for a multiple display slot.
>>>>>>---------------------------------------------------------------------
>>>>>>---- 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>-------------------------------------------------------------------------
>>>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
>>
>>
>>    
>>
>
>-------------------------------------------------------------------------
>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: Engineering ontology

Tania Tudorache
In reply to this post by Eman Negm

Imen,

try Swoogle, a semantic web engine for searching ontologies
(http://swoogle.umbc.edu/)

We also have a travel ontology in owl
(http://protege.stanford.edu/plugins/owl/owl-library/travel.owl) in the
OWL ontology library.

Tania

Eman Negm wrote:

>and any one can give me links about travel ontology and weather ontology also?
>  
>  thanks alot
>  Eman
>
>IBY <[hidden email]> wrote:
>  please can you give links about "Enterprise Ontologies, lifecycle, etc. then
>there
>are other references."
>
>thanks in advance
>Imen
>
>On 3/23/06, Tania Tudorache wrote:
>  
>
>>James,
>>
>>there are some available. Depends on which area of engineering you are
>>interested in.
>>
>>One of the well know is the PhysSys ontology developed by Pim Borst for
>>describing physical systems. I am not sure where to get the sources
>>from.
>>
>>http://www.qrg.northwestern.edu/papers/Files/qr-workshops/QR95/Borst_1995_PhysSys_Ontology_Physical_Systems.pdf
>>
>>I know that the PELAB from Univ. of Linkoeping, also wanted to make an
>>OWL ontology for describing physical systems based on Modelica,
>>especially for simultation purposes. I don't know how far they got.
>>(http://www.ida.liu.se/~adrpo/)
>>
>>The Engineering Mathematics ontology by T.Gruber and G.Olsen:
>>http://www-ksl.stanford.edu/knowledge-sharing/papers/engmath.html
>>
>>In Ontolingua (http://www-ksl-svc.stanford.edu:5915/), you have also
>>several ontologies for the engineering domain. (Engineering ontology,
>>assemblies, components, constraints,connections, etc.)
>>
>>I have just discovered this:
>>
>>http://cvs.sourceforge.net/viewcvs.py/sigmakee/KBs/Attic/engineering.txt?rev=1.2
>>
>>You can also look at the PSMTab plugin
>>(http://protege.stanford.edu/plugins/psmtab/PSMTab.html), where you can
>>apply reusable problem solving methods (like, design, configuration,
>>etc) on your own domain.
>>
>>If you interested in Enterprise Ontologies, lifecycle, etc. then there
>>are other references.
>>
>>Please start in future your own thread when you post a message on the
>>discussion list. Thanks!
>>
>>Tania
>>
>>
>>
>>zhanjun li wrote:
>>
>>    
>>
>>>Hey all,
>>>I wonder are they any existent engineering ontologies available and
>>>accessible?
>>>I would appreciate if anyone can suggest some resources.
>>>
>>>Thanks,
>>>
>>>James
>>>
>>>-----Original Message-----
>>>From: [hidden email]
>>>[mailto:[hidden email]] On Behalf Of Tania
>>>Tudorache
>>>Sent: Wednesday, March 22, 2006 1:06 PM
>>>To: [hidden email]
>>>Subject: [protege-discussion] Re: Limiting relationships on the value of
>>>      
>>>
>>a
>>    
>>
>>>slot
>>>
>>>
>>>Bob,
>>>
>>>you asked for a feature: adding the :NAME slot to the display slots.
>>>Actually, this is also possible in current Protege.
>>>
>>>You need to add the :NAME slot as template slot to your class. If you
>>>      
>>>
>>don't
>>    
>>
>>>want it to be visible on the instance form, you can set its slot widget
>>>      
>>>
>>to
>>    
>>
>>>"none" in the FormsTab.
>>>
>>>In this way, the :NAME slot becomes availabe as a display slot. You can
>>>      
>>>
>>use
>>    
>>
>>>it also in combination with other slots if you use the "Multiple slots.."
>>>option.
>>>
>>>Tania
>>>
>>>
>>>
>>>Tania Tudorache wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>Hi Bob, Mike,
>>>>
>>>>I would have suggested the same thing as Mike: modeling the concepts as
>>>>classes rather than instances. But this still does not solve Bob's
>>>>problem. From what I understood he wants at "edit" time to restrict the
>>>>values of location if species is already set. So, if the species of B17
>>>>is Tritonia, he wants to have the location limited to "Cerebral, Buccal
>>>>and Pedal". You can realize this only if you make the B17 be a subclass
>>>>of Tritonia. If you set at Tritonia class the allowed classes for
>>>>nervous_system to "Cerebral, Buccal and Pedal", and B17 is a subclass
>>>>of Tritonia, then you will inherit the allowed locations to B17 also.
>>>>However you must check if this modeling is actually what you mean.
>>>>
>>>>In general, there are certain restrictions that are imposed by the
>>>>semantics of the representation language, like for example that allowed
>>>>classes can only be restricted in subclasses. But, there might other
>>>>things that you need to cover by using axioms, constraints, rules etc.
>>>>In your case, you need to state a rule: "If species = Tritonia then
>>>>locations = {Cerebral, Buccal, Pedal}". You can also formulate a
>>>>general
>>>>rule:
>>>>"If Neuron.species= ?species => Neuron.location =
>>>>?species.nervous_system" I used here ?species as a variable and
>>>>Neuron.species is the species slot from Neuron class.
>>>>
>>>>You also have to know when you want to check these restrictions. For
>>>>example, by using PAL axioms, like Samson suggested, you could check in
>>>>the PAL Tab if the restrictions are violated or not. But you don't have
>>>>any support at edit time. So for example, when editing the locations
>>>>for B17, you will get the list of all locations, not only of the
>>>>        
>>>>
>>"correct"
>>    
>>
>>>>locations. In order to get support at edit time you would have to
>>>>implement a slot widget, for example.
>>>>
>>>>Bob, I have added your feature request to our list.
>>>>
>>>>Tania
>>>>
>>>>Mike Bada wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Hi Bob,
>>>>>
>>>>>I'd like to first suggest that your instances would be better modeled
>>>>>as
>>>>>classes: For example, cerebral ganglia, tritonians, and B17 neurons,
>>>>>even though they are more specific than ganglia, organisms, and
>>>>>neurons, respectively, are still all types of things. Ideally, an
>>>>>instance refers to a single thing, such as a single cerebral ganglion
>>>>>or a tritonian, regardless whether or not you actually need to make
>>>>>instances for specific ganglia or tritonians for your task.
>>>>>
>>>>>If you instead model these instances as classes, you can then use
>>>>>overriding of the allowed classes of slots to progressively restrict
>>>>>the values of the slots down the class hierarchy. At the level of
>>>>>"neuron", the allowed class of "location" could be set to "ganglion";
>>>>>this says that neurons can be located in ganglia. Then, for example,
>>>>>at the level of "B17 neuron" (represented as a subclass of "neuron"),
>>>>>the allowed classes of "location" could be further restricted to the
>>>>>types of ganglia (represented as subclasses of "ganglion") in which
>>>>>B17 neurons can be located; this states that B17 neurons can be
>>>>>located in cerebral ganglia (or wherever they're located). At the
>>>>>level of "tritonian B17 neuron" (a subclass of "B17 neuron") this might
>>>>>          
>>>>>
>>be
>>    
>>
>>>>>          
>>>>>
>>>further restricted, etc.
>>>
>>>
>>>      
>>>
>>>>>Cheers,
>>>>>Mike
>>>>>
>>>>>Bob Calin-Jageman wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>The replies I had to my last query were extremely helpful (Thanks
>>>>>>Tania and Samson), so I thought I'd seek help on another problem I'm
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>having.
>>>
>>>
>>>      
>>>
>>>>>>The problem is representing how the value of a slot restricts the
>>>>>>values of other slot. For example, every address has a city and a
>>>>>>state, but once you choose a state the options for the city become
>>>>>>            
>>>>>>
>>more
>>    
>>
>>>>>>            
>>>>>>
>>>limited.
>>>
>>>
>>>      
>>>
>>>>>>In my specific domain, this problem arises in representing how a
>>>>>>neuron's properties depend on its speces. For example:
>>>>>>
>>>>>>Class - Ganglia.
>>>>>>Slots: Name.
>>>>>>Instances: Cerebral, Pedal, Buccal, Abdominal) Class - Organisms.
>>>>>>Slots: Name, Nervous_System (Instance of Ganglia)
>>>>>>Instances: Tritonia (Cerebral, Pedal, Buccal), Aplysia (Cerebral,
>>>>>>Abdominal, Buccal) Class - Neuron
>>>>>>Slots: Name, Species (Instance of Organism), Location (Instance of
>>>>>>Ganglia)
>>>>>>Instances: B17 (Tritonia; Pedal), L13 (Aplysia; Buccal), etc.
>>>>>>
>>>>>>I want to make it so that the value of a Neuron's species restricts
>>>>>>that range of valid locations. Note that this is not a problem only
>>>>>>for locations, but for many other relationships we'd like to define.
>>>>>>How do I represent this is Protege? Or, is this something that
>>>>>>should be done via application logic?
>>>>>>
>>>>>>Bob
>>>>>>
>>>>>>One feature request: To make the class name available as a parameter
>>>>>>for a multiple display slot.
>>>>>>---------------------------------------------------------------------
>>>>>>---- 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>-------------------------------------------------------------------------
>>>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
>>
>>
>>    
>>
>
>-------------------------------------------------------------------------
>To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>
>
>
>---------------------------------
>New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low rates.
>
>-------------------------------------------------------------------------
>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: Limiting relationships on the value of a slot

Ankur Jain-7
In reply to this post by Tania Tudorache

Tania,

I am also interested in using the class name for
display slot. How exactly I can add :DIRECT-TYPE slot
to the template slots? I tried various things but
couldn't get to it.

Thanks.

Ankur Jain
Purdue University

--- Tania Tudorache <[hidden email]> wrote:

>
> Bob,
>
> you can do this by adding to the template slots the
> :DIRECT-TYPE slot.
> But, you should make this invisible on the forms
> tab. This is a system
> slot and the users should not change the direct type
> by changing the own
> slot values of the :DIRECT-TYPE slot.
>
> As for the other solution, I am sure that an
> extension of the
> InstanceTree would not be hard to implement.
>
> Tania
>
>
> Bob Calin-Jageman wrote:
>
> >Tania,
> >thanks for the reply.
> >
> >i'm looking for a way to make the *class* name part
> of the display
> >slot.  I think your solution would allow me to add
> the :NAME slot to the
> >display slot but not the class name.
> >
> >As for why I want to do this, it is to make the
> instance tree widget
> >more useful.  If you have a relationship that
> allows several
> >classes/subclasses, the instance tree widget shows
> related instances by
> >their display slot, but without any way to
> distinguish which class each
> >instance belongs to.  I though that allowing class
> name to be part of a
> >compound display slot would help, although it might
> be simpler to alter
> >the instance tree widget to have the option of
> pre-pending the class
> >name to each related instance.
> >
> >
> >Bob
> >
> >Tania Tudorache wrote:
> >
> >  
> >
> >>Bob,
> >>
> >>you asked for a feature: adding the :NAME slot to
> the display slots.
> >>Actually, this is also possible in current
> Protege.
> >>
> >>You need to add the :NAME slot as template slot to
> your class. If you
> >>don't want it to be visible on the instance form,
> you can set its slot
> >>widget to "none" in the FormsTab.
> >>
> >>In this way, the :NAME slot becomes availabe as a
> display slot. You can
> >>use it also in combination with other slots if you
> use the "Multiple
> >>slots.." option.
> >>
> >>Tania
> >>
> >>
> >>
> >>Tania Tudorache wrote:
> >>
> >>
> >>
> >>    
> >>
> >>>Hi Bob, Mike,
> >>>
> >>>I would have suggested the same thing as Mike:
> modeling the concepts as
> >>>classes rather than instances. But this still
> does not solve Bob's
> >>>problem. From what I understood he wants at
> "edit" time to restrict the
> >>>values of location if species is already set. So,
> if the species of B17
> >>>is Tritonia, he wants to have the location
> limited to "Cerebral, Buccal
> >>>and Pedal". You can realize this only if you make
> the B17 be a subclass
> >>>of Tritonia. If you set at Tritonia class the
> allowed classes for
> >>>nervous_system to "Cerebral, Buccal and Pedal",
> and B17 is a subclass of
> >>>Tritonia, then you will inherit the allowed
> locations to B17 also.
> >>>However you must check if this modeling is
> actually what you mean.
> >>>
> >>>In general, there are certain restrictions that
> are imposed by the
> >>>semantics of the representation language, like
> for example that allowed
> >>>classes can only be restricted in subclasses.
> But, there might other
> >>>things that you need to cover by using axioms,
> constraints, rules etc.
> >>>In your case, you need to state a rule: "If
> species = Tritonia then
> >>>locations = {Cerebral, Buccal, Pedal}". You can
> also formulate a general
> >>>rule:
> >>>"If Neuron.species= ?species  => Neuron.location
> =
> >>>?species.nervous_system" I used here ?species as
> a variable and
> >>>Neuron.species is the species slot from Neuron
> class.
> >>>
> >>>You also have to know when you want to check
> these restrictions. For
> >>>example, by using PAL axioms, like Samson
> suggested, you could check in
> >>>the PAL Tab if the restrictions are violated or
> not. But you don't have
> >>>any support at edit time. So for example, when
> editing the locations for
> >>>B17, you will get the list of all locations, not
> only of the "correct"
> >>>locations. In order to get support at edit time
> you would have to
> >>>implement a slot widget, for example.
> >>>
> >>>Bob, I have added your feature request to our
> list.
> >>>
> >>>Tania
> >>>
> >>>Mike Bada wrote:
> >>>
> >>>
> >>>
> >>>  
> >>>
> >>>      
> >>>
> >>>>Hi Bob,
> >>>>
> >>>>I'd like to first suggest that your instances
> would be better modeled as
> >>>>classes:  For example, cerebral ganglia,
> tritonians, and B17 neurons,
> >>>>even though they are more specific than ganglia,
> organisms, and neurons,
> >>>>respectively, are still all types of things.
> Ideally, an instance
> >>>>refers to a single thing, such as a single
> cerebral ganglion or a
> >>>>tritonian, regardless whether or not you
> actually need to make instances
> >>>>for specific ganglia or tritonians for your
> task.
> >>>>
> >>>>If you instead model these instances as classes,
> you can then use
> >>>>overriding of the allowed classes of slots to
> progressively restrict the
> >>>>values of the slots down the class hierarchy.
> At the level of "neuron",
> >>>>the allowed class of "location" could be set to
> "ganglion"; this says
> >>>>that neurons can be located in ganglia.  Then,
> for example, at the level
> >>>>of "B17 neuron" (represented as a subclass of
> "neuron"), the allowed
> >>>>classes of "location" could be further
> restricted to the types of
> >>>>ganglia (represented as subclasses of
> "ganglion") in which B17 neurons
> >>>>can be located; this states that B17 neurons can
> be located in cerebral
> >>>>ganglia (or wherever they're located).  At the
> level of "tritonian B17
> >>>>neuron" (a subclass of "B17 neuron") this might
> be further restricted, etc.
> >>>>
> >>>>Cheers,
> >>>>Mike
> >>>>
> >>>>Bob Calin-Jageman wrote:
> >>>>
> >>>>
> >>>>
> >>>>  
> >>>>
> >>>>    
> >>>>
> >>>>        
> >>>>
> >>>>>The replies I had to my last query were
> extremely helpful (Thanks Tania
> >>>>>and Samson), so I thought I'd seek help on
> another problem I'm having.
> >>>>>
> >>>>>The problem is representing how the value of a
> slot restricts the values
> >>>>>of other slot.  For example, every address has
> a city and a state, but
> >>>>>once you choose a state the options for the
> city become more limited.  
> >>>>>In my specific domain, this problem arises in
> representing how a
> >>>>>neuron's properties depend on its speces.  For
> example:
> >>>>>
> >>>>>Class - Ganglia.
> >>>>>Slots: Name.
> >>>>>Instances: Cerebral, Pedal, Buccal, Abdominal)
> >>>>>Class - Organisms.
> >>>>>Slots: Name, Nervous_System (Instance of
> Ganglia)
> >>>>>Instances: Tritonia (Cerebral, Pedal, Buccal),
> Aplysia (Cerebral,
> >>>>>Abdominal, Buccal)
> >>>>>Class - Neuron
> >>>>>Slots: Name, Species (Instance of Organism),
> Location (Instance of
> >>>>>Ganglia)
> >>>>>Instances: B17 (Tritonia; Pedal), L13 (Aplysia;
> Buccal), etc.
> >>>>>
> >>>>>I want to make it so that the value of a
> Neuron's species restricts that
> >>>>>range of valid locations.  Note that this is
> not a problem only for
> >>>>>locations, but for many other relationships
> we'd like to define.  How do
> >>>>>I represent this is Protege?  Or, is this
> something that should be done
> >>>>>via application logic?
> >>>>>
> >>>>>Bob
> >>>>>
> >>>>>One feature request: To make the class name
> available as a parameter for
> >>>>>a multiple display slot.
>
>>>>>-------------------------------------------------------------------------
> >>>>>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
> >>>
> >>>
> >>>
> >>>
> >>>  
> >>>
> >>>      
> >>>
>
>>-------------------------------------------------------------------------
> >>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
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

12