query regarding ontology design using modifiers

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

query regarding ontology design using modifiers

Neha Sood
Hi everyone,

I have a query regarding ontology design. How can i add frequency of certain event in an ontology. 

For instance, a person P visit place A rarely, place B usually,  Thus, different modifiers are required to draw the person  visiting habbit in an ontology. 
How should i represent frequency modifier in ontology as per your suggestion.
a) Whether i should add a class with individuals as rarely,sometime,always etc. modifiers,
or b)  as a data property with these modifier values as literals. In this case, i need , do i need to create separate frequency variable for each place.

Thanks a lot in advance!!

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

Re: query regarding ontology design using modifiers

Michael DeBellis-2
You can do it either way but IMO the best way to do it is to make visitFrequency an object property and to make it have a range which is an enumerated class. So you can define a class called Frequency and in the EquivalentTo field define that class with the expression {Rarely, Sometimes, Always}. Note: be sure to create Rarely, Sometimes, and Always as individuals that are instances of Frequency before you add that definition. Doing it this way eliminates some potential errors of mis-spelling a string and also give you completion when writing rules or DL statements by typing <cntl><space>.  

Another advantage is you can create an order for your frequencies if you want to. So you could have an object property with domain and range of Frequency called isMoreFrequentThan (with inverse isLessFrequentThan) and you could declare that Sometimes isMoreFrequentThan Rarely. You could also declare isMoreFrequentThan to be transitive so the reasoner would make inferences like: if Sometimes  isMoreFrequentThan Rarely and Always  isMoreFrequentThan Sometimes then Always  isMoreFrequentThan Rarely. 

Michael

On Thu, Sep 19, 2019 at 11:22 AM Neha Sood <[hidden email]> wrote:
Hi everyone,

I have a query regarding ontology design. How can i add frequency of certain event in an ontology. 

For instance, a person P visit place A rarely, place B usually,  Thus, different modifiers are required to draw the person  visiting habbit in an ontology. 
How should i represent frequency modifier in ontology as per your suggestion.
a) Whether i should add a class with individuals as rarely,sometime,always etc. modifiers,
or b)  as a data property with these modifier values as literals. In this case, i need , do i need to create separate frequency variable for each place.

Thanks a lot in advance!!
_______________________________________________
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: query regarding ontology design using modifiers

Neha Sood
Thanks a lot for this suggestion!! i am working on this solution and i think, it will definitely suit ontology design.

Best Regards,
Neha


On Fri, Sep 20, 2019 at 12:28 AM Michael DeBellis <[hidden email]> wrote:
You can do it either way but IMO the best way to do it is to make visitFrequency an object property and to make it have a range which is an enumerated class. So you can define a class called Frequency and in the EquivalentTo field define that class with the expression {Rarely, Sometimes, Always}. Note: be sure to create Rarely, Sometimes, and Always as individuals that are instances of Frequency before you add that definition. Doing it this way eliminates some potential errors of mis-spelling a string and also give you completion when writing rules or DL statements by typing <cntl><space>.  

Another advantage is you can create an order for your frequencies if you want to. So you could have an object property with domain and range of Frequency called isMoreFrequentThan (with inverse isLessFrequentThan) and you could declare that Sometimes isMoreFrequentThan Rarely. You could also declare isMoreFrequentThan to be transitive so the reasoner would make inferences like: if Sometimes  isMoreFrequentThan Rarely and Always  isMoreFrequentThan Sometimes then Always  isMoreFrequentThan Rarely. 

Michael

On Thu, Sep 19, 2019 at 11:22 AM Neha Sood <[hidden email]> wrote:
Hi everyone,

I have a query regarding ontology design. How can i add frequency of certain event in an ontology. 

For instance, a person P visit place A rarely, place B usually,  Thus, different modifiers are required to draw the person  visiting habbit in an ontology. 
How should i represent frequency modifier in ontology as per your suggestion.
a) Whether i should add a class with individuals as rarely,sometime,always etc. modifiers,
or b)  as a data property with these modifier values as literals. In this case, i need , do i need to create separate frequency variable for each place.

Thanks a lot in advance!!
_______________________________________________
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: query regarding ontology design using modifiers

Michael DeBellis-2
Neha, you're welcome.  You've probably figured it out by now but I'm working on a few articles for my blog where I describe common tips and patterns that are useful for OWL and Protege and this was one example I was planning to do anyway. I haven't written the article yet but I did create a quick demo ontology I thought I would share with you just to give a concrete example. I have three object properties: listensToBritney, listensToMahler, and listensToREM. I have 5 instances of the enumerated class Frequency: Never, Seldom, Sometimes, Often, Always. I put them in order using the properties isMoreFrequentThan and isLessFrequentThan. 

