From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>

Date: Tue, 07 Apr 2009 11:00:42 -0400 (EDT)

Message-Id: <20090407.110042.171690282.pfps@research.bell-labs.com>

To: schneid@fzi.de

Cc: public-owl-wg@w3.org

Date: Tue, 07 Apr 2009 11:00:42 -0400 (EDT)

Message-Id: <20090407.110042.171690282.pfps@research.bell-labs.com>

To: schneid@fzi.de

Cc: public-owl-wg@w3.org

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) peterReceived on Tuesday, 7 April 2009 14:58:50 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 16:41:58 UTC
*