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

Re: new version of semantic layering document

From: pat hayes <phayes@ai.uwf.edu>
Date: Mon, 23 Sep 2002 14:37:31 -0500
Message-Id: <p05111b39b9b513f28f35@[]>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: www-webont-wg@w3.org

>On a quick read through of part of the new document I found the following
>issues.  I'm assuming that rdfs:subClassOf, rdfs:subPropertyOf,
>rdfs:domain, and rdfs:range are strengthened to iff.

Yes for the subs, as the document says; no for domain and range. See 
my message to Jeremy.

BTW, strengthening domain and range to IFF seems to me to be a really 
bad idea, in general: it completely destroys the idea of conjunctive 
range/domain assertions. We put the current semantics into RDFS in 
order to conform to the DAML conjunctive semantics, so why do you 
want to blow this out of the water in OWL?

>Without this
>strengthening, many more of the claims in the document are incorrect.
>- owl:UniqueProperty is not in OWL.

OK, delete that then.

>- Making IOC and IOP sets of sets doesn't seem to have any impact.  The
>   fact that ICEXT(IS(owl:Class)) is a set of sets doesn't make ICEXT(IS(foo))
>   have any relationship to IS(foo), for foo in ICEXT(IS(owl:Class)).

Right. But the relevant restrictions are added for fast OWL and dont 
need to be mentioned for large OWL. It could just be omitted, but it 
really only is there to introduce the abbreviated names IOC and IOP, 
in order to shorten the statement of subsequent semantic conditions. 
[But reading on, I see that there should be a stronger statement made 
here. Some of the fast-OWL conditions need to be moved back into weak 

>- owl:DisjointWith is incorrect.  There is no reason to require that the
>   disjoint classes be nonempty.

OK, its easy to make that change if you prefer. It seems odd to say 
that an empty class is disjoint with itself, is all.

>- Care has to be taken with lists that contain elements of LV.

I wondered about that and decided it was harmless. In large OWL of 
course it is; in fast OWL, the syntactic conditions need to be stated 
so that only lists of the right kind can be used as arguments in the 
appropriate places. I agree that this issue is rather rushed over in 
the current draft: there might be a need for a more exact statement 
of the syntactic restrictions on fast OWL.

As you know, in an earlier version I did have a rather over-elaborate 
way of specifying the syntactic legality in terms of conditions on a 
closure set, but I think that is best left as a kind of existence 

>- Weak OWL only requires the existence of unions, intersections, finite
>   sets, and complements.  This means that (someValuesFrom foo bar) does not
>   necessarily exist.

Right. The text says that explicitly. Are you saying this is a problem?

One option that I considered for a while is to not bother mentioning 
'weak OWL' at all, and just go directly to strong OWL, then impose 
purely syntactic restrictions to define fastOWL as a subset. That 
would certainly be the most attractive way to present the overall 
picture, but after an hour wrestling with how to state the 
restriction closure conditions to make this work I gave up.

>- It is not the case that Weak OWL requires IOC to contain all finite
>   subsets and be closed under union, intersections, and relative
>   complements.  All that is required is that for each such set, IOC
>   contains an element whose class extension is that set.

Right, that is a wording error. I will fix that, thanks.

>- In a Weak OWL interpretation it is not the case that
>       owl:Thing rdf:type owl:Class .
>       owl:Nothing rdf:type owl:Class .
>   In general Weak OWL does not force any particular class to belong to
>   owl:Class.

Ah yes, you are right. Careless of me, sorry. I need to move some of 
the conditions on the domain from fast OWL to weak OWL. Its a bit too 
weak like this.

>The claim that owl:Thing, owl:Property, and owl:Class are
>   analogues to rdfs:Resource, rdfs:Class, and rdf:Property is incorrect.
>   Further, all of
>	owl:Class rdfs:subClassOf rdfs:Class .
>	owl:Restriction rdfs:subClassOf owl:Class .
>	owl:Property rdfs:subClassOf rdf:Property .
>  are not true in Weak OWL, nor is
>	AAA rdf:type owl:Property .  ->  AAA rdfs:domain owl:Thing .
>  a valid inference in Weak OWL.

OK, I need to strengthen weak OWL to support all this. That was 
certainly my intention. I will try to get this done by tomorrow.

>- In Large OWL it is not the case that owl:Class and rdfs:Class have the
>   same extension.  In particular owl:Nothing (and indeed most empty
>   classes) can belong to neither, either one or, or both of owl:Class and
>   rdfs:Class in Large OWL.  It is thus not the case that IOC=IC or IOP=IP
>   in Large OWL.

No, wait. It is *stipulated* that IOC=IC and IOP=IP in large OWL. 
Those equations are part of the large-OWL semantics. So it is the 

>- The closure conditions for Large OWL should change integer to
>   non-negative integer.

Ah, OK. The expressions would still make sense with negative 
integers. But as you prefer.

>- There are many restrictions in Large OWL that may be problematic because
>   their presence may affect their extension.  For example, what is the
>   class extension of 
>       _:x owl:onProperty rdfs:subClassOf .
>       _:x owl:maxCardinality 57 .

Its the class of all RDFS classes which have no more than 57 
subclasses, right? That might be empty, for all I know. (Oh no, wait, 
all the empty classes are in it.) But Im sure it *exists*. In fact, 
you could toss in things like transfinite cardinalities (as long as 
they are describable) and I would still be sure the restriction 
classes would exist.

>   Can it be shown that there are *no* problems in determining the class
>   extensions of all the restrictions that mention the RDF and RDFS
>   structural properties and that thus may interfere with their own class
>   extension?

Im not sure what you mean by 'interfere with'. One can certainly 
create inconsistencies by asserting that, say, rdfs:subClassOf is the 
same as some odd restriction. But just defining new restriction 
classes in terms of the RDFS/OWL vocabulary doesn't in itself 
interfere with that vocabulary in any sense I can think of.

>These are all the issues that I could find in a quick partial reading of
>the document.
>PS:  I would much have preferred to try to get a version of the previous
>      document that didn't have any known bugs before making such drastic
>      changes.

Well, the previous approach seemed to be hopeless, and this is really 
only a simplified version phrased somewhat differently. The only 
major change was realizing that we could impose simplified 
restriction closure conditions on large OWL, and let it support all 
the intuitive inferences. (That is what took the weekend.)

Im sorry that Im always pushing others against time limits on this, 
however. Thanks for all the help.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Monday, 23 September 2002 15:37:25 UTC

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