This is a nice little example of the power of OWL. Because the two properties are inverses and transitive, all I had to do was enter the order that Never isLessFrequentThan Seldom, Seldom, isLessFrequentThan Sometimes, etc. and everything else gets computed by the Reasoner. 

Then I included some SWRL rules to show how you could use this. E.g., if you had a system that was recommending music, there are rules like:

listensToMahler(?p, ?f) ^ isMoreFrequentThan(?f, Sometimes) -> suggestMusicBy(?p, Mahler)

I.e., if someone listens to Mahler more than Sometimes  then suggest  Mahler to them. Not exactly rocket science and if I was really doing it right I would make the listensTo property the equivalent of an n-ary relation by making a class that recorded the artist and frequency rather than having different properties for each artist but for the sake of demonstrating the Frequency enumerated class pattern I thought this was good enough. 

Michael

On Fri, Sep 20, 2019 at 1:04 AM Neha Sood <[hidden email]> wrote:
Thanks a lot for this suggestion!! i am working on this solution and i think, it will definitely suit ontology design.

Best Regards,
Neha


On Fri, Sep 20, 2019 at 12:28 AM Michael DeBellis <[hidden email]> wrote:
You can do it either way but IMO the best way to do it is to make visitFrequency an object property and to make it have a range which is an enumerated class. So you can define a class called Frequency and in the EquivalentTo field define that class with the expression {Rarely, Sometimes, Always}. Note: be sure to create Rarely, Sometimes, and Always as individuals that are instances of Frequency before you add that definition. Doing it this way eliminates some potential errors of mis-spelling a string and also give you completion when writing rules or DL statements by typing <cntl><space>.  

Another advantage is you can create an order for your frequencies if you want to. So you could have an object property with domain and range of Frequency called isMoreFrequentThan (with inverse isLessFrequentThan) and you could declare that Sometimes isMoreFrequentThan Rarely. You could also declare isMoreFrequentThan to be transitive so the reasoner would make inferences like: if Sometimes  isMoreFrequentThan Rarely and Always  isMoreFrequentThan Sometimes then Always  isMoreFrequentThan Rarely. 

Michael

On Thu, Sep 19, 2019 at 11:22 AM Neha Sood <[hidden email]> wrote:
Hi everyone,

I have a query regarding ontology design. How can i add frequency of certain event in an ontology. 

For instance, a person P visit place A rarely, place B usually,  Thus, different modifiers are required to draw the person  visiting habbit in an ontology. 
How should i represent frequency modifier in ontology as per your suggestion.
a) Whether i should add a class with individuals as rarely,sometime,always etc. modifiers,
or b)  as a data property with these modifier values as literals. In this case, i need , do i need to create separate frequency variable for each place.

Thanks a lot in advance!!
_______________________________________________
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

