Re: Case for Reinstatement of Qualified Cardinality Restrictions

i have a few thoughts on the matter.  I mark them with + or - to 
indicate support or lack of it for the addition.

++ there is no doubt that qualified number restriction is useful.  When 
i have it in languages I use it.
Alan gives good examples of its usefulness.

-- I also believe there is no doubt that qualified number restriction is 
confusing to people.  Even though I was aware of this issue before 
releasing daml+oil, I was still surprised by the number of smart people 
with good backgrounds who used daml+oil and asked me cardinalityq 
showing that they clearly did not understand it even though they read 
our documentation and attempted to understand it.

- there is an interesting datapoint that protege (having been used for a 
significant number of medical models for a number of years) does not 
have qualified number restriction and they claim that their users have 
not been asking them for it.  (I went to a protege meeting today and 
specifically asked them about two issues: 1 - if their users had 
requested it.  2 - if it would be a problem for them if we put it in owl 
and they came up to owl compliance.  The answer to 1 was no - their 
users are not asking them for it and they have a lot of medical 
applications.   The answer to 2 was they could put it in but it would be 
messy and would complicate the interface significantly.  Of course they 
are only putting it in from a modeling perspective (and not from a 
reasoning perspective).

 + if we put it in, i can write the necessary additions to the overview 
in the same style as is currently there.  This is the easy part though.

- not all implementations of OWL reasoning will be in the tableaux 
reasoner style.  For some styles of implementation, qualified number 
restriction poses non-trivial additional work to support over the 
current OWL DL/Full  syntax.

My bottom line is I am on the fence on the issue of adding it to OWL DL 
and OWL Full.
(Of course I would vote strongly against adding it to OWL Lite).

If we expect this release of OWL to be the final OWL, then i would want 
to put it in OWL DL and Full expecting that some implementations that 
were "just" going to be able to make it up to OWL DL/Full compliance may 
choose not to implement it, thus not be complete. 
If we are more interested in getting more implementations that are 
likely to be able to support OWL DL (with qualified number restriction), 
then I would vote for keeping it out of OWL DL in our upcoming release.

One option is to put it in OWL Full but not OWL DL (thus breaking the 
past decision to have them have the same syntax).


Jim Hendler wrote:

> At 6:20 PM -0400 4/16/03, Jonathan Borden wrote:
>> As I recall the discussion at the Amsterdam F2F -- I had wondered if 
>> such
>> features would be needed by biomedical ontologies and thought that I was
>> told that this wasn't the case.
>> The use cases he cites are compelling (at least to me), and if indeed
>> qualified cardinalities *are* needed to support these then I strongly
>> support reopening the issue.
>> Jonathan
> I am worried that the feature most complained about in Daml+oil and 
> also the ones most misused were these.  Let me make a suggestion -- if 
> we were to decide to include these, we would need to write the 
> one-paragraph, easy to understand explanation that would go in the 
> Overview -- anyone want to take a stab at a suggested one?
>  -JH
> p.s. Any change that would require us to change every document and 
> that is exposed by test cases makes me nervous at this late date -- 
> I'd want to see pretty strong support for the change...
>>>  The following long message (from [1]) comes from Alan Rector to our
>>>  comments list, addressing the issue of the qualified constraints -
>>>  basically, he's asking us to reopen issue 3.2 Qualified Cardinality
>>>  constraints.  Guus and I would like to hear the WG's feelings on
>>>  this.  Since there's no specific document addressed (although it
>>>  would require changes in every document), Guus and I will handle this
>>>  email and its response.
>>>    -JH
>>>  [1]

Received on Friday, 18 April 2003 21:02:12 UTC