- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Sun, 16 Dec 2007 18:41:51 -0800
- To: Pat Hayes <phayes@ihmc.us>, Jim Hendler <hendler@cs.rpi.edu>
- Cc: Owl Dev <public-owl-dev@w3.org>, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>, OWL Working Group WG <public-owl-wg@w3.org>
On Dec 16, 2007, at 3:21 PM, Pat Hayes wrote: >> I agree with Jim on this, and on the fact that it is a serious >> error to revert to a DAML 'feature' which was rejected for good >> reasons, based on deployed systems and usage, in OWL 1.0. Could you summarize the "good reasons"? I am reviewing http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I3.2-Qualified- Restrictions > The Working Group decided 25 Apr 2002 to remove qualified > cardinality constraints. The issue was reopened due to new > information Apr 2003 from Alan Rector. In the 8 May 2003 > teleconference, the WG resolved > > ... to POSTPONE this issue for the following reasons: > > OWL already contains one QCR construct: owl:someValuesFrom (QCR > with minimal cardinality of 1) which covers some frequent-occurring > cases of QCRs. > > There are some workarounds for QCRs, using the rdfs:subPropertyOf > construct. These can be used in simple cases, such as the example > in the Guide below. The WG agrees that these workarounds are more > problematic for complex part-of relations such as pointed out by > Alan Rector in his use cases a) and b). > > The evidence on whether users need this is mixed. Rector's use > cases are compelling, but Protege (which has a large user > community) has not reported user requests for this feature. > > Inclusion of this feature will put additional burden on > implementations. For example, it is nontrivial to add this to Protege. > The Working Group therefore POSTPONES the full treatment of QCRs, > while considering possibilities for making idioms or other > guidelines for QCRs available to the community > My understanding of the current situations is that a) The the workarounds have been proven inadequate b) People *are* asking for the feature c) Implementors have indicated that they will support it - protege 4 supports it in the UI, and Fact++ and Pellet support it in the reasoner. (at a minimum). The postponement doesn't make reference to technical issues surrounding the additional vocabulary. Jim, on what basis, then, is it to be rejected now? I see a solution offered by Peter, and one offered by Pat. (I suggest more intuitive names for the properties). Both suggest additional vocabulary terms. Pat, would it be possible to explain the advantage of your solution over the one Peter suggests? Thanks, Alan
Received on Monday, 17 December 2007 02:42:08 UTC