W3C home > Mailing lists > Public > public-owl-wg@w3.org > January 2009

Re: An explanation of the technical difficulties surrounding Alan Rector's comment

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Thu, 15 Jan 2009 11:30:13 -0500
Message-ID: <29af5e2d0901150830y5b55ab95wb19c5bb48cba71b6@mail.gmail.com>
To: "Boris Motik" <boris.motik@comlab.ox.ac.uk>
Cc: public-owl-wg@w3.org

Hi Boris,

What about something that is along the lines of Ian's suggestion -
that the desired class be named and then the name used in the
annotation. The problem with this is the clutter of such classes.

Suppose for a moment we allowed a class name to be a blank node. Then
that blank node could be the target of the annotation. Along the lines
of EquivalentClasses:

EquivalentClasses( CE | nodeID, CE1 ... CEn )

Add a global restriction that nodeID can only appear in the position
of annotationValue.

Then we could have

SubClassOf(Annotation(a:shouldBe :foodreally) a:Food a:HeatedAnimal)
EquivalentClasses( :foodreally, IntersectionOf(a:HeatedAnimal
a:NotPoisonousAnimal))

Not that we would like to write that - but if that can be
serialized/parsed, then its a small step to allowing

SubClassOf(Annotation(a:shouldBe IntersectionOf(a:HeatedAnimal
a:NotPoisonousAnimal)) a:Food a:HeatedAnimal)

as syntactic sugar for the above, with the change:

AnnotationValue := AnonymousIndividual | IRI | Literal | ClassExpression

--Alan


On Wed, Jan 14, 2009 at 1:52 PM, Boris Motik
<boris.motik@comlab.ox.ac.uk> wrote:
>
> Hello,
>
> Here is a short description of why allowing complex classes in annotations is difficult.
>
>
> AnnotationAssertion in the structural specification currently takes an annotation property and a URI. Now if we wanted to allow for
> complex classes in annotation assertions, we'd need to change the structural specification such that we have several different
> versions of annotation assertions. In particular, we'd need AnnonationAssertionByEntityOtherThanClass,
> AnnotationAnnotationByAnonymousIndividual, and AnnotationAnnotationByClassExpression (I've used these long names not for irony
> purposes but make 100% clear what we'd need).
>
> But we already had a subset of that: at one point, we had annotations with entity values. This was rather unlucky, because it was
> not possible to roundtrip annotations to and from RDF correctly. Note that this does not depend on simple vs. complex classes in
> annotations: the problem is actually causes if we allowed entities as annotation values rather than URIs. Consider the following RDF
> graph:
>
> (1) x my:annProp y
>
> What is y now? If could be used in an ontology both as a class and as an individual, so we don't know what the actual value of the
> annotation was. Note that declarations do not help us distinguish the proper role of y: the ontology might actually explicitly
> declare y to be both a class and an individual. This problem was solved by allowing only URIs in annotations: this now makes parsing
> (1) unambiguous.
>
> Thus, the problem is not so much about allowing for complex classes in annotations; rather, the problem is with distinguishing
> entities vs. URIs. The addition of complex classes would require us that we make this distinction, which would have bad consequences
> regarding RDF mapping. In fact, the addition of annotations with complex classes would make this problem even worse. Consider the
> following RDF graph:
>
> (2) x my:annProp _:z
>
> It is impossible to know here what the role of _:z is: is it an anonymous individual that should be expanded to a class, or is it
> really meant to be treated as an anonymous individual? In other words, there is no way for an RDF parser to know whether to
> translate this triple into AnnotationAnnotationByClassExpression or AnnotationAnnotationByAnonymousIndividual.
>
> Regards,
>
>        Boris
>
>
>
Received on Thursday, 15 January 2009 16:32:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 15 January 2009 16:32:30 GMT