OWL 2 RL Property chains in SPIN

144 views
Skip to first unread message

Gerrit

unread,
Aug 25, 2011, 9:28:16 AM8/25/11
to TopBraid Suite Users
Looking at the definition of OWL 2 property chains in owlrl.spin.rdf:

# prp-spo2-2
CONSTRUCT {
?u1 ?p ?u3 .
}
WHERE {
?p owl:propertyChainAxiom ?x .
?x list:length 2 .
?x list:index ( 0 ?p1 ) .
?x list:index ( 1 ?p2 ) .
?u1 ?p1 ?u2 .
?u2 ?p2 ?u3 .
}

it seems that any property chain axiom containing more than two
properties is not supported. Am I reading this correctly and if so,
are there plans to extend it in future?

Regards,
Gerrit

Scott Henninger

unread,
Aug 25, 2011, 10:31:16 AM8/25/11
to TopBraid Suite Users
Gerrit; this is a known limitation for the current set of OWL 2 RL
profile rules, and we plan to fix for 3.6.

In the meanwhile, I'd suggest you take a look at the much more
expressive SPARQL property paths. Let's take a great grandfather
example where you may express this using property chain axioms as:

ex:hasGreatGrandFather
owl:propertyChainAxiom
(ex:parent ex:parent ex:father) .

Using SPARQL property paths you need to specify precisely the same
information needed in a property chain axiom:

CONSTRUCT {?me :hasGreatGrandFather ?ggfather}
{ ?me ex:parent/ex:parent/ex:father ?ggfather .
}

Property chain axioms stops there, but you can go much further with
SPARQL. For example, suppose you're trying to link some other
resource to ancestors - like citizenship - and this is modeled in a
couple of ways - :citizenship or :legalCountry. You can specify the
following:

CONSTRUCT {?me :ancestorCitizenship ?ggparentCitizenship}
{ ?me ex:parent/ex:parent/ex:parent/( ex:citizenship |
ex:legalCountry) ?ggparentCitizenship .
}

This is a very common modeling pattern, particularly when merging data
from multiple sources, and it just can't be expressed conveniently in
OWL.

The expressiveness of property paths is much richer that these simple
examples - see http://www.w3.org/TR/sparql11-property-paths/. It
provides for inverse links, transitivity, alternative paths and
multiple paths in addition to the harcoded path sequence in property
chains. In fact the above can be expressed as:
?me ex:parent{3}/(ex:citizenship | ex:legalCountry) ?
ggparentCitizenship .

...and you could get the citizenship for all grandparent and
greatgrandparents with:
?me :parent{2,3}/(ex:citizenship | ex:legalCountry) ?
ggparentCitizenship .

So there's quite a bit more you can specify with property paths, with
the tradeoff that the expressions are in rules rather than the data,
which is sometimes an advantage.

-- Scott

Gerrit

unread,
Aug 25, 2011, 10:47:12 AM8/25/11
to TopBraid Suite Users
Thanks Scott. I haven't really looked at SPARQL property paths until
now, and your examples and explanation make it a lot easier to
understand. Property paths seems to solve most of the problems I've
had with property chain axioms in the past.

On Aug 25, 4:31 pm, Scott Henninger <shennin...@topquadrant.com>
wrote:
> Gerrit; this is a known limitation for the current set of OWL 2 RL
> profile rules, and we plan to fix for 3.6.
>
> In the meanwhile, I'd suggest you take a look at the much more
> expressive SPARQL property paths.  Let's take a great grandfather
> example where you may express this using property chain axioms as:
>
> ex:hasGreatGrandFather
>       owl:propertyChainAxiom
>               (ex:parent ex:parent ex:father) .
>
> Using SPARQL property paths you need to specify precisely the same
> information needed in a property chain axiom:
>
> CONSTRUCT {?me :hasGreatGrandFather ?ggfather}
> {  ?me ex:parent/ex:parent/ex:father ?ggfather .
>
> }
>
> Property chain axioms stops there, but you can go much further with
> SPARQL.  For example, suppose you're trying to link some other
> resource to ancestors - like citizenship - and this is modeled in a
> couple of ways - :citizenship or :legalCountry.  You can specify the
> following:
>
> CONSTRUCT {?me :ancestorCitizenship ?ggparentCitizenship}
> {  ?me ex:parent/ex:parent/ex:parent/( ex:citizenship |
> ex:legalCountry) ?ggparentCitizenship .
>
> }
>
> This is a very common modeling pattern, particularly when merging data
> from multiple sources, and it just can't be expressed conveniently in
> OWL.
>
> The expressiveness of property paths is much richer that these simple
> examples - seehttp://www.w3.org/TR/sparql11-property-paths/.  It
Reply all
Reply to author
Forward
0 new messages