Re: Issue with RDF encoding of inverse property axioms/expressions

From: "Michael Schneider" <schneid@fzi.de>
Subject: Issue with RDF encoding of inverse property axioms/expressions
Date: Tue, 7 Apr 2009 16:25:23 +0200

> All!
> 
> While reviewing the RDF Mapping, I found the following issue, which I
> think is worth being presented in a separate mail. 
> 
> The basic observation is that "inverse property" expressions and
> axioms may have the same form in RDF. AFAICS, this may lead to a
> problem with the mapping. For example, consider (omitting
> declarations): 
> 
>   _:x owl:inverseOf :p .
>   _:x owl:inverseOf :q .
> 
> I would normally expect that this is a legal OWL 2 DL ontology (in RDF
> graph form). 

This is *not* an OWL 2 DL ontology in RDF graph form, because it is
missing typing for :p and :q.  The typing is needed to make the mapping
rules work.  I have an analysis of the fixed version below.

> The first problem is, however, what the corresponding FS
> ontology will be. Is it 
> 
>   InverseObjectProperties( ObjectInverseOf(:p) :q )
> 
> or
> 
>   InverseObjectProperties( ObjectInverseOf(:q) :p )  
> 
> ? Well, at least semantically, this would not be a problem, because
> both axioms have the same meaning. 
> 
> However, when looking at the mapping rules, it turns out that the RDF
> graph above does not even map. 
> 
> Table 11 about object property expressions defines:
> 
>   IF
>     _:x owl:inverseOf *:y .
>     { OPE(_:x) = ε and OPE(*:y) ≠ ε }
>   THEN
>     OPE(_:x) = ObjectInverseOf( OPE(*:y) )
> 
> And Table 16 on axiom parsing defines:
> 
>   IF
>     x owl:inverseOf y .
>     { OPE(x) ≠ ε and OPE(y) ≠ ε }  
>   THEN the following axiom is added to O_G
>     InverseObjectProperties( OPE(x) OPE(y) ) 
> 
> First, the canonicial parsing process uses Table 11 to construct the
> "OPE(.)" function. WLOG (for symmetric reasons), the first of the two
> triples in the graph is chosen. This leads to  
> 
>   OPE(_:x) = ObjectInverseOf( OPE(:p) )

This doesn't work because OPE(:p) is not acceptable to the side
conditions of the rule.

> Afterwards, the first triple is removed from the graph.
> 
> The second triple won't be chosen anymore, since now OPE(_:x) !=
> epsilon. Fine! 
> 
> Now, the canonical parsing process tries to use Table 16 to build an
> axiom. However, the remaining (2nd) triple cannot be mapped, since
> OPE(_:x) != epsilon. 

This is the wrong way around.  OPE(_:x) *is* acceptable, but OPE(:q) is
not.

> So this graph cannot be mapped. :(

But not for the reasons you state.

> How do we cope with this? IMO, the easiest way is to just leave things
> as they are: An RDF graph as the one above is not a valid OWL 2 DL
> ontology. I think, that's fine, because, AFAIU, it hasn't been a valid
> OWL 1 ontology, either. 
> 
> What do you think?
>  
> Michael 

Here is an analysis of the situation with the correct typing triples:

  :p rdf:type owl:ObjectProperty .
  :q rdf:type owl:ObjectProperty .
  _:x owl:inverseOf :p .
  _:x owl:inverseOf :q .

The patterns in Table 6 match on the rdf:type triples
and then OPE is initialized (Table 9) so that
  OPE(:p) = :p
  OPE(:q) = :q

Then the pattern in Table 11 matches (in exactly one of two ways)
resulting in, w.l.o.g.,
  OPE(_:x) = ObjectInverseOf(:p)

Then the pattern in Table 16 matches, generating the axiom
  InverseObjectProperties(ObjectInverseOf(:p) :q)

peter

Received on Tuesday, 7 April 2009 14:58:50 UTC