1

Currently I'm developing an ontology to represent preferences that a specific user may have about something. For example, the user may have an MediaVolumeLevel preference set to VolumeLevel_3.

The different levels (individuals of the class MediaVolumeLevel) are: VolumeLevel_1, VolumeLevel_2, VolumeLevel_3 and VolumeLevel_4.

The user and the Preference are linked by the objectProperty hasMediaVolumeLevelPreference.

The objectProperty assertion need to be inferred from other User aspects through SWRL rules. For example, if the user has a hearing difficulty, the MediaVolumeLevel needs to be set to VolumeLevel_4. So:

User(?u), hasDifficulty(?u,Hearing) -> hasMediaVolumeLevelPreference(?u,VolumeLevel_4)

This is working fine. But, since I have other SWRL rules that also infer the MediaVolumeLevel for the same users, such as:

User(?u), hasContext(?u,NoisyRoom) -> hasMediaVolumeLevelPreference(?u, VolumeLevel_3)

and SWRL supports monotonic inference only, the reasoner will assert both VolumeLevels (VolumeLevel_4 and VolumeLevel_3).

What I need is a rule that, somehow, will only assert the preference if there's no higher level already asserted. In the given example, even if hasContext(?u,NoisyRoom) is true, the only asserted level should be VolumeLevel_4 because other rule asserted it.

Any advices on this? Is what I want possible using SWRL? I'm using Protege 4.3 and Pellet Reasoner

Thanks, MFV.

Maurício Fontana de Vargas
  • 81
  • 1
  • 3

1 Answers1

3

this is possible but only in certain cases. Allow me to explain.


1) Your hasMediaVolumeLevelPreference is an object property that relates to individualsVolumeLevel_1, VolumeLevel_2, VolumeLevel_3 and VolumeLevel_4. These individuals have no relative ordering in the ontology. You, as a human designer, are aware that VolumeLevel_4 is greater than VolumeLevel_3 but to a reasoner no such relative ordering exists. If you were to change hasMediaVolumeLevelPreference to a data property with a range of int (or long or whatever really) then you have provided a concrete data value behind your individuals. Thus you can write rules using swrl comparison builtins, i.e swrl:greaterThan etc.

2) You can now write clauses into your rules that make comparisons in the antecedent so that only the highest value gets asserted, however SWRL supports monotonic inference only. Hence, SWRL rules cannot be used to modify existing information in an ontology. SWRL rules can not retract or remove information from an ontology. Therefore in the case where a lower volume, Volume_3 gets asserted before Volume_4, you cannot remove the relation hasMediaVolumeLevelPreference(Volume_3) from your ontology.

3) All is not lost yet though, Apache Jena has a rule engine that can be used to manipulate the ontology at an rdf triple level. You may have to write your own built-ins but you can remove properties and class descriptions from rdf subgraphs. Go here for more info on Jena rules.

I hope this helps.

Kunal Khaladkar
  • 493
  • 3
  • 16
  • Just a note, Jena rules cannot be placed directly in the ontology via xml syntax and have to be loaded from an external .txt file and fed to the Jena rules reasoner. – Kunal Khaladkar Aug 29 '15 at 06:29
  • First of all, thanks for your answer @kunal-khaladkar 1) Ok, but what if no VolumeLevel has been already asserted? The rule: `User(?u), hasDifficulty(?u,Hearing), hasMediaVolumeLevelPreference(?vl), lessThan(?vl,4) -> hasMediaVolumeLevelPreference(?u,VolumeLevel_4)` won't work because `hasMediaVolumeLevelPreference(?vl)` is not true. Is there any workaround to solve this or am I getting it wrong? 3) I've read the link about Jena and it seems very interesting. Unfortunately, I've already wrote my sotware using OWL api and start coding again from scratch will take me too long – Maurício Fontana de Vargas Sep 01 '15 at 14:34
  • For 1) you are correct, that rule will not fire if `hasMediaVolumeLevelPreference` is not asserted on an individual. As for a workaround, I can't really think of how that would actually look and behave. However, since you are using owl api, it may be better for you to allow multiple assertions of the `hasMediaVolumeLevelPreference` property and handle retrieving the "largest" one through your code. I'll continue to think on this problem though and let you know if I can come up with something. – Kunal Khaladkar Sep 01 '15 at 17:00
  • That's exactly how I'm doing right now, but in my opinion it's a ugly solution. Having something in the ontology itself would be a much better approach. Thanks for your attention so far! – Maurício Fontana de Vargas Sep 01 '15 at 20:09