RE: [OWLWG-COMMENT] Punning and the "properties for classes" use case

[Reclaimed from PUBLIC-OWL-WG. :)]

Hi, Alan!

Alan Ruttenberg wrote on November 01, 2007
in http://lists.w3.org/Archives/Public/public-owl-wg/2007Nov/0007.html

>Ah well, since I am cited I will reply :)
>
>(I guess I should say "chair hat off")
>
>To summarize, I think that Michael accurately calculates the  
>entailments, that these are no new surprise, and that they are a  
>necessary consequence of exactly the articulated trade off. In  
>summary, I don't see anything new in this analysis.
>
>That the current proposal does not satisfy all use cases is not  
>surprising. The alternative (no alternative provided) provides fewer.  
>I'd urge that in order to move the conversation forward, that some  
>concrete alternative proposals be put forward - these proposals  
>should at least offer increased functionality in the direction  
>desired, should not require new research, as that would be outside  
>the mandate of the charter, and provide for sound, complete, and  
>decidable reasoning, to provide for the user community that depends  
>on these aspects of OWL DL.
>
>For my part I will offer that it is my understanding that OWL 1.1(DL)  
>does not invalidate the semantic of OWL Full, and should not impact  
>those users who currently use OWL Full reasoners.

I will come to this point below.

>More comments in line:
>>> My understanding is that there is a requirement to be able to  
>>> create  properties attached to classes that have more inference  
>>> support than  is currently possible using annotation properties.  
>>> For example, it is  desirable that an "annotation property" for an  
>>> editing time stamp  should have a range that is xsd:date, or, for  
>>> SKOS, we would like  to  be create subproperties of rdfs:label.
>>
>> I agree that this would be a very valuable feature. But I don't  
>> believe that this feature is really provided by punning.
>
>Good that you agree on the feature. Disagree on the conclusion. The  
>feature is supported, but subject to limitations.
>
>>> Alan Rector articulated these cases initially, IIRC. I suspect  
>>> they  are recorded somewhere amongst  the OWLED stuff.
>>>
>>> I believe that you have correctly identified the missing  
>>> entailments.  Those entailments, while desirable in general, are  
>>> not necessary for  the above use case.
>>
>> I think that this argumentation might be somewhat shortsighted.  
>> Let's regard for example the following situation:
>>
>>   (1) <c1> a owl:Class .
>>   (2) <p> a owl:ObjectProperty .
>>   (3) <c1> <p> <x> .
>>
>> While OWL-1.0-DL will not allow this combination of axioms, it  
>> actually is allowed with punning. So it looks like as if I really  
>> have achieved to add an objectproperty to some class.
>>
>> Now, it will probably be quite common in the SemWeb to make further
>> assertions about a class by using a /different/ name for it, and  
>> OWL with punning allowes us to do so by stating an additional  
>> renaming axiom like:
>>
>>   (4) <c2> owl:sameAs <c1> .
>
>It may be common, but it would be documented that the case of using  
>owl:sameAs between classes to infer owl:equivalentClasses is exactly  
>the limitation of OWL 1.1 (DL). Ditto inferred sameAs via "smushing"  
>using IFPs. Ditto all other cases. If it were me I would include a  
>section in the user documentation that explains all the cases where  
>one should not have the expectation of entailment.
>
>That said, we would have exactly the case in many other  
>specifications. People's expectations do not match what the  
>specification says.
>
>> Having axioms (1) to (4), a punning enabled reasoner will be able  
>> to infer the following new statement:
>>
>>   (5) <c2> <p> <x> .
>>
>> So up to now, everything looks fine with regards to the "properties  
>> for classes" use case.
>
>Except that the use case that I am familiar for "properties for  
>classes" does not get substantial additional benefit from the use of  
>sameAs in this case. Perhaps this is someone else's use case. It  
>isn't the one I cited.
>
>As an example of what the use case does support, suppose we have
>
>(a) <q> a owl:Class
>(b) <r> a owl:Class
>(c) <q> disjointFrom <r>
>(d) <p> range <q>
>
>then
>
>(e*) <x> a <r> (inconsistent) (since (3,d) ==> <x> a <q>, and q and r  
>are disjoint)
>
>> But it doesn't might look so fine anymore, if we have additional  
>> axioms on class <c1>. Say, we have the assertion:
>>
>>   (6) <i> a <c1> .
>>
>> and I want to make <c1> into a sub class of another class <d>, but  
>> now by using its alleged synonym "<c2>":
>>
>>   (7) <c2> rdfs:subClassOf <d> .
>>
>> then I would expect that the following statement can also be 
>inferred:
>>
>>   (8) <i> a <d> .
>>
>> But as far as /I/ understand punning, (8) won't be entailable,  
>> because the URI called "<c1>" denotes a class in (1), while it  
>> denotes an individual in (3). In effect, I did not, as intended,  
>> assign property <p> to the class ressource denoted by the name  
>> "<c1>", but instead, this property has been assigned to some  
>> possibly completely different individual resource, which just  
>> happens to have the same name. And there has to be no semantical  
>> relationship between these two resources, so these two resources  
>> don't have to coincide, see section 3.3 of [1].
>
>Your analysis is correct. However the intention is not that there is  
>no "semantical relationship"  between them. In discussion on this  
>topic it has been proposed that we make it clear that these are  
>intended to be the same entity, 

