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

>-----Original Message-----
>From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org]
>On Behalf Of Ivan Herman
>Sent: Friday, January 16, 2009 10:31 AM
>To: Alan Ruttenberg
>Cc: Boris Motik; public-owl-wg@w3.org
>Subject: 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

Ah, well... :)

I can see from Boris' answer that he seems to be in favor of simply going on with the current situation (where only URIs are allowed to occur in annotation statements). So no change here, and therefore nothing that could have any effect on anything.

And Alan's primary suggestion seems to be to simply define names for class expressions by stating equivalence axioms. This also doesn't change anything, because that's possible with in the current situation, anyway. It's just a pragmatic approach.

Alan's additional idea with the bNode would be, from an OWL 2 Full perspective, also no big deal, because from 

  AnnotationAssertion(my:anProp my:entity)

follows

  AnnotationAssertion(my:anProp _:x)

under the OWL 2 Full semantics. And explicitly using bNodes instead of URIs cannot be disallowed in OWL Full, anyway.

So I cannot see any immediate dangers for OWL 2 Full arising from the (very conservative) suggestions that have been proposed so far.

But, perhaps, let me say a word about Alan's bNode proposal. I think that the pragmatic approach to introduce URIs by equivalent axioms is already sufficient. I don't see a need for changing the language. One can (outside the standard!) come up with naming schemes for this sort of approach, so the additional names won't annoy too much. Modeling tools can directly support this by allowing the author of an ontology to actually annotate class expressions (without explicitly adding an equivalence axiom), and behind the scenes a new name is created by the modeling tool for this. As long as you do not read the ontology source code, you won't be bothered by these technical names. (And if you do, the technical URIs probably aren't more bothersome than additional bNodes.)

So here are my 2 cents: I am in favor of keeping things as they are, and to point Alan Rector to the existing possibility to introduce names for class expressions. 

I know that it is, in general, nice to have "anonymous complex expressions" in languages, such as anonymous classes in Java or lambda expressions (unnamed function definitions) in functional languages. And as long as the introduction of such a feature to a language is largely for free, I'm fine with introducing it. But, apparently, the annotation of complex class expressions wouldn't be for free in OWL 2, but would lead to problems, as Boris pointed out. And since we have a perfectly working (and not too inconvenient, IMO) option, I see no reason why not to apply this option instead.

Michael

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

--
Dipl.-Inform. Michael Schneider
Research Scientist, Dept. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: schneid@fzi.de
WWW  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555

==============================================================================

FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. rer. nat. Dr. h.c. Wolffried Stucky, Prof. Dr. rer. nat. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus

==============================================================================