FrequencyExample.owl (27K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: query regarding ontology design using modifiers

Neha Sood
Thanks for this example. In this example, if there are 10 instances of musician, then is it good design pattern to create 10 listensToXXX  object properties or we say muscians(n)->listensToMusic(n) properties.?

On Sat, Sep 21, 2019 at 1:57 AM Michael DeBellis <[hidden email]> wrote:
Neha, you're welcome.  You've probably figured it out by now but I'm working on a few articles for my blog where I describe common tips and patterns that are useful for OWL and Protege and this was one example I was planning to do anyway. I haven't written the article yet but I did create a quick demo ontology I thought I would share with you just to give a concrete example. I have three object properties: listensToBritney, listensToMahler, and listensToREM. I have 5 instances of the enumerated class Frequency: Never, Seldom, Sometimes, Often, Always. I put them in order using the properties isMoreFrequentThan and isLessFrequentThan. 

This is a nice little example of the power of OWL. Because the two properties are inverses and transitive, all I had to do was enter the order that Never isLessFrequentThan Seldom, Seldom, isLessFrequentThan Sometimes, etc. and everything else gets computed by the Reasoner. 

Then I included some SWRL rules to show how you could use this. E.g., if you had a system that was recommending music, there are rules like:

listensToMahler(?p, ?f) ^ isMoreFrequentThan(?f, Sometimes) -> suggestMusicBy(?p, Mahler)

I.e., if someone listens to Mahler more than Sometimes  then suggest  Mahler to them. Not exactly rocket science and if I was really doing it right I would make the listensTo property the equivalent of an n-ary relation by making a class that recorded the artist and frequency rather than having different properties for each artist but for the sake of demonstrating the Frequency enumerated class pattern I thought this was good enough. 

Michael

On Fri, Sep 20, 2019 at 1:04 AM Neha Sood <[hidden email]> wrote:
Thanks a lot for this suggestion!! i am working on this solution and i think, it will definitely suit ontology design.

Best Regards,
Neha


On Fri, Sep 20, 2019 at 12:28 AM Michael DeBellis <[hidden email]> wrote:
You can do it either way but IMO the best way to do it is to make visitFrequency an object property and to make it have a range which is an enumerated class. So you can define a class called Frequency and in the EquivalentTo field define that class with the expression {Rarely, Sometimes, Always}. Note: be sure to create Rarely, Sometimes, and Always as individuals that are instances of Frequency before you add that definition. Doing it this way eliminates some potential errors of mis-spelling a string and also give you completion when writing rules or DL statements by typing <cntl><space>.  

Another advantage is you can create an order for your frequencies if you want to. So you could have an object property with domain and range of Frequency called isMoreFrequentThan (with inverse isLessFrequentThan) and you could declare that Sometimes isMoreFrequentThan Rarely. You could also declare isMoreFrequentThan to be transitive so the reasoner would make inferences like: if Sometimes  isMoreFrequentThan Rarely and Always  isMoreFrequentThan Sometimes then Always  isMoreFrequentThan Rarely. 

Michael

On Thu, Sep 19, 2019 at 11:22 AM Neha Sood <[hidden email]> wrote:
Hi everyone,

I have a query regarding ontology design. How can i add frequency of certain event in an ontology. 

For instance, a person P visit place A rarely, place B usually,  Thus, different modifiers are required to draw the person  visiting habbit in an ontology. 
How should i represent frequency modifier in ontology as per your suggestion.
a) Whether i should add a class with individuals as rarely,sometime,always etc. modifiers,
or b)  as a data property with these modifier values as literals. In this case, i need , do i need to create separate frequency variable for each place.

Thanks a lot in advance!!
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: query regarding ontology design using modifiers

Michael DeBellis-2
Yes, that's what I meant when I said the right solution would be to create the equivalent of an N-Ary relation. You can't just say that X listensToMusic Y you need to also say with what frequency, the equivalent of a ternary relation so you would have triples such as <Kenneth, REM, Often>,   But since you can't have ternary relations in OWL you have to reify the relation by creating a new class. Actually, after I sent my example the requirement for a rule for each artist bothered me even just for an example, so I redid the ontology and did just that. Now I have a Preference class that has properties for the Person that has the Preference, the Artist (in the sense of a musical Artist) that the Preference relates to and the Frequency that the Person listens to the Artist. That means rather than a rule for each Artist, now I just need one rule as you can see in the new version of the example ontology which is attached. 

Michael



On Sat, Sep 21, 2019 at 10:03 AM Neha Sood <[hidden email]> wrote:
Thanks for this example. In this example, if there are 10 instances of musician, then is it good design pattern to create 10 listensToXXX  object properties or we say muscians(n)->listensToMusic(n) properties.?

On Sat, Sep 21, 2019 at 1:57 AM Michael DeBellis <[hidden email]> wrote:
Neha, you're welcome.  You've probably figured it out by now but I'm working on a few articles for my blog where I describe common tips and patterns that are useful for OWL and Protege and this was one example I was planning to do anyway. I haven't written the article yet but I did create a quick demo ontology I thought I would share with you just to give a concrete example. I have three object properties: listensToBritney, listensToMahler, and listensToREM. I have 5 instances of the enumerated class Frequency: Never, Seldom, Sometimes, Often, Always. I put them in order using the properties isMoreFrequentThan and isLessFrequentThan. 

This is a nice little example of the power of OWL. Because the two properties are inverses and transitive, all I had to do was enter the order that Never isLessFrequentThan Seldom, Seldom, isLessFrequentThan Sometimes, etc. and everything else gets computed by the Reasoner. 

Then I included some SWRL rules to show how you could use this. E.g., if you had a system that was recommending music, there are rules like:

listensToMahler(?p, ?f) ^ isMoreFrequentThan(?f, Sometimes) -> suggestMusicBy(?p, Mahler)

I.e., if someone listens to Mahler more than Sometimes  then suggest  Mahler to them. Not exactly rocket science and if I was really doing it right I would make the listensTo property the equivalent of an n-ary relation by making a class that recorded the artist and frequency rather than having different properties for each artist but for the sake of demonstrating the Frequency enumerated class pattern I thought this was good enough. 

Michael

