W3C home > Mailing lists > Public > www-webont-wg@w3.org > April 2002

RE: proposed resolution of Qualified Restrictions

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Wed, 24 Apr 2002 09:53:45 +0100
To: "Jonathan Borden" <jonathan@openhealth.org>, <www-webont-wg@w3.org>
Message-ID: <JAEBJCLMIFLKLOJGMELDOENACDAA.jjc@hplb.hpl.hp.com>

> -----Original Message-----
> From: www-webont-wg-request@w3.org
> [mailto:www-webont-wg-request@w3.org]On Behalf Of Jonathan Borden
> Sent: 22 April 2002 18:31
> To: Jeremy Carroll; www-webont-wg@w3.org
> Subject: Re: proposed resolution of Qualified Restrictions 
> Jeremy Carroll wrote:
> >
> > As issue owner, since I believe I have heard consensus, I now summarise
> that
> > consensus and propose a resolution.
> >
> > Summary of consensus
> > ====================
> > At the face2face no one wished to include qualified restrictions in OWL.
> Um. I'm not entirely happy with this summary for the following reasons:
> 1) The charter at least suggests that we use DAML+OIL with changes if there
> are good reasons for doing so. There should be some burden of at least
> explaning why a change is being proposed. e.g.
> - I assume the cardinality Q constraints were put into DAML+OIL for a good
> reason. Why?
> - What are the problems caused by these constraints?
> - Are they simply syntactic sugar?
> - If they are simply syntactic sugar, which is what I thought was the
> explanation of why they might be dropped, then we should have a lower burden
> for dropping them. On the other hand, if they are other than syntactic
> sugar, we should have a higher burden as this will change DAML+OIL in other
> than a merely cosmetic fashion.

I heard that the set of people who understood what the Q things were was small,
and that no-one in that set could think of a good reason for having them.

Thus the (implicit) argument for dropping them is the sense that they add to the
difficulty of the language for no user benefit.

(I believe that the unqualified restrictions are commonly implemented as qualified

> 2) Mike Dean had already raised another issue [3.2 Qualified Restrictions].
> How is this issue different from the issue at hand? I presume Mike has a
> desire for qualified restrictions, otherwise why was that issue raised. At
> the very least we should hear what Mike et al. have to say before closing
> the issue.

I used the URLref of Mike's issue.
Unfortunately someone changed the fragment ID under my feet! :)

This is the same as that issue.

> 3) I thought that at the F2F we were trying to come to a compromise on a
> single OWL language. It seems that lots of folks were unhappy on both sides
> of the compromise. I though the Q restrictions were 'dropped' as part of
> this compromise process. Since we have decided to have two conformance
> levels, what are the problems having something very much like DAML+OIL at
> the full level. Note: the issues with usability look to me like they will
> need to be resolved at the 'presentation syntax' level.

I heard it different, that no-one wanted the Q things at all.

If at the telecon it is clear that we don't have consensus, I would prefer to 
unopen this issue. I was only opening it because I thought we were already 
at consensus on it.

> >
> > Proposed Resolution
> > ===================
> >
> > I propose that the WG
> > - decides that the qualified restrictions of DAML+OIL are not part of OWL.
> > - approves the test cases of
> > http://lists.w3.org/Archives/Public/www-webont-wg/2002Apr/0126.html
> >   as reflecting this decision.
> > - closes the unmentioned-qualified-restrictions issue.
> >
> >
> > If there is anyone who believes they should be part of OWL, please respond
> > to this message - ideally arguing for retaining them.
> >
> I think this issue deserves at the very least a written explanation for the
> archives. The minutes of the F2F do not have such an explanation.

That's fair.
I will address that separately.

> Jonathan
Received on Wednesday, 24 April 2002 05:10:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:43 UTC