Ok, this is actually news to me. To cite from section 3.3 of [1]:

  "In punning, names can be used for several purposes; 
  for example, Person can at the same time be the name 
  of a class and the name of an individual. 
  The different uses of a name are, however, 
  completely independent, and from a semantic point
  of view they can be thought of as separate names, 
  e.g., Person-the-Class and Person-the-Individual."

This statement appears to me to be in direct contrast to yours above. But I
acknowledge that the cited document is already pretty old, and it is
therefore quite possible that the punning approach has changed significantly
in the meanwhile. It was one of the aims of my original mail to receive more
current information about punning. Of course, such information should be in
some document form, to be usable as a foundation for OWL-1.1, and for
everyone else to evaluate.

>that OWL 1.1 make a sacrifice of  
>completeness for progress,  that usage that exploits the fact that  
>one can "trick out" the language to this end will not be supported in  
>the future.
>
>> I can at least see in the semantics draft [2] that in OWL-1.1 there  
>> will be no strict separation of the different parts of the OWL  
>> universe (individuals, classes, etc.) anymore, as it has been  
>> originally demanded for OWL-1.0-DL. But this makes it only / 
>> possible/ for an individual and a class to be the same.
>(and a property)
>> As long as I do not have any means in OWL-1.1-DL to also /enforce/  
>> these two resources to be the same, this relaxation seems to be  
>> useless to me with respect to punning.
>
>To you. But not to others. It is key to remember here that we have a  
>diverse set of users and that we are trying to bring value to as many  
>of them as possible.
>
>> (BTW: I am not certain whether this relaxation is a good idea, but  
>> this is another topic.)
>>
>> Punning, as I understand it from [1], is just a means for  
>> "overloading"
>> names for resources from different parts of the OWL universe.
>
>This is a misunderstanding. It is a compromise to bring additional  
>requested functionality into the language. It has, as part of the  
>compromise, the effect of appearing to overload names. That is not  
>its intention.
>
>> Without punning, I would have to write axioms (1) and (3) above in  
>> a form like
>>
>>   (1') <c1_class> a owl:Class .
>>   (3') <c1_indiv> a owl:Thing .
>>
>> In OWL-DL plus punning, the reasoner will have to do such URI  
>> renamings
>> itself in a pre-processing step before it can start its reasoning  
>> tasks.
>> This seems necessary, otherwise the reasoner might produce wrong  
>> entailments.
>>
>>> As I understand it, the reason those entailments  are not  
>>> supported is that there is not enough theoretical work to  ensure  
>>> that they can be implemented in a sound, complete, and  decidable  
>>> manner.
>>>
>>> Proponents of punning would label this:
>>>
>>> "OWL DL, now with more, but not all, of OWL Full goodness"
>>
>> As I understand it, punning has nothing to do with OWL Full  
>> semantics, and then it would not provide any kind of "OWL Full  
>> goodness".
>
>This would be an opinion. In my opinion it brings us closer to such  
>goodness, while dodging some (opined) badness, like the fact that  
>there are no effective sound and complete reasoners for the language.
>
>> I rather believe that the proponents of punning think that  
>> overloading URIs in OWL might be useful, or at least convenient, in  
>> certain cases. I could imagine that the argumentation might go this  
>> way:
>>
>>   "In OWL-1.0-DL, one workaround to assign properties
>>   to a class C is to dedicate some individual iC, which
>>   receives the property as a proxy for C. So why not just
>>   give this proxy individual the same name as the class
>>   to make the intended connection between them both more
>>   explicit?"
>
>In OWL 1.0 this would be a workaround. In OWL 1.1 we can see this as  
>a step closer to where we want to be. The intention that name  
>indicate both is made clearer, entailments that we know can be made  
>with current reasoners are codified, and a direction is set for  
>future development.
>
>> But I find it pretty confusing to overload URIs, to say the least.  
>> As my example above demonstrates, it is very easy to draw wrong  
>> conclusions about the semantics of an ontology when using URI  
>> overloading (confusing for a human, who constructs and/or reads  
>> ontologies; not confusing for a machine, of course).
>
>It is easy to draw wrong conclusions in many cases. We rely on  
>reference back to specifications to ensure that our expectations  
>match what is offered.
>
>> So I consider punning, while perhaps a "nice-to-have" feature, to  
>> be a very dangerous feature in practice, and I will prefer to  
>> follow the saver principle: "One URI, one resource".
>
>I respect your preference, but disagree that so called  
>"punning" (time to find a more accurate name) is at opposition with  
>the principle "One URI, one resource".

Again from section 3.3 of [1]:

  "However, punning is not compatible with the meta-modelling 
  possibilites inherent in the semantics of RDF [6] 
  (and thus inherent in OWL Full), precisely because it makes 
  the two uses of a name semantically independent."

And probably again outdated...(?)

>Hope this helps you understand the motivations involved. Please do  
>consider proposing an alternative within the constraints proposed  
>earlier, or contributing theoretical work that could augment current  
>reasoners so that they *can* support the entailments you desire.

These are pretty high demands on a public comment! :)

Well, perhaps I can at least dare to try out a few theoretical
considerations here.

<WARNING>
  Below I try to apply both Punning and OWL-Full semantics in combination, 
  but I am not accustomed to do so. So please double check my
  argumentation, it might well be that it contains significant errors.
  (If so, then this will be another good example for how confusing 
  punning actually is. ;-))