On Fri, Sep 20, 2019 at 1:04 AM Neha Sood <[hidden email]> wrote:
Thanks a lot for this suggestion!! i am working on this solution and i think, it will definitely suit ontology design.

Best Regards,
Neha


On Fri, Sep 20, 2019 at 12:28 AM Michael DeBellis <[hidden email]> wrote:
You can do it either way but IMO the best way to do it is to make visitFrequency an object property and to make it have a range which is an enumerated class. So you can define a class called Frequency and in the EquivalentTo field define that class with the expression {Rarely, Sometimes, Always}. Note: be sure to create Rarely, Sometimes, and Always as individuals that are instances of Frequency before you add that definition. Doing it this way eliminates some potential errors of mis-spelling a string and also give you completion when writing rules or DL statements by typing <cntl><space>.  

Another advantage is you can create an order for your frequencies if you want to. So you could have an object property with domain and range of Frequency called isMoreFrequentThan (with inverse isLessFrequentThan) and you could declare that Sometimes isMoreFrequentThan Rarely. You could also declare isMoreFrequentThan to be transitive so the reasoner would make inferences like: if Sometimes  isMoreFrequentThan Rarely and Always  isMoreFrequentThan Sometimes then Always  isMoreFrequentThan Rarely. 

Michael

On Thu, Sep 19, 2019 at 11:22 AM Neha Sood <[hidden email]> wrote:
Hi everyone,

I have a query regarding ontology design. How can i add frequency of certain event in an ontology. 

For instance, a person P visit place A rarely, place B usually,  Thus, different modifiers are required to draw the person  visiting habbit in an ontology. 
How should i represent frequency modifier in ontology as per your suggestion.
a) Whether i should add a class with individuals as rarely,sometime,always etc. modifiers,
or b)  as a data property with these modifier values as literals. In this case, i need , do i need to create separate frequency variable for each place.

Thanks a lot in advance!!
_______________________________________________
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

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

