Two Questions

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

Two Questions

Julian Vincent-3
1. I have a problem with the validity of DLQuery expressions in different issues of Protege  (I've mentioned this in a previous post but didn't get a useful answer).  The snippet below is taken from a class in the ontology:

  I can query this with "hasTrizResolution some (IP_02 and IP_24)" in an ontology written with P4.1 and have the Class returned, but it doesn't work with P4.3, when I have to use "hasTrizResolution some IP_02 and hasTrizResolution some IP_24" which (for the way I want to use the query) is extremely inconvenient.  What changed between P.1 and P4.3?  I should add that I had some replies to this from a previous posting a few months ago, which explained the difference between the two queries but I'm afraid I really didn't understand the argument.  Aside from that, the form of the query which P4.1 allows me is the one I wish to use, independent of any sort of argument against it.

2.  In order to overcome this difficulty, one way out is to merge a later version (now in P5) of the ontology, or parts of it, with an earlier version (written using P4.1).  How can I do this?

Many thanks
Julian Vincent

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Two Questions

Timothy Redmond

I will assume for this answer that the three axioms that you have displayed are in the "SubClassOf" section.  If they are in the "Equivalent To" section then the answers are very different and I suspect that the ontology does not say what you want it to say.

For simplicity lets call the class being described in your included screenshot C.

On 08/02/2014 07:41 AM, Julian Vincent wrote:
1. I have a problem with the validity of DLQuery expressions in different issues of Protege  (I've mentioned this in a previous post but didn't get a useful answer).  The snippet below is taken from a class in the ontology:

  I can query this with "hasTrizResolution some (IP_02 and IP_24)" in an ontology written with P4.1 and have the Class returned, but it doesn't work with P4.3, when I have to use "hasTrizResolution some IP_02 and hasTrizResolution some IP_24" which (for the way I want to use the query) is extremely inconvenient. 

I suspect that the core problem here is in the meaning of "IP_02 and IP_24" in the expression above.  (There is also the problem of anticipated inferences but I will come to that later.)  "IP_02 and IP_24" represents those individuals that are in both IP_02 and IP_24 classes.  The axioms that your diagram represents only states that an individual in the C class has at least one hasTrizResolution value in each of the IP_02, IP_24 and IP_26 classes.  It does not require that it has a hasTrizResolution value that is in both IP_02 and in IP_24 at the same time.

I knew I might have trouble explaining this so I drew a picture:


The point in the upper left (x) may be a member of the C class that you are describing and the three arrows leaving it represent three hasTrizResolution values in each of the IP_02, IP_24 and IP_26 classes.  The shaded region represents the intersection of IP_02 and IP_24, or in OWL parlance "IP_02 and IP_24".  In the picture that I have shown, x may be a member of C but is not a member of

              hasTrizResolution some (IP_02 and IP_24)

The following picture shows an example of a member (y) of this last class

Note that y, as shown, does not have a hasTrizResolution value in the IP_26 class so it cannot be in the C class.  Note also that x from the previous figure is not a member of


              hasTrizResolution some (IP_02 and IP_24)


So now we have the question of what inference you are expecting.  "hasTrizResolution some (IP_02 and IP_24)" is not known to be a super-class of C. In particular x from the first figure might be C but is not in "hasTrizResolution some (IP_02 and IP_24)".  "hasTrizResolution some (IP_02 and IP_24)" is not known to a sub-class of C because, among other reasons, "hasTrizResolution some (IP_02 and IP_24)" does not indicate that there is a hasTrizResolution value in the IP_26 class.

In contrast -- because you mentioned this class expression -- a member of the
     (hasTrizResolution some IP_02) and (hasTrizResolution some IP_24) 
might be like the individual z in the following diagram:




Note that as drawn z is not a member of the C class either because it does not have a hasTrizResolution value in the IP_26 class.


What changed between P.1 and P4.3?

