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

Alan,

just to understand: what would be the effect of all that in the RDF
mapping and, more importantly, the OWL Full semantics? It may not be
that easy to ignore the semantics consequences of such additional
goodies there (though I let Michael really comment on that...)

Ivan

Alan Ruttenberg wrote:
> 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
>>
>>
>>
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf