RE: Proposal to resolve ISSUE-86

Hello,

After some internal consultation with Peter, we came up with a refined version of the proposal for closing this issue. I'll explain
everything on an example.

Imagine you have the following FS ontology:

(1) SubClassOf(
      C
      ObjectSomeValuesFrom(
        InverseObjectProperty( P )
        D
      )
    )
(2) ObjectPropertyAssertion( InverseObjectProperty( P ) i1 i2 )

The current RDF serialization produces the following RDF triples:

(3)  <C, rdfs:subClassOf, _:x>
(4)  <_:x, rdf:type, owl:Restriction>
(5)  <_:x, owl:someValuesFrom, C>
(6)  <_:x, owl:someValuesFrom, _:y>
(7)  <_:y, owl:inverseObjectPropertyExpression, P>
(8)  <i1, _:y, i2>

The problem arises only because in (8) we have _:y in the predicate position. So let's just use a "pseudo-blank node": instead of
_:y, we should use some special name. I'll call this node $$pseudoblank$$P, but the name does not really matter: you just need to
ensure that it somehow (magically) uniquely depends on P. This name should live in the OWL namespace in order to avoid collisions
with regular names occurring in an ontology.


Thus, instead of (3)--(8), we would get the following triples:

(9)  <C, rdfs:subClassOf, _:x>
(10) <_:x, rdf:type, owl:Restriction>
(11) <_:x, owl:someValuesFrom, C>
(12) <_:x, owl:someValuesFrom, $$pseudoblank$$P>
(13) <$$pseudoblank$$P, owl:inverseObjectPropertyExpression, P>
(14) <i1, $$pseudoblank$$P, i2>

Our RDF graph is now fine: in (14) we now have a named node in the predicate position.



Thus, the RDF mapping would be simply changed as follows:

- InverseObjectProperties( p1 p2 ) would be mapped into <p1, owl:inverseOf, p2>. This is the mapping of the axiom.

- InverseObjectProperty( p ) would be mapped into <FRESH(p), owl:inverseObjectPropertyExpression, p>. This is the mapping of the
property expression.



Some of the existing proposals were similar; however, they also proposed to include the following triple in order to axiomatize
$$pseudoblank$$P and P as inverse of each other:

(15) <$$pseudoblank$$P, owl:inverseOf, P>

Note, however, that we do not really need this additional triple: on the OWL Full side, we can simply repeat the semantic conditions
of owl:inverseOf for owl:inverseObjectPropertyExpression. In other words, we just say that a triple of the form <x,
owl:inverseObjectPropertyExpression, y> places a constraint on an interpretation that IEXT(x) = Inverse(IEXT(y)).



Finally, note that we need both owl:inverseOf and owl:inverseObjectPropertyExpression. To understand why, consider the following
example ontology.

(16) InverseObjectProperties( InverseObjectProperty( P1 ) P2 )

The mapping should then produce the following RDF triples:

(17) <$$pseudo$$1, owl:inverseOf, P2>
(18) <$$pseudo$$1, owl:inverseObjectPropertyExpression, P1>

This is good so, because this allows us to properly deserialize the triples: we know that (17) is to be transformed into
InverseObjectProperties() (i.e., an axiom), and we also know that (18) is to be transformed into InverseObjectProperty() (i.e., a
property expression). Without an explicit distinction between owl:inverseOf and owl:inverseObjectPropertyExpression, we would not be
able to correctly reverse this mapping.



Please let me know how you feel about it.

Regards,

	Boris

Received on Wednesday, 26 March 2008 19:55:12 UTC