Lots of things have changed - though I suspect that they do not have any impact on this query.  If I remember my Protege numbering right -- I might be off by one version number though -- I think that Protege 4.1 is not a recommended version to use any more.

But in the context of what you are asking, the best that you can expect is that one of them (probably Protege 4.1) has a bug.  The nature of inference will not change as we make new versions of software.  So different versions of Protege should come to the same conclusions given the same inputs.


 I should add that I had some replies to this from a previous posting a few months ago, which explained the difference between the two queries but I'm afraid I really didn't understand the argument.  Aside from that, the form of the query which P4.1 allows me is the one I wish to use, independent of any sort of argument against it.

I think that you should choose class expresssions because they mean what you want to say, not because they have any particular syntactic format.  If the class expression means what you want it to say then there should be an argument that you can make the expected inferences about it.


2.  In order to overcome this difficulty, one way out is to merge a later version (now in P5) of the ontology, or parts of it, with an earlier version (written using P4.1).  How can I do this?

I don't think that this makes sense.

I think that the right way to think about this problem is to talk about inferences that you expect Protege (or a Protege reasoner) to see and then we can talk about why these inferences either do or do not follow.  If some inference that should follow is not seen in Protege, then this might turn into a bug report against Protege or a Protege reasoner.

This process will be easier if you provide an ontology and some expected inferences for us to look at (so that we don't guess at your intended meaning).

-Timothy




Many thanks
Julian Vincent


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Two Questions

Lorenz Buehmann
In short form, both concepts

r some (A and B)
(r some A) and (r some B)

are totally different.

Lorenz
On 08/02/2014 10:15 PM, Timothy Redmond wrote:

I will assume for this answer that the three axioms that you have displayed are in the "SubClassOf" section.  If they are in the "Equivalent To" section then the answers are very different and I suspect that the ontology does not say what you want it to say.

For simplicity lets call the class being described in your included screenshot C.

On 08/02/2014 07:41 AM, Julian Vincent wrote:
1. I have a problem with the validity of DLQuery expressions in different issues of Protege  (I've mentioned this in a previous post but didn't get a useful answer).  The snippet below is taken from a class in the ontology:

  I can query this with "hasTrizResolution some (IP_02 and IP_24)" in an ontology written with P4.1 and have the Class returned, but it doesn't work with P4.3, when I have to use "hasTrizResolution some IP_02 and hasTrizResolution some IP_24" which (for the way I want to use the query) is extremely inconvenient. 

I suspect that the core problem here is in the meaning of "IP_02 and IP_24" in the expression above.  (There is also the problem of anticipated inferences but I will come to that later.)  "IP_02 and IP_24" represents those individuals that are in both IP_02 and IP_24 classes.  The axioms that your diagram represents only states that an individual in the C class has at least one hasTrizResolution value in each of the IP_02, IP_24 and IP_26 classes.  It does not require that it has a hasTrizResolution value that is in both IP_02 and in IP_24 at the same time.

I knew I might have trouble explaining this so I drew a picture:


The point in the upper left (x) may be a member of the C class that you are describing and the three arrows leaving it represent three hasTrizResolution values in each of the IP_02, IP_24 and IP_26 classes.  The shaded region represents the intersection of IP_02 and IP_24, or in OWL parlance "IP_02 and IP_24".  In the picture that I have shown, x may be a member of C but is not a member of

              hasTrizResolution some (IP_02 and IP_24)

The following picture shows an example of a member (y) of this last class

Note that y, as shown, does not have a hasTrizResolution value in the IP_26 class so it cannot be in the C class.  Note also that x from the previous figure is not a member of


              hasTrizResolution some (IP_02 and IP_24)


So now we have the question of what inference you are expecting.  "hasTrizResolution some (IP_02 and IP_24)" is not known to be a super-class of C. In particular x from the first figure might be C but is not in "hasTrizResolution some (IP_02 and IP_24)".  "hasTrizResolution some (IP_02 and IP_24)" is not known to a sub-class of C because, among other reasons, "hasTrizResolution some (IP_02 and IP_24)" does not indicate that there is a hasTrizResolution value in the IP_26 class.

In contrast -- because you mentioned this class expression -- a member of the
     (hasTrizResolution some IP_02) and (hasTrizResolution some IP_24) 
might be like the individual z in the following diagram:




Note that as drawn z is not a member of the C class either because it does not have a hasTrizResolution value in the IP_26 class.


What changed between P.1 and P4.3?

Lots of things have changed - though I suspect that they do not have any impact on this query.  If I remember my Protege numbering right -- I might be off by one version number though -- I think that Protege 4.1 is not a recommended version to use any more.

But in the context of what you are asking, the best that you can expect is that one of them (probably Protege 4.1) has a bug.  The nature of inference will not change as we make new versions of software.  So different versions of Protege should come to the same conclusions given the same inputs.


 I should add that I had some replies to this from a previous posting a few months ago, which explained the difference between the two queries but I'm afraid I really didn't understand the argument.  Aside from that, the form of the query which P4.1 allows me is the one I wish to use, independent of any sort of argument against it.

I think that you should choose class expresssions because they mean what you want to say, not because they have any particular syntactic format.  If the class expression means what you want it to say then there should be an argument that you can make the expected inferences about it.


2.  In order to overcome this difficulty, one way out is to merge a later version (now in P5) of the ontology, or parts of it, with an earlier version (written using P4.1).  How can I do this?

I don't think that this makes sense.

I think that the right way to think about this problem is to talk about inferences that you expect Protege (or a Protege reasoner) to see and then we can talk about why these inferences either do or do not follow.  If some inference that should follow is not seen in Protege, then this might turn into a bug report against Protege or a Protege reasoner.

This process will be easier if you provide an ontology and some expected inferences for us to look at (so that we don't guess at your intended meaning).

-Timothy




Many thanks
Julian Vincent


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Two Questions

Julian Vincent-2
To Lorenz:  I could have told you (and did) that the two are totally different.  But why, and how do you manipulate the system to take advantage of that difference?

To Timothy: Many thanks for your clear exposition.  You make it clear that the root of the difference is whether or not A and B are disjoint.  With that weapon in my hand I could write a 5-line ontology and play with it, and sorted out where the differences are - to get my desired format (the (A and B) one) I need A and B not to be disjunct and the and the object property to be Functional. I can revert to separation of the classes for later use, but I need the (A and B) format for internal testing.  With all the variables available it was difficult to see which was most important and thus to have a firm starting point.

The thought then occurs to me - I couldn't solve this problem using the Manchester tutorial, and often the explanations in that and other tutorials are difficult for me (non-mathematician with little founding in logic) to understand.  It would be very helpful to have a number of exercises which illustrate these points.  This is a common ploy in coding manuals.

But finally - many thanks for your clarity.
Julian


On 3 Aug 2014, at 08:13, Lorenz Bühmann <[hidden email]> wrote:

> In short form, both concepts
>
> r some (A and B)
> (r some A) and (r some B)
>
> are totally different.
>
> Lorenz
> On 08/02/2014 10:15 PM, Timothy Redmond wrote:
>>
>> I will assume for this answer that the three axioms that you have displayed are in the "SubClassOf" section.  If they are in the "Equivalent To" section then the answers are very different and I suspect that the ontology does not say what you want it to say.
>>
>> For simplicity lets call the class being described in your included screenshot C.
>>
>> On 08/02/2014 07:41 AM, Julian Vincent wrote:
>>> 1. I have a problem with the validity of DLQuery expressions in different issues of Protege  (I've mentioned this in a previous post but didn't get a useful answer).  The snippet below is         taken from a class in the ontology:
>>>
>>>   I can query this with "hasTrizResolution some (IP_02 and IP_24)" in an ontology written with P4.1 and have the Class returned, but it doesn't work with P4.3, when I have to use "hasTrizResolution some IP_02 and hasTrizResolution some IP_24" which (for the way I want to use the query) is extremely inconvenient.  
>>
>> I suspect that the core problem here is in the meaning of "IP_02 and IP_24" in the expression above.  (There is also the problem of anticipated inferences but I will come to that later.)  "IP_02 and IP_24" represents those individuals that are in both IP_02 and IP_24 classes.  The axioms that your diagram represents only states that an individual in the C class has at least one hasTrizResolution value in each of the IP_02, IP_24 and IP_26 classes.  It does not require that it has a hasTrizResolution value that is in both IP_02 and in IP_24 at the same time.
>>
>> I knew I might have trouble explaining this so I drew a picture:
>>
>> <Mail Attachment.png>
>> The point in the upper left (x) may be a member of the C class that you are describing and the three arrows leaving it represent three hasTrizResolution values in each of the IP_02, IP_24 and IP_26 classes.  The shaded region represents the intersection of IP_02 and IP_24, or in OWL parlance "IP_02 and IP_24".  In the picture that I have shown, x may be a member of C but is not a member of
>>
>>               hasTrizResolution some (IP_02 and IP_24)
>>
>>
>> The following picture shows an example of a member (y) of this last class
>> <Mail Attachment.png>
>> Note that y, as shown, does not have a hasTrizResolution value in the IP_26 class so it cannot be in the C class.  Note also that x from the previous figure is not a member of
>>
>>
>>               hasTrizResolution some (IP_02 and IP_24)
>>
>>
>>
>> So now we have the question of what inference you are expecting.  "hasTrizResolution some (IP_02 and IP_24)" is not known to be a super-class of C. In particular x from the first figure might be C but is not in "hasTrizResolution some (IP_02 and IP_24)".  "hasTrizResolution some (IP_02 and IP_24)" is not known to a sub-class of C because, among other reasons, "hasTrizResolution some (IP_02 and IP_24)" does not indicate that there is a hasTrizResolution value in the IP_26 class.
>>
>> In contrast -- because you mentioned this class expression -- a member of the
>>      (hasTrizResolution some IP_02) and (hasTrizResolution some IP_24)
>>
>> might be like the individual z in the following diagram:
>>
>>
>> <Mail Attachment.png>
>>
>> Note that as drawn z is not a member of the C class either because it does not have a hasTrizResolution value in the IP_26 class.
>>
>>
>>> What changed between P.1 and P4.3?
>>
>> Lots of things have changed - though I suspect that they do not have any impact on this query.  If I remember my Protege numbering right -- I might be off by one version number though -- I think that Protege 4.1 is not a recommended version to use any more.
>>
>> But in the context of what you are asking, the best that you can expect is that one of them (probably Protege 4.1) has a bug.  The nature of inference will not change as we make new versions of software.  So different versions of Protege should come to the same conclusions given the same inputs.
>>
>>
>>>  I should add that I had some replies to this from a previous posting a few months ago, which explained the difference between the two queries but I'm afraid I really didn't understand the argument.  Aside from that, the form of the query which P4.1 allows me is the one I wish to use, independent of any sort of argument against it.
>>
>> I think that you should choose class expresssions because they mean what you want to say, not because they have any particular syntactic format.  If the class expression means what you want it to say then there should be an argument that you can make the expected inferences about it.
>>
>>>
>>> 2.  In order to overcome this difficulty, one way out is to merge a later version (now in P5) of the ontology, or parts of it, with an earlier version (written using P4.1).  How can I do this?
>>
>> I don't think that this makes sense.
>>
>> I think that the right way to think about this problem is to talk about inferences that you expect Protege (or a Protege reasoner) to see and then we can talk about why these inferences either do or do not follow.  If some inference that should follow is not seen in Protege, then this might turn into a bug report against Protege or a Protege reasoner.
>>
>> This process will be easier if you provide an ontology and some expected inferences for us to look at (so that we don't guess at your intended meaning).
>>
>> -Timothy
>>
>>
>>
>>>
>>> Many thanks
>>> Julian Vincent
>>>
>>>
>>> _______________________________________________
>>> protege-user mailing list
>>>
>>> [hidden email]
>>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>>
>>
>>
>> _______________________________________________
>> protege-user mailing list
>>
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>
> _______________________________________________
> protege-user mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

Reply | Threaded
Open this post in threaded view
|

two questions about SKOS

Iman Gharib
hello dear all,
i am a student in germany and have two questions about SKOS and i would be really thankful if you could help.
I am using SKOS in Protege and i try to make an ontology from a thesaurus.
my first question: I would like to know what is the different between skos related to and skos has related? are they just opposite?

my second question: how can i use skosxl in protege?

i do appreciate your help
Iman
 

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Two Questions

Timothy Redmond
In reply to this post by Julian Vincent-2

> But why, and how do you manipulate the system to take advantage of that difference?

In my opinion, this is the wrong point of view.  My thinking is that OWL
is a specification language, so you should use it - within the limits of
practicality - to say what you mean. Once you do this the reasoners will
behave as you expect.

-Timothy


On 08/03/2014 04:27 AM, Julian Vincent wrote:

> To Lorenz:  I could have told you (and did) that the two are totally different.  But why, and how do you manipulate the system to take advantage of that difference?
>
> To Timothy: Many thanks for your clear exposition.  You make it clear that the root of the difference is whether or not A and B are disjoint.  With that weapon in my hand I could write a 5-line ontology and play with it, and sorted out where the differences are - to get my desired format (the (A and B) one) I need A and B not to be disjunct and the and the object property to be Functional. I can revert to separation of the classes for later use, but I need the (A and B) format for internal testing.  With all the variables available it was difficult to see which was most important and thus to have a firm starting point.
>
> The thought then occurs to me - I couldn't solve this problem using the Manchester tutorial, and often the explanations in that and other tutorials are difficult for me (non-mathematician with little founding in logic) to understand.  It would be very helpful to have a number of exercises which illustrate these points.  This is a common ploy in coding manuals.
>
> But finally - many thanks for your clarity.
> Julian
>
>
> On 3 Aug 2014, at 08:13, Lorenz Bühmann <[hidden email]> wrote:
>
>> In short form, both concepts
>>
>> r some (A and B)
>> (r some A) and (r some B)
>>
>> are totally different.
>>
>> Lorenz
>> On 08/02/2014 10:15 PM, Timothy Redmond wrote:
>>> I will assume for this answer that the three axioms that you have displayed are in the "SubClassOf" section.  If they are in the "Equivalent To" section then the answers are very different and I suspect that the ontology does not say what you want it to say.
>>>
>>> For simplicity lets call the class being described in your included screenshot C.
>>>
>>> On 08/02/2014 07:41 AM, Julian Vincent wrote:
>>>> 1. I have a problem with the validity of DLQuery expressions in different issues of Protege  (I've mentioned this in a previous post but didn't get a useful answer).  The snippet below is         taken from a class in the ontology:
>>>>
>>>>    I can query this with "hasTrizResolution some (IP_02 and IP_24)" in an ontology written with P4.1 and have the Class returned, but it doesn't work with P4.3, when I have to use "hasTrizResolution some IP_02 and hasTrizResolution some IP_24" which (for the way I want to use the query) is extremely inconvenient.
>>> I suspect that the core problem here is in the meaning of "IP_02 and IP_24" in the expression above.  (There is also the problem of anticipated inferences but I will come to that later.)  "IP_02 and IP_24" represents those individuals that are in both IP_02 and IP_24 classes.  The axioms that your diagram represents only states that an individual in the C class has at least one hasTrizResolution value in each of the IP_02, IP_24 and IP_26 classes.  It does not require that it has a hasTrizResolution value that is in both IP_02 and in IP_24 at the same time.
>>>
>>> I knew I might have trouble explaining this so I drew a picture:
>>>
>>> <Mail Attachment.png>
>>> The point in the upper left (x) may be a member of the C class that you are describing and the three arrows leaving it represent three hasTrizResolution values in each of the IP_02, IP_24 and IP_26 classes.  The shaded region represents the intersection of IP_02 and IP_24, or in OWL parlance "IP_02 and IP_24".  In the picture that I have shown, x may be a member of C but is not a member of
>>>
>>>                hasTrizResolution some (IP_02 and IP_24)
>>>
>>>
>>> The following picture shows an example of a member (y) of this last class
>>> <Mail Attachment.png>
>>> Note that y, as shown, does not have a hasTrizResolution value in the IP_26 class so it cannot be in the C class.  Note also that x from the previous figure is not a member of
>>>
>>>
>>>                hasTrizResolution some (IP_02 and IP_24)
>>>
>>>
>>>
>>> So now we have the question of what inference you are expecting.  "hasTrizResolution some (IP_02 and IP_24)" is not known to be a super-class of C. In particular x from the first figure might be C but is not in "hasTrizResolution some (IP_02 and IP_24)".  "hasTrizResolution some (IP_02 and IP_24)" is not known to a sub-class of C because, among other reasons, "hasTrizResolution some (IP_02 and IP_24)" does not indicate that there is a hasTrizResolution value in the IP_26 class.
>>>
>>> In contrast -- because you mentioned this class expression -- a member of the
>>>       (hasTrizResolution some IP_02) and (hasTrizResolution some IP_24)
>>>
>>> might be like the individual z in the following diagram:
>>>
>>>
>>> <Mail Attachment.png>
>>>
>>> Note that as drawn z is not a member of the C class either because it does not have a hasTrizResolution value in the IP_26 class.
>>>
>>>
>>>> What changed between P.1 and P4.3?
>>> Lots of things have changed - though I suspect that they do not have any impact on this query.  If I remember my Protege numbering right -- I might be off by one version number though -- I think that Protege 4.1 is not a recommended version to use any more.
>>>
>>> But in the context of what you are asking, the best that you can expect is that one of them (probably Protege 4.1) has a bug.  The nature of inference will not change as we make new versions of software.  So different versions of Protege should come to the same conclusions given the same inputs.
>>>
>>>
>>>>   I should add that I had some replies to this from a previous posting a few months ago, which explained the difference between the two queries but I'm afraid I really didn't understand the argument.  Aside from that, the form of the query which P4.1 allows me is the one I wish to use, independent of any sort of argument against it.
>>> I think that you should choose class expresssions because they mean what you want to say, not because they have any particular syntactic format.  If the class expression means what you want it to say then there should be an argument that you can make the expected inferences about it.
>>>
>>>> 2.  In order to overcome this difficulty, one way out is to merge a later version (now in P5) of the ontology, or parts of it, with an earlier version (written using P4.1).  How can I do this?
>>> I don't think that this makes sense.
>>>
>>> I think that the right way to think about this problem is to talk about inferences that you expect Protege (or a Protege reasoner) to see and then we can talk about why these inferences either do or do not follow.  If some inference that should follow is not seen in Protege, then this might turn into a bug report against Protege or a Protege reasoner.
>>>
>>> This process will be easier if you provide an ontology and some expected inferences for us to look at (so that we don't guess at your intended meaning).
>>>
>>> -Timothy
>>>
>>>
>>>
>>>> Many thanks
>>>> Julian Vincent
>>>>
>>>>
>>>> _______________________________________________
>>>> protege-user mailing list
>>>>
>>>> [hidden email]
>>>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>>>
>>>
>>> _______________________________________________
>>> protege-user mailing list
>>>
>>> [hidden email]
>>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>> _______________________________________________
>> protege-user mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-user
> _______________________________________________
> protege-user mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-user
>


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user