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

LANG, GUIDE, SEM: issue 5.9 Malformed DAML+OIL Restrictions

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Mon, 30 Sep 2002 20:05:49 +0100
To: <www-webont-wg@w3.org>

The LANG GUIDE and SEM docs seem to say different things about this issue,
it hasn't been closed so I guess that's fair:

Restrictions with extra components (e.g., an owl:Restriction element with
multiple different owl:onProperty elements) have unusual and misleading
semantic impact (in general equating the extensions of two or more
well-formed restrictions). Use of such constructs should be avoided. See
issue #5.9-Malformed-DAML+OIL-Restrictions.

I believe the abstract syntax prohibits them.

GUIDE says:
owl:maxCardinality can be used to specify an upper bound. In combination
with owl:minCardinality it is possible to specify a range.
which I read as:

      <owl:onProperty rdf:resource="#VINTAGE-YEAR"/>

(I realise this isn't the doc we were asked to read)
I have changed the restriction conditions to IFF from Peter's document, as I
was worried that the conditions on restrictions may not be strong enough as
worded there. The issue is rather similar to the bug that Peter identified
in the RDFS subclass conditions: wording the semantics purely as only-if
conditions (if E is asserted, the interpretation must be thus...) does not
allow us to conclude that E is true, given some semantic conditions; the
'iff' version seems better and clearly is stronger. The closure conditions
ensure that we will not be stymied by some class failing to be in the
universe, and the functionality of IRP secures a unique property for each
restriction class, so I can see no reason to have the weaker conditions. If
I'm not seeing some fatal problem, please let me know: it would be easy to
change it back.

as I see it, your iff condition means that at least semantically any
owl:cardinality restriction would necessarily also have owl:minCardinality
and owl:maxCardinality arcs hanging off it. I am fairly agnostic on this,
but it does seem to relate to issue 5.9
Received on Monday, 30 September 2002 15:02:34 UTC

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