WhatsTheFrequencyKenneth.owl (30K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: query regarding ontology design using modifiers

Neha Sood

I saw this example and while executing this, another solution, with little variation, came to mind. I create an object property listensTo with domain and range person, another object property hasFrequency{always,never,..}. Now, we can create a rule using these object properties as, i extended ontology by adding another data property (loveForMusic)  which is boolean in nature, to test this.

FrequencyExample:Person(?p) ^ FrequencyExample:listensTo(?m1, FrequencyExample:Britney) ^ FrequencyExample:hasFrequency(?m1, FrequencyExample:Always) ^ FrequencyExample:listensTo(?m2, FrequencyExample:Mahler) ^ FrequencyExample:hasFrequency(?m2, FrequencyExample:Always) -> FrequencyExample:loveForMusic(?p, true)

What do you think about this way ?

 Though , i need to create separate value for every listenTo property for different musicians, i need not to create separate values for every frequency..as in extended ontology. Can this be further improved by restricting listenTo{A,B} for person p1, listensTo{A,B,C} for person p2 etc.somewhat..i may be vague in this suggestion.


On Sun, Sep 22, 2019 at 8:47 PM Michael DeBellis <[hidden email]> wrote:
Yes, that's what I meant when I said the right solution would be to create the equivalent of an N-Ary relation. You can't just say that X listensToMusic Y you need to also say with what frequency, the equivalent of a ternary relation so you would have triples such as <Kenneth, REM, Often>,   But since you can't have ternary relations in OWL you have to reify the relation by creating a new class. Actually, after I sent my example the requirement for a rule for each artist bothered me even just for an example, so I redid the ontology and did just that. Now I have a Preference class that has properties for the Person that has the Preference, the Artist (in the sense of a musical Artist) that the Preference relates to and the Frequency that the Person listens to the Artist. That means rather than a rule for each Artist, now I just need one rule as you can see in the new version of the example ontology which is attached. 

Michael



On Sat, Sep 21, 2019 at 10:03 AM Neha Sood <[hidden email]> wrote:
Thanks for this example. In this example, if there are 10 instances of musician, then is it good design pattern to create 10 listensToXXX  object properties or we say muscians(n)->listensToMusic(n) properties.?

On Sat, Sep 21, 2019 at 1:57 AM Michael DeBellis <[hidden email]> wrote:
Neha, you're welcome.  You've probably figured it out by now but I'm working on a few articles for my blog where I describe common tips and patterns that are useful for OWL and Protege and this was one example I was planning to do anyway. I haven't written the article yet but I did create a quick demo ontology I thought I would share with you just to give a concrete example. I have three object properties: listensToBritney, listensToMahler, and listensToREM. I have 5 instances of the enumerated class Frequency: Never, Seldom, Sometimes, Often, Always. I put them in order using the properties isMoreFrequentThan and isLessFrequentThan. 

This is a nice little example of the power of OWL. Because the two properties are inverses and transitive, all I had to do was enter the order that Never isLessFrequentThan Seldom, Seldom, isLessFrequentThan Sometimes, etc. and everything else gets computed by the Reasoner. 

Then I included some SWRL rules to show how you could use this. E.g., if you had a system that was recommending music, there are rules like:

listensToMahler(?p, ?f) ^ isMoreFrequentThan(?f, Sometimes) -> suggestMusicBy(?p, Mahler)

I.e., if someone listens to Mahler more than Sometimes  then suggest  Mahler to them. Not exactly rocket science and if I was really doing it right I would make the listensTo property the equivalent of an n-ary relation by making a class that recorded the artist and frequency rather than having different properties for each artist but for the sake of demonstrating the Frequency enumerated class pattern I thought this was good enough. 

Michael

On Fri, Sep 20, 2019 at 1:04 AM Neha Sood <[hidden email]> wrote:
Thanks a lot for this suggestion!! i am working on this solution and i think, it will definitely suit ontology design.

Best Regards,
Neha


On Fri, Sep 20, 2019 at 12:28 AM Michael DeBellis <[hidden email]> wrote:
You can do it either way but IMO the best way to do it is to make visitFrequency an object property and to make it have a range which is an enumerated class. So you can define a class called Frequency and in the EquivalentTo field define that class with the expression {Rarely, Sometimes, Always}. Note: be sure to create Rarely, Sometimes, and Always as individuals that are instances of Frequency before you add that definition. Doing it this way eliminates some potential errors of mis-spelling a string and also give you completion when writing rules or DL statements by typing <cntl><space>.  

Another advantage is you can create an order for your frequencies if you want to. So you could have an object property with domain and range of Frequency called isMoreFrequentThan (with inverse isLessFrequentThan) and you could declare that Sometimes isMoreFrequentThan Rarely. You could also declare isMoreFrequentThan to be transitive so the reasoner would make inferences like: if Sometimes  isMoreFrequentThan Rarely and Always  isMoreFrequentThan Sometimes then Always  isMoreFrequentThan Rarely. 

Michael

On Thu, Sep 19, 2019 at 11:22 AM Neha Sood <[hidden email]> wrote:
Hi everyone,

I have a query regarding ontology design. How can i add frequency of certain event in an ontology. 

For instance, a person P visit place A rarely, place B usually,  Thus, different modifiers are required to draw the person  visiting habbit in an ontology. 
How should i represent frequency modifier in ontology as per your suggestion.
a) Whether i should add a class with individuals as rarely,sometime,always etc. modifiers,
or b)  as a data property with these modifier values as literals. In this case, i need , do i need to create separate frequency variable for each place.

Thanks a lot in advance!!
_______________________________________________
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
_______________________________________________
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

FrequencyExample.owl (31K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: query regarding ontology design using modifiers

Michael DeBellis-2
If I'm understanding what you want to do here, you want to say that someone who listens to some Artist Always is a music lover. the way I would do that would be to create a defined class that was a subclass of Customer (in my version, I'm assuming we only have data on the listening preferences of Customers) called MusicLover that could be defined as: 

Customer
 and (hasPreference some
    (Preference
     and (preferenceFrequency value Always)))

This says that any Customer who has a Preference for any Artist that equals Always is an instance of the MusicLover class. This has the advantage that you can use the Preference class and rather than testing for each Artist (which means you need to edit the rule every time you add a new Artist)  the defined class will work for all Artists, as you add more you don't need to edit the rule. Note: you could also do this with a SWRL rule where the consequent was "-> MusicLover(?p)"  In SWRL classes are treated as unary predicates so on the left hand side "MusicLover(?p)" will succeed if p is an instance of the MusicLover class and on the right hand side it will make p an instance of the MusicLover class.  I changed my last version of the ontology and added the defined class MusicLover. As you can see in the latest attached version the reasoner infers that Michael is a MusicLover because he listens to Mahler Always. 

Also, FYI, there is a way to get rid of those annoying prefixes in the SWRL rule. I just haven't bothered with it for this simple example but if you want to know how see my blog post on it:  https://www.michaeldebellis.com/post/owl-swrl-protege-tips-1-removing-ontology-prefixes-from-swrl-rules 

Michael 

On Mon, Sep 23, 2019 at 6:22 AM Neha Sood <[hidden email]> wrote:

