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

Re: PROPOSAL to close issue 5.9 Malformed DAML+OIL Restrictions

From: Dan Connolly <connolly@w3.org>
Date: 31 Oct 2002 17:58:59 -0600
To: "Peter F. "Patel-Schneider <pfps@research.bell-labs.com>
Cc: www-webont-wg@w3.org
Message-Id: <1036108739.9227.1945.camel@dirk>

On Thu, 2002-10-31 at 14:02, Peter F. Patel-Schneider wrote:
> 
> Recall that malformed OWL restrictions are things like
> 
> _:x owl:onProperty ex:pa .
> _:x owl:onProperty ex:pb .
> _:x owl:minCardinality xsd:integer"5" .
> _:x owl:allValuesFrom ex:ca .
> 
> I do not believe that there is any way to make these things work nicely.
> They should never happen,

Quite; does the guide make that clear?
If not, I'd like to ammend this proposal
so that the guide will say "don't do that."
Hmm... reading the guide,
http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/att-0322/01-Guide.html
I don't see a natural place to put it.

How about the reference?
(sorry, ran out of time to suggest text)

> but they do need to be handled in the
> RDFS-compatible OWL model theory.
> 
> Right now there are two different ways of treating such junk.
> 
> 1/ In the DAML+OIL model theory and in my earlier RDFS-compatible model
>    theories for OWL, the effect of such collections of triples is to force
>    all legal restrictions that can be formed from the triples to be
>    co-extensional. 
>    For example, the above four triples would imply that the following four sets
>     {u in IOT | card({v : <u,v> in IEXT(IS(ex:pa))}) >= 5 }
>     {u in IOT | card({v : <u,v> in IEXT(IS(ex:pb))}) >= 5 }
>     {u in IOT | <u,v> in IEXT(IS(ex:pa)) -> v in ICEXT(IS(ex:ca)) }
>     {u in IOT | <u,v> in IEXT(IS(ex:pb)) -> v in ICEXT(IS(ex:ca)) }
>     are all the same.
> 
> 2/ In Pat's model theories for OWL, and in the current semantics document,
>    the effect of such collections is to force the properties to be the
>    same, and then to force co-extensionality.
>    For example, the above four triples would imply IS(ex:pa) = IS(ex:pb) 
>    *and* that the following two sets
>     {u in IOT | card({v : <u,v> in IEXT(IS(ex:pa))}) >= 5 }
>     {u in IOT | <u,v> in IEXT(IS(ex:pa)) -> v in ICEXT(IS(ex:ca)) }
>     are the same.

Either way is fine by me.

> I PROPOSE to use the DAML+OIL solution because I find that forcing the
> properties to be the same commits more violence than just forcing the
> various extensions to be the same.

I concur.

> Note that the entire issue does not arise in the abstract syntax as there
> is no way of creating such malformed restrictions there.
> 
> Peter F. Patel-Schneider
> Bell Labs Research
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Thursday, 31 October 2002 18:58:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:53 GMT