W3C home > Mailing lists > Public > www-webont-wg@w3.org > February 2003

Re: OWL Syntax - complex restrictions

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Wed, 19 Feb 2003 14:15:55 +0000
Message-ID: <3E53919B.6030405@hpl.hp.com>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
CC: www-webont-wg@w3.org


My summary of where we are at:

We agree that test 102 can be fixed easily, and that test 103 cannot.
We disagree about the importance.

You have not disagreed that either of my suggested fixes would allow this 
mapping rule to be removed.

I note that you have not offerred any text that describes OWL Lite graphs 
without reference to the mapping rules.

A minor technical note is that you already have an unmappable abstract 
syntax construction - an empty multipart restriction does not match any 
rule. (This is attractive to me since it fixes entailment problems reported 
in [1]; I suggest you do not add mapping rules to cope with this case).

Jeremy

(no inline comments below)

[1]
http://lists.w3.org/Archives/Public/www-webont-wg/2003Feb/0158.html
[[
Ontology( Individual( type( restriction( dp ) ) )

entails

Ontology( DataValuedProperty( dp ) )
]]

Peter F. Patel-Schneider wrote:

> From: Jeremy Carroll <jjc@hpl.hp.com>
> Subject: OWL Syntax - complex restrictions
> Date: Wed, 19 Feb 2003 11:38:25 +0100
> 
> 
>>I attached three tests related to the mapping rule:
>>
>>restriction(ID component1 … componentn) 
>>(With at least two components)
>>
>>=>
>>
>> _:x owl:intersectionOf 
>>  T(SEQ(restriction(ID component1) …
>>    restriction(ID componentn))) .
>>
> 
> This rule should be changed to look like the rule for intersection, in
> particular, and the other rules for descriptions and restrictions, this was
> an oversight on my part when I added the optional type triples.  I have
> just now made this change.
> 
> However, read on ...
> 
> 
>>The first test (101) shows a simple application of this rule.
>>According to both the AS&S WD and the S&AS editors draft this is OWL Lite.
>>
> 
> Agreed.
> 
> 
>>This rule is the only way on OWL Lite of introducing a bNode that looks 
>>somewhat like a description.
>>Other use of intersectionOf in OWL Lite is on named classes.
>>
> 
> This is the ony way in OWL Lite of introducing a bNode that is a
> non-restriction description.
> 
> 
>>Other class-like bNodes are all of type owl:Restriction.
>>
> 
> Agreed.
> 
> 
>>This rule is very fragile, when used backwards.
>>
> 
> For OWL Lite, agreed.
> 
> 
>>The second test 102 shows has changed an rdf:Description in test 101 to an 
>>owl:Class. Since this node is the subject of owl:intersectionOf and the 
>>object of rdf:type, this should be relatively innocuous - instead it means 
>>that the construct now can only correspond to an abstract syntax description 
>>and is hence in OWL DL.
>>
> 
> The remedy here is to make the rule look like the other rules for
> descriptions, i.e., allow for optional owl:Class and rdfs:Class typing.
> 
> 
>>The third test 103 again exhinits the fragility of this rule, since the only 
>>change is one #p is replaced by a #q. Again this is enough to make the 
>>construct a description rather than a multipart restriction - and hence this 
>>file too is in OWL DL according to the published docs.
>>
> 
> I agree that this is now in OWL DL.
> 
> 
>>This is fixed in my work on syntax by simply not allowing multipart 
>>restrictions in the abstract syntax.
>>http://sealpc09.cnuce.cnr.it/jeremy/owl-syntax/2003-12-Feb/intro.html
>>
> 
> Well, forbidding multi-part resrictions would do the trick.  However, I
> don't see that there is nearly sufficient reason to change something that
> has been in the OWL abstract syntax since the beginning.
> 
> 
>>Another possible fix is to:
>>- simply delete the mapping rule.
>>  Then not all abstract syntaxes can be mapped, which would need editorial 
>>comment, but is non-fatal to the overall design.
>>
> 
> I don't view this as a desirable change.
> 
> 
>>This fix can also be applied to the EquivalentZZZ's rules and the 
>>DisjointClasses rules - only have them defined for two elements.
>>Some abstract syntaxes then cannot be mapped, but are semantically equivalent 
>>to ones that can.
>>
> 
> I view this changes as undesirable.
> 
> 
>>Jeremy
>>
> 
> peter
> 
Received on Wednesday, 19 February 2003 09:16:15 GMT

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