I saw this example and while executing this, another solution, with little variation, came to mind. I create an object property listensTo with domain and range person, another object property hasFrequency{always,never,..}. Now, we can create a rule using these object properties as, i extended ontology by adding another data property (loveForMusic)  which is boolean in nature, to test this.

FrequencyExample:Person(?p) ^ FrequencyExample:listensTo(?m1, FrequencyExample:Britney) ^ FrequencyExample:hasFrequency(?m1, FrequencyExample:Always) ^ FrequencyExample:listensTo(?m2, FrequencyExample:Mahler) ^ FrequencyExample:hasFrequency(?m2, FrequencyExample:Always) -> FrequencyExample:loveForMusic(?p, true)

What do you think about this way ?

 Though , i need to create separate value for every listenTo property for different musicians, i need not to create separate values for every frequency..as in extended ontology. Can this be further improved by restricting listenTo{A,B} for person p1, listensTo{A,B,C} for person p2 etc.somewhat..i may be vague in this suggestion.


On Sun, Sep 22, 2019 at 8:47 PM Michael DeBellis <[hidden email]> wrote:
Yes, that's what I meant when I said the right solution would be to create the equivalent of an N-Ary relation. You can't just say that X listensToMusic Y you need to also say with what frequency, the equivalent of a ternary relation so you would have triples such as <Kenneth, REM, Often>,   But since you can't have ternary relations in OWL you have to reify the relation by creating a new class. Actually, after I sent my example the requirement for a rule for each artist bothered me even just for an example, so I redid the ontology and did just that. Now I have a Preference class that has properties for the Person that has the Preference, the Artist (in the sense of a musical Artist) that the Preference relates to and the Frequency that the Person listens to the Artist. That means rather than a rule for each Artist, now I just need one rule as you can see in the new version of the example ontology which is attached. 

Michael



On Sat, Sep 21, 2019 at 10:03 AM Neha Sood <[hidden email]> wrote:
Thanks for this example. In this example, if there are 10 instances of musician, then is it good design pattern to create 10 listensToXXX  object properties or we say muscians(n)->listensToMusic(n) properties.?

On Sat, Sep 21, 2019 at 1:57 AM Michael DeBellis <[hidden email]> wrote:
Neha, you're welcome.  You've probably figured it out by now but I'm working on a few articles for my blog where I describe common tips and patterns that are useful for OWL and Protege and this was one example I was planning to do anyway. I haven't written the article yet but I did create a quick demo ontology I thought I would share with you just to give a concrete example. I have three object properties: listensToBritney, listensToMahler, and listensToREM. I have 5 instances of the enumerated class Frequency: Never, Seldom, Sometimes, Often, Always. I put them in order using the properties isMoreFrequentThan and isLessFrequentThan. 

This is a nice little example of the power of OWL. Because the two properties are inverses and transitive, all I had to do was enter the order that Never isLessFrequentThan Seldom, Seldom, isLessFrequentThan Sometimes, etc. and everything else gets computed by the Reasoner. 

Then I included some SWRL rules to show how you could use this. E.g., if you had a system that was recommending music, there are rules like:

listensToMahler(?p, ?f) ^ isMoreFrequentThan(?f, Sometimes) -> suggestMusicBy(?p, Mahler)

I.e., if someone listens to Mahler more than Sometimes  then suggest  Mahler to them. Not exactly rocket science and if I was really doing it right I would make the listensTo property the equivalent of an n-ary relation by making a class that recorded the artist and frequency rather than having different properties for each artist but for the sake of demonstrating the Frequency enumerated class pattern I thought this was good enough. 

Michael

On Fri, Sep 20, 2019 at 1:04 AM Neha Sood <[hidden email]> wrote:
Thanks a lot for this suggestion!! i am working on this solution and i think, it will definitely suit ontology design.

Best Regards,
Neha


On Fri, Sep 20, 2019 at 12:28 AM Michael DeBellis <[hidden email]> wrote:
You can do it either way but IMO the best way to do it is to make visitFrequency an object property and to make it have a range which is an enumerated class. So you can define a class called Frequency and in the EquivalentTo field define that class with the expression {Rarely, Sometimes, Always}. Note: be sure to create Rarely, Sometimes, and Always as individuals that are instances of Frequency before you add that definition. Doing it this way eliminates some potential errors of mis-spelling a string and also give you completion when writing rules or DL statements by typing <cntl><space>.  

Another advantage is you can create an order for your frequencies if you want to. So you could have an object property with domain and range of Frequency called isMoreFrequentThan (with inverse isLessFrequentThan) and you could declare that Sometimes isMoreFrequentThan Rarely. You could also declare isMoreFrequentThan to be transitive so the reasoner would make inferences like: if Sometimes  isMoreFrequentThan Rarely and Always  isMoreFrequentThan Sometimes then Always  isMoreFrequentThan Rarely. 

