RE: Proposal to resolve ISSUE-81

Hi Alan!

Alan Ruttenberg wrote on Wednesday, March 26:

>Based on your comment and some other conversation, perhaps a better  
>choice is
>
>EquivalentClasses(ObjectIntersectionOf(ObjectOneOf(John)  
>ObjectHasValue(hasMother  Mary)) owl:Nothing )
>
>This has a better parallel for NegativeDataPropertyAssertion, in that  
>it can be valid OWL 1.0 DL. (no complement of oneOf(literal) 
>in OWL 1.0)
>
>-Alan

But now another more practical point comes to my mind.

Negative property assertions in OWL-1.1, although only being syntactic sugar, allow ontology authors to express in an explicit form that a certain assertion is *not* expected to hold. Further, it might well be that explicit negative assertions will have computational advantages, when it comes to check for consistency.

I also want these advantages in RDF, not only in functional syntax. And for the aspect of semantical and computational complexity: The way you suggest to encode negative assertions requires a pretty bit of OWL language features (equivalence, intersection, nominals, restrictions, and owl:Nothing). I believe a small rulebased sublanguage of OWL-Full will easily be out of play here.

However, having an explicit representation for negative assertions would be more of a lightweight feature: If the rule reasoner brings up the triple "s p o", it can immediately see that an inconsistency has occurred, if the negative assertion "NOT(s p o)" is directly represented in the ontology.

Best,
Michael

>On Mar 24, 2008, at 8:01 AM, Michael Schneider wrote:
>
>> Hi, Alan!
>>
>>> -----Original Message-----
>>> From: public-owl-wg-request@w3.org
>>> [mailto:public-owl-wg-request@w3.org] On Behalf Of Alan Ruttenberg
>>> Sent: Sunday, March 23, 2008 3:48 PM
>>> To: Web Ontology Language ((OWL)) Working Group WG
>>> Subject: Proposal to resolve ISSUE-81
>>>
>>>
>>> To resolve this issue I propose that NegativeObjectPropertyAssertion
>>> be transformed into the equivalent class assertion. In order to
>>> support tools that wish to preserve the presentation of 
>this axiom as
>>> NegativeObjectPropertyAssertion we use the axiom annotation 
>mechanism
>>> with a new annotation property: syntaxHint.  syntaxHint would be
>>> considered optional - not all tools need serialize using it, nor all
>>> tool pay attention to it.
>>>
>>> So
>>> NegativeObjectPropertyAssertion(hasMother John Mary)
>>>
>>> Is translated in to
>>>
>>> ClassAssertion(
>>>   Annotation(syntaxHint NegativeObjectPropertyAssertion)
>>>   John ObjectAllValuesFrom(hasMother ObjectComplementOf(ObjectOneOf
>>> (Mary))))
>>
>> I will only talk here about having this as an RDF syntax for  
>> negative property assertions. I won't talk about the functional  
>> syntax.
>>
>> I would not totally object to your proposal, but let me say that I  
>> have a personal preference for a more direct encoding.
>>
>> Aside from the round-tripping issue (ignoring your "syntaxHint"  
>> annotation for the moment :-)), I can also see a slight semantic  
>> issue with the above encoding, in particular for /data/ property  
>> assertions. I feel that the following idea might be worth to be  
>> considered: Statements of the form
>>
>>   NegativeDataPropertyAssertion(dp s o)
>>
>> should be allowed, where 'dp' denotes a data property, and 'o'  
>> denotes an individual(!) instead of a datavalue. The reason is that  
>> I just want to state that the triple "s p o" does *not* exist, and  
>> for an 'o', which does *not* denote a datavalue, this is, of  
>> course, always a true assertion.
>>
>> This is probably a controversial idea. Whatever one's opinion is  
>> here, the approach given by the above encoding will *not* support  
>> this idea:
>>
>>   * In Full, the object o will be coerced into a datavalue, which  
>> may lead to undesired semantical side effects in certain situations.
>>
>>   * In DL, if 'o' is an individual, then this will produce an  
>> error, AFAICS. [FIXME: There is no individual/datavalue punning in  
>> 1.1-DL, since URIs cannot denote datavalues?]
>>
>> These effects can at least be technically avoided with a direct  
>> encoding such as the current one based on reification. One can, of  
>> course, opt to introduce these effects explictly in such a direct  
>> encoding. Anyway, one has then the /option/ to do so. So what my  
>> idea at least shows is that the above encoding of negative property  
>> assertions carries perhaps a bit more information than necessary.
>>
>> But again, as for ISSUE-67, I prefer to avoid RDF reification  
>> (again for political reasons in the first place), and would instead  
>> opt to introduce a dedicated feature specific vocabulary:
>>
>>   _:x rdf:type owl11:NegativeObjectPropertyAssertion
>>   _:x owl11:propertyAssertionSubject s
>>   _:x owl11:propertyAssertionPredicate p
>>   _:x owl11:propertyAssertionObject o
>>
>> And analog for 'owl11:NegativeDataPropertyAssertion' (I won't argue  
>> about names, though).
>>
>>> -Alan
>>>
>>> meta: ISSUE-103
>>
>> Cheers,
>> Michael
>>

--
Dipl.-Inform. Michael Schneider
FZI Forschungszentrum Informatik Karlsruhe
Abtl. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: Michael.Schneider@fzi.de
Web  : 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
Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus