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

On Wed, Oct 8, 2008 at 6:03 AM, Boris Motik <boris.motik@comlab.ox.ac.uk> wrote:
>
> 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.

The only remaining pun I am concerned about is the one between
ontology and individual. We have this undesirable situation (in my
opinion) where if we write
Imports(a:foo a:foov1)
then a:foo and a:foov1 are not part of the domain. But if we then
write elsewhere
Annotation(owl:backwardCompatibleWith a:foov2) then a:foov2 is part of
the domain.
It seems to me that either ontologies should all be or not all be part
of the domain.
Moreover, if a:foov2 *is* an individual here, and if a:foov2 is in the
imports closure, then the owl:backwardCompatibleWith is not referring
to the a:foov2 ontology but to some unrelated punned entity.
No problem perhaps with owl:backwardCompatibleWith, but it is a
problem for owl:incompatibleWith

Moreover maintaining these two entities distinct in OWL RL would seem
to be problematic.

>
>
> 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.

So far so good. Some questions:

What sort of thing is a:Eagle and how is it (formally - say in the
metamodel) related to entities in OWL? Can I have an annotations where
a:Eagle is not the same URI as some entity in the ontology? Should a
tool display annotations stated in such an axiom with any entity in
the ontology that has the same URI?

How do annotations on Axioms work?

What about the RHS of an annotation? If i have (annotation by entity)

Annotation( a:Eagle a:image(i:eaglePicture))
ObjectProperty(i:eaglePicture)
NamedIndividual(i:eaglePicture)
What does the annotation refer to? Does it matter? What is our advice
to tool writers on how to present this?

>
> 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.

Much?


> Please let me know how you feel about this.
>
>
> Regards,
>
>        Boris

Received on Wednesday, 15 October 2008 16:58:52 UTC