Michael

On Thu, Sep 19, 2019 at 11:22 AM Neha Sood <[hidden email]> wrote:
Hi everyone,

I have a query regarding ontology design. How can i add frequency of certain event in an ontology. 

For instance, a person P visit place A rarely, place B usually,  Thus, different modifiers are required to draw the person  visiting habbit in an ontology. 
How should i represent frequency modifier in ontology as per your suggestion.
a) Whether i should add a class with individuals as rarely,sometime,always etc. modifiers,
or b)  as a data property with these modifier values as literals. In this case, i need , do i need to create separate frequency variable for each place.

Thanks a lot in advance!!
_______________________________________________
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
_______________________________________________
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

WhatsTheFrequencyKenneth.owl (32K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: query regarding ontology design using modifiers

Neha Sood
Yes, somewhat like this, to further explain what i was seeking
There are four types of passes,{monthly,weekly,yearly}
5 places in an itenary
n number of people
So the rules i need to create are
1. if person p1 vistisPlace m1 always, visitsPlace m2 sometimes, visitsPlace m3 rarely then providePass(yearly)
or
 if person p1 vistisPlace m1 always, visitsPlace m2 always, visitsPlace m3 rarely then providePass(monthly)  
or 
 if person p1 vistisPlace m1 always, visitsPlace m2 sometimes, visitsPlace m3 always then providePass(weekly) 

so there are around 10 places, for which diffrent permutations will be to identify to whoom to give which pass..
So i am looking into this solution..now here, place m1 has higher priority than m2, so even if person doesn't visit m2 but visit m1 always, he/she will be given weekly pass.. so i am trying to model solution for such example,


In the abovesaid solution, equivalence relation would be fine, when there is only one or two values, i suppose, but many cases can create one equivalence class, so will this  be a good solution.

This conversation has really helped to modelling my casestudy. i look further to improve my model with these solutions

On Tue, Sep 24, 2019 at 4:10 AM Michael DeBellis <[hidden email]> wrote:
If I'm understanding what you want to do here, you want to say that someone who listens to some Artist Always is a music lover. the way I would do that would be to create a defined class that was a subclass of Customer (in my version, I'm assuming we only have data on the listening preferences of Customers) called MusicLover that could be defined as: 

Customer
 and (hasPreference some
    (Preference
     and (preferenceFrequency value Always)))

This says that any Customer who has a Preference for any Artist that equals Always is an instance of the MusicLover class. This has the advantage that you can use the Preference class and rather than testing for each Artist (which means you need to edit the rule every time you add a new Artist)  the defined class will work for all Artists, as you add more you don't need to edit the rule. Note: you could also do this with a SWRL rule where the consequent was "-> MusicLover(?p)"  In SWRL classes are treated as unary predicates so on the left hand side "MusicLover(?p)" will succeed if p is an instance of the MusicLover class and on the right hand side it will make p an instance of the MusicLover class.  I changed my last version of the ontology and added the defined class MusicLover. As you can see in the latest attached version the reasoner infers that Michael is a MusicLover because he listens to Mahler Always. 

Also, FYI, there is a way to get rid of those annoying prefixes in the SWRL rule. I just haven't bothered with it for this simple example but if you want to know how see my blog post on it:  https://www.michaeldebellis.com/post/owl-swrl-protege-tips-1-removing-ontology-prefixes-from-swrl-rules 

Michael 

On Mon, Sep 23, 2019 at 6:22 AM Neha Sood <[hidden email]> wrote:

I saw this example and while executing this, another solution, with little variation, came to mind. I create an object property listensTo with domain and range person, another object property hasFrequency{always,never,..}. Now, we can create a rule using these object properties as, i extended ontology by adding another data property (loveForMusic)  which is boolean in nature, to test this.

FrequencyExample:Person(?p) ^ FrequencyExample:listensTo(?m1, FrequencyExample:Britney) ^ FrequencyExample:hasFrequency(?m1, FrequencyExample:Always) ^ FrequencyExample:listensTo(?m2, FrequencyExample:Mahler) ^ FrequencyExample:hasFrequency(?m2, FrequencyExample:Always) -> FrequencyExample:loveForMusic(?p, true)

What do you think about this way ?

 Though , i need to create separate value for every listenTo property for different musicians, i need not to create separate values for every frequency..as in extended ontology. Can this be further improved by restricting listenTo{A,B} for person p1, listensTo{A,B,C} for person p2 etc.somewhat..i may be vague in this suggestion.


