Imagine I have a property :loves that is not :Symmetric and I'm working in the following closed "space"

  :Naoko :loves :Sato .
  :Sato :loves :Naoko .
  :Ryooko :loves :Naoko .

I can the express this idea in a pidgin of first order logic

  AND(:A :loves :B,:B :loves :A) -> :A :mutuallyLoves :B

which infers the new facts

 :Naoko :mutallyLoves :Sato .
 :Sato :mutallyLoves :Naoko .

Can I define this :mutallyLoves property in OWL?

EDIT: I'd be interested in seeing ways to materialize or query :mutallyLoves using other tools, like SPARQL, RIF, SPIN, whatever...

asked 06 Nov '11, 14:11

database_animal's gravatar image

database_animal ♦
accept rate: 15%

edited 07 Nov '11, 12:10


I was thinking about property chains, but unfortunately loves o loves o loves is not what you need. If only we could define property intersections in OWL...

(07 Nov '11, 04:59) utapyngo utapyngo's gravatar image

Is that the answer, or at least the beginning of an answer? That this is a property intersection and property intersections cause OWL to implode?

I can use SPARQL to materialize :mutallyLoves, or I can rewrite a SPARQL query that has it as a property. I'd like to make this capability reusable for arbitrary predicate ?p and available for forward and backwards chain.

(07 Nov '11, 16:06) database_animal ♦ database_animal's gravatar image

Property intersection is not a language feature of OWL 2 and probably cannot be expressed in terms of existing language features, not even in OWL 2 Full:

Of course, it should be mentioned that your question is more specific than general intersection, as it essentially asks for the intersection of a property and its inverse. But I cannot tell, without deeper checking, whether this special case can still be expressed.

(08 Nov '11, 07:05) Michael Schn... ♦ Michael%20Schneider's gravatar image

I think to do this in SPIN, you need to create your own sub class of rdf:Property. For example, my:DerrivedProperty. And your own property to say what property it is derived from. For example, my:derrivedFrom. Then you would say the following:

:mutuallyLoves a my:DerrivedProperty
:mutuallyLoves my:derrivedFrom :loves

The following SPIN rule should create the inferences:

CONSTRUCT {?s ?pd ?o}
WHERE {?pd my:derrivedFrom ?p.
?s ?p ?o.
?o ?p ?s.}

You can also throw in

?pd a my:DerrivedProperty.

This rule will work collaboratively with SPIN OWL RL rules for symmetricity

permanent link

answered 07 Nov '11, 17:48

irene_polikoff's gravatar image

accept rate: 21%

We can extend Signified's partial solution that uses a class :MutuallyLoved into a full solution for the property :mutuallyLoves, if we make two additional assumptions.

Firstly, and that's probably easy to accept, we state that if A mutually loves B, then A also (ordinarily) loves B:

(1) :mutuallyLoves rdfs:subPropertyOf :loves .

Secondly, we only consider /true/ love, and, as we all know, true love can only be given to a /single/ person (at most):

(2) :loves rdf:type owl:FunctionalProperty .

Next, we "translate" the class of people who are mutually loved into the class of people who are mutually loving /someone/:

(3) :MutuallyLoved owl:equivalentClass [
      rdf:type owl:Restriction ;
      owl:onProperty :mutuallyLoves ;
      owl:minCardinality "1"^^xsd:nonNegativeInteger ] .

Now let's probe :Naoko's and :Sato's love! As :Naoko is a member of class :MutuallyLoved, there must be, via axiom (3), some Mr. X whom she :mutuallyLoves. Now, as we know from (1), to :mutuallyLoves people means to :loves them, so we know that :Naoko :loves Mr. X. And as :loves has been determined to be a functional relationship by (2), it turn's out from the premise that ":Naoko :loves :Sato" that Mr. X is, in fact, :Sato himself! Hence, there is no more reason to disbelieve in :Naoko's and :Sato's true love for each other:

:Naoko :mutuallyLoves :Sato .

Lovely story, isn't it! But what about reasoning?

The result is clearly too hard for the OWL 2 RL/RDF rules, with all the property restrictions and existential semantics being involved. I have checked with Ivan Herman's online RL reasoner, with all additional features turned on, and got a negative result.

The solution /is/ in the scope of the OWL 2 Direct Semantics when applied to the /unrestricted/ OWL 2 Structural Specification, but is unfortunately beyond OWL 2 DL, since already Signified's example is in conflict with one of the global restrictions of OWL 2 DL ("You shall not apply self-restrictions on properties defined by property chain axioms!"), and my three additional axioms above make the situation even worse. HermiT 1.3.2 does not confirm the entailment (wrongly claims non-entailment). Pellet 2.3.0 claims entailment, but only after several suspicious warnings that it will ignore diverse axioms while doing reasoning and that the conclusion ontology is empty, which is clearly not the case, so it seemed to be confused and only accidentally correct. Therefore, it turns out that using an OWL 2 DL reasoner is not a reliant method. The tests were made with this cleaned-up version of the whole example in RDF/XML:

However, the solution is, formally, in OWL 2 Full. I have checked it with our "naive" approach to OWL 2 Full reasoning presented in and it worked! I'm afraid, I still haven't a handy reasoner tool for people to easily play with themselves, but whoever is interested can copy and paste the TPTP code at

into any first-order theorem prover (see the link in the file there for FOL reasoners). That's a translation of the example here. The remaining stuff in the file is a sufficient selection of OWL 2 Full semantic conditions to make the example produce the result (the full set of semantic conditions would be a little too much and would be inefficient). Happy OWL 2 Full reasoning! :-)

permanent link

answered 10 Nov '11, 20:13

Michael%20Schneider's gravatar image

Michael Schn... ♦
accept rate: 34%

edited 11 Nov '11, 02:16


I think {:mutuallyLoves rdfs:subClassOf :loves .} is a typo, intended to be {:mutuallyLoves rdfs:subPropertyOf :loves .} Overall, an interesting solution, but assumption (2) and lack of tooling significantly limits its usefulness.

(10 Nov '11, 23:50) irene_polikoff irene_polikoff's gravatar image

@irene_polikoff: Thanks, fixed it. It was only a typo in the text, the cited code was fine.

Assumption (2) is, of course, the relevant bit to make the story work. There may be other scenarios in which functionality of the basic property from which a mutual relation is to be derived is more justified, and in such scenarios the pattern will be useful. We don't simply dismiss a new design pattern just because we don't like the example given for it, right?

Concerning lack of tooling: If there is no proper tool to deal with a given problem, the best thing to do is to develop such a tool. :-)

(11 Nov '11, 02:33) Michael Schn... ♦ Michael%20Schneider's gravatar image

+1, I like the approach, and assumption (2) might hold for some cases.

(11 Nov '11, 09:08) Signified ♦ Signified's gravatar image

This is conceptually the same problem as discussed here (aka. property intersection, role conjunction, etc.). The conclusion there is that it's not possible in OWL 2 DL, and probably not possible in OWL 2 Full.

However, you can use :hasSelf to model the class MutuallyLoved.

:lovedBy owl:inverseOf :love .
:lovesLovedBy owl:propertyChainAxiom ( :loves :lovedBy ) .
:MutuallyLoved owl:equivalentClass [ owl:hasSelf true ; owl:onProperty :lovesLovedBy . ]

From this, you can see that :Sato and :Naoko are members of :MutuallyLoved...

...but (as far as we can tell), you cannot resolve the cyclical relationship between them using OWL 2. In summary, you can detect cyclical property paths in OWL 2, but you can (probably) only infer class memberships from such detections, not binary relations.

EDIT: just saw the comments on the answer. Doh! ...anyways, there's a little bit more detail here.

permanent link

answered 10 Nov '11, 12:52

Signified's gravatar image

Signified ♦
accept rate: 37%

edited 10 Nov '11, 12:53

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 06 Nov '11, 14:11

question was seen: 1,991 times

last updated: 11 Nov '11, 09:08