Re: Punning and the "properties for classes" use case (from public-owl-dev)

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.

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, 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".

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.

Regards,
Alan


> Anyway, if my argumentation above is right, then punning does not  
> cover the "properties for classes" use case.
>
>
> Cheers,
> Michael
>
> [1] "Next Steps for OWL"
>     http://owl-workshop.man.ac.uk/acceptedLong/submission_11.pdf
>
> [2] "OWL 1.1 Model-Theoretic Semantics", chapter 2
>     http://www.webont.org/owl/1.1/semantics.html#2
>
>
>

Received on Thursday, 1 November 2007 18:41:42 UTC