On Sun, Sep 22, 2019 at 8:47 PM Michael DeBellis <[hidden email]> wrote:
Yes, that's what I meant when I said the right solution would be to create the equivalent of an N-Ary relation. You can't just say that X listensToMusic Y you need to also say with what frequency, the equivalent of a ternary relation so you would have triples such as <Kenneth, REM, Often>,   But since you can't have ternary relations in OWL you have to reify the relation by creating a new class. Actually, after I sent my example the requirement for a rule for each artist bothered me even just for an example, so I redid the ontology and did just that. Now I have a Preference class that has properties for the Person that has the Preference, the Artist (in the sense of a musical Artist) that the Preference relates to and the Frequency that the Person listens to the Artist. That means rather than a rule for each Artist, now I just need one rule as you can see in the new version of the example ontology which is attached. 

Michael



On Sat, Sep 21, 2019 at 10:03 AM Neha Sood <[hidden email]> wrote:
Thanks for this example. In this example, if there are 10 instances of musician, then is it good design pattern to create 10 listensToXXX  object properties or we say muscians(n)->listensToMusic(n) properties.?

On Sat, Sep 21, 2019 at 1:57 AM Michael DeBellis <[hidden email]> wrote:
Neha, you're welcome.  You've probably figured it out by now but I'm working on a few articles for my blog where I describe common tips and patterns that are useful for OWL and Protege and this was one example I was planning to do anyway. I haven't written the article yet but I did create a quick demo ontology I thought I would share with you just to give a concrete example. I have three object properties: listensToBritney, listensToMahler, and listensToREM. I have 5 instances of the enumerated class Frequency: Never, Seldom, Sometimes, Often, Always. I put them in order using the properties isMoreFrequentThan and isLessFrequentThan. 

This is a nice little example of the power of OWL. Because the two properties are inverses and transitive, all I had to do was enter the order that Never isLessFrequentThan Seldom, Seldom, isLessFrequentThan Sometimes, etc. and everything else gets computed by the Reasoner. 

Then I included some SWRL rules to show how you could use this. E.g., if you had a system that was recommending music, there are rules like:

listensToMahler(?p, ?f) ^ isMoreFrequentThan(?f, Sometimes) -> suggestMusicBy(?p, Mahler)

I.e., if someone listens to Mahler more than Sometimes  then suggest  Mahler to them. Not exactly rocket science and if I was really doing it right I would make the listensTo property the equivalent of an n-ary relation by making a class that recorded the artist and frequency rather than having different properties for each artist but for the sake of demonstrating the Frequency enumerated class pattern I thought this was good enough. 

Michael

On Fri, Sep 20, 2019 at 1:04 AM Neha Sood <[hidden email]> wrote:
Thanks a lot for this suggestion!! i am working on this solution and i think, it will definitely suit ontology design.

Best Regards,
Neha


On Fri, Sep 20, 2019 at 12:28 AM Michael DeBellis <[hidden email]> wrote:
You can do it either way but IMO the best way to do it is to make visitFrequency an object property and to make it have a range which is an enumerated class. So you can define a class called Frequency and in the EquivalentTo field define that class with the expression {Rarely, Sometimes, Always}. Note: be sure to create Rarely, Sometimes, and Always as individuals that are instances of Frequency before you add that definition. Doing it this way eliminates some potential errors of mis-spelling a string and also give you completion when writing rules or DL statements by typing <cntl><space>.  

Another advantage is you can create an order for your frequencies if you want to. So you could have an object property with domain and range of Frequency called isMoreFrequentThan (with inverse isLessFrequentThan) and you could declare that Sometimes isMoreFrequentThan Rarely. You could also declare isMoreFrequentThan to be transitive so the reasoner would make inferences like: if Sometimes  isMoreFrequentThan Rarely and Always  isMoreFrequentThan Sometimes then Always  isMoreFrequentThan Rarely. 

Michael

On Thu, Sep 19, 2019 at 11:22 AM Neha Sood <[hidden email]> wrote:
Hi everyone,

I have a query regarding ontology design. How can i add frequency of certain event in an ontology. 

For instance, a person P visit place A rarely, place B usually,  Thus, different modifiers are required to draw the person  visiting habbit in an ontology. 
How should i represent frequency modifier in ontology as per your suggestion.
a) Whether i should add a class with individuals as rarely,sometime,always etc. modifiers,
or b)  as a data property with these modifier values as literals. In this case, i need , do i need to create separate frequency variable for each place.

Thanks a lot in advance!!
_______________________________________________
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
_______________________________________________
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