</WARNING>

I recall the following two statements you did in your answer above:

(1) [from the beginning of the mail]
    "For my part I will offer that it is my understanding 
    that OWL 1.1(DL) does not invalidate the semantic of OWL Full"

(2) [same name for individuals and classes]
    "the intention is not that there is no "semantical relationship"
    between them. In discussion on this topic it has been proposed 
    that we make it clear that these are intended to be the same entity"

So by this you seem to put the following two requirements on punning:

(A) it is compatible with OWL-Full semantics

(B) it is /always/ ensured that if an individual resource 
    has the same name as a class resource, 
    then these two resources are equal.

Let's now see what consequences these two requirements have, by regarding
the following set of axioms (originally stated by Jeremy):

  <a> a owl:Thing .
  <a> a owl:Class .
  <b> a owl:Thing .
  <b> a owl:Class .
  <a> owl:sameAs <b> .

To ease the discussion, I will denote the different involved resources by
the URIs "<a_Thing>", "<a_Class>", "<b_Thing>" and "<b_Class>". 

The last axiom tells us that 

  <a_Thing> owl:sameAs <b_Thing>, 

i.e. that the individuals denoted by "<a_Thing>" and "<b_Thing>" are equal.
>From (B) we get that the individual resource <a_Thing> equals the class
resource <a_Class>, and that the individual resource <b_Thing> equals the
class resource <b_Class>. So we have

  <a_Class> = <a_Thing> = <b_Thing> = <b_Class>

So the class resource <a_Class> equals the class resource <b_Class>. And the
OWL-Full compatibility required by (A) allows us to get from this equality
of class resources to the equality of the respective class /extensions/:

  CLASSEXT(<a_Class>) = CLASSEXT(<b_Class>)

So we receive the entailment:

  <a> owl:sameAs <b> |= <a> owl:equivalentClass <b>

I am not sure if this argumentation is correct, but I do not find any error.
If it is correct, then under the conditions (A) and (B) we can actually
entail class equivalence from individual equality when using punning. So it
seems that if punning deploys under the conditions (A) and (B), then Jeremy
was wrong with his original analysis that this entailment would not hold for
punning. (Getting this entailment by a reasoner is another story, of course,
nothing is said here about algorithmically completeness).

Turning this argument around, we can see that if, for some given kind of
punning mechanism, this entailment does not hold, then this has one of the
following two consequences:

  (A') Not in every case do individuals and classes, 
       which have the same name, are the same resources.

  (B') OWL-Full semantics are invalidated.

So if we accept that conditions (A) and (B) are necessary requirements for
any OWL-1.1 punning mechanism, then not having "same |= equivalence"
entailment would be a real showstopper. And after what I have heard in the
other mails in this thread yet, this entailment really seems /not/ to hold.

>Regards,
>Alan

Cheers,
Michael

>> [1] "Next Steps for OWL"
>>     http://owl-workshop.man.ac.uk/acceptedLong/submission_11.pdf

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

Received on Friday, 2 November 2007 19:12:14 UTC