A proposal for resolving the punning issue (ISSUE-114) + a related proposal for a tweak to the annotation system

Hello,

Here is a proposal for resolving the punning issue (ISSUE-114); this resolution includes a related tweak to the annotation system.


After the recent discussions in the WG, I think I understand where the objections to punning come from. Let me explain this on an
example of the following ontology:

(1) ClassAssertion( a:Eagle   a:Harry )
(2) ClassAssertion( a:Species a: Eagle )

Here, the URI a:Eagle has been overloaded (or subjected to punning): in (1), it is used as a class and in (2) it is used as an
individual. The confusion surrounding punning seems to have been caused by an impression that under punning individual a:Eagle is
something different than the class a:Eagle. This is *not* the case with punning: the individual a:Eagle and the class a:Eagle are in
fact two  *views* of the one and the same URI a:Eagle.

These two views are necessary in order to obtain a standard first-order semantics. It does not change the fact that, from a user's
point of view, there is only one thing that the URI a:Eagle stands for.  The idea behind punning is that the two views do not
semantically interact with each other (as opposed to the RDF situation where the views do semantically interact).

In order to make this clear in the Syntax document, I propose to introduce a new subsection in Section 5 in which we'd explain these
things. I would add several examples by means of which I'd explain how punning is intended to be used. There would not, however, be
any additional forbidden overloadings -- the only ones forbidden would be datatype vs class and object vs data vs annotation
property.


Having said that, as Alan has pointed out in a recent email, the annotation subsystem does not completely follow this idea.
Currently, it is possible to attach *different annotations* to the individual a:Eagle and to the class a:Eagle, like this:

(3) EntityAnnotation( Class( a:Eagle ) Label( "xxx" ) )
(4) EntityAnnotation( NamedIndividual( a:Eagle ) Label( "yyy") )

Now, the class a:Eagle has the label "xxx", but the individual a:Eagle has the label "yyy"; this is clearly not consistent with
punning providing different views of the same URI. This also causes problems with the RDF mapping. The transformation of (3)--(4)
into RDF produces the following triples:

(5) < a:Eagle , rdf:type, owl:Class >
(6) < a:Eagle , rdfs:Label , "xxx" >
(7) < a:Eagle , rdfs:Label , "yyy" >

In this transformation, the fact that "xxx" and "yyy" have been associated with the class and the individual view, respectively, has
been lost. Thus, the reverse mapping currently produces the following axiom:

(8) EntityAnnotation( Class( a:Eagle ) Label( "xxx" ) Label( "yyy" ) )


In order to correct this, I propose to change the annotation system and assign annotations simply to URIs; similarly, the values of
annotations could be literals or URIs, rather than entities. Thus, axioms (3) and (4) under the new regime would be written like
this:

(9)  EntityAnnotation( a:Eagle Label( "xxx" ) )
(10) EntityAnnotation( a:Eagle Label( "yyy" ) )

This has a number of benefits. First, it is consistent with the view that the individual and the class a:Eagle are not different
things. Second, it solves some problems with the RDF mapping and, in  
fact, brings OWL 2 DL closer to OWL 2 Full. The RDF mapping would then produce only triples (6) and (7), and the reverse
transformation would produce the following axiom:

(11) EntityAnnotation( a:Eagle Label( "xxx" ) Label( "yyy" ) )

The fact that the original ontology consisted of two axioms is lost; however, the result of the reverse transformation correctly
attaches both annotations to the URI a:Eagle.


The impact on the documents would be minimal. There is no impact on OWL Full, and there would be rather trivial changes to the
Syntax and the RDF Mapping documents. The RDF Mapping document would actually become much simpler.


Please let me know how you feel about this.


Regards,

	Boris

Received on Wednesday, 8 October 2008 10:04:29 UTC