W3C home > Mailing lists > Public > public-owl-wg@w3.org > June 2008

Re: Issue-114

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Mon, 30 Jun 2008 16:26:33 -0400
Message-Id: <A0F076C0-6629-4F5E-B013-75DC860BB366@gmail.com>
Cc: OWL Working Group WG <public-owl-wg@w3.org>
To: Rinke Hoekstra <hoekstra@uva.nl>

On Jun 30, 2008, at 2:46 PM, Rinke Hoekstra wrote:

> Hi Alan, Michael,
> On 30 jun 2008, at 19:59, Alan Ruttenberg wrote:
>> After discussion with Michael, we agreed to narrow this issue as  
>> follows: We propose that the only punning in OWL is against  
>> individuals - that is, anything named in OWL can have an  
>> individual with the same (punned name).
> Could you please clarify what the underlying reason is for this  
> restriction? Object/datatype property punning and class/datatype  
> punning were problems because of a compatibility issue with OWL  
> Full. Is there a similar problem with class/property and individual/ 
> property punning?

There is no problem with individual/property punning - this is  
included as valid in my proposal. There has never been, as far as I  
am aware, a call for class/property punning.

> If the restriction is based on an apparent lack of use cases I'm  
> sure with a little effort we could come up with several. For instance,
> 1) The use of elephant and mouse properties to represent 'all  
> elephants are bigger than all mice' (Markus' paper). The trick is  
> to bridge the gap between TBox and RBox by making e.g. the class  
> 'elephant' equivalent to a self restriction on the 'elephant'  
> property. Role inclusion axioms can then be used (together with the  
> universal role) to connect all elephants to all mice. I feel that  
> this is a case where class/property punning is appropriate.

In the case of individual/xx punning, we have the prospect (in DL)   
of (eventually)  saying x (individual) sameAs y  (individual) => x  
(type specific equivalence) y, In OWL full this is already part of  
the semantics.

How should this work with punning between properties and classes?

> 2) A well known case is the relational nature of several roles,  
> such as 'father'. Sometimes 'father' is used in the sense of  
> 'has_father', sometimes it should be the class of fathers (or, more  
> precisely, the role played by persons who are fathers). Again,  
> using role inclusion axioms you can do a reification-like trick to  
> infer the 'father' relation between two classes, given the chain  
> has_father o played_by -> father.

Could you write out what you mean by this in (possibly pseudo) OWL  
and explain how I should understand it. I can't really understand  
what you mean here.

>> This corresponds to what I believe is the commonly requested case,  
>> and simplifies the current situation in which we have narrow  
>> restrictions on certain forms of punning - no object/data property  
>> punning, no class/datatype punning.
> I don't think this is a very convincing argument, as exactly the  
> cases of punning that are currently already prohibited are not very  
> intuitive. Having just class/individual punning is hard to defend  
> (in particular because, at least in my view, most cases for class/ 
> individual punning is just bad practice)

It may be bad practice, but is is requested. To the extent that we  
are chartered to provide features that have been identified by users  
as widely needed, I think it ought to be a consideration in choosing  
what is in and outside OWL. If we don't get rich annotations, the  
class and property to instance punning will provide features that can  
not otherwise be met.


> -Rinke
> -----------------------------------------------
> Drs. Rinke Hoekstra
> Email: hoekstra@uva.nl    Skype:  rinkehoekstra
> Phone: +31-20-5253499     Fax:   +31-20-5253495
> Web:   http://www.leibnizcenter.org/users/rinke
> Leibniz Center for Law,          Faculty of Law
> University of Amsterdam,            PO Box 1030
> 1000 BA  Amsterdam,             The Netherlands
> -----------------------------------------------
Received on Monday, 30 June 2008 20:27:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:05 UTC