- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Mon, 31 Mar 2008 19:29:34 -0400 (EDT)
- To: schneid@fzi.de
- Cc: public-owl-wg@w3.org
From: "Michael Schneider" <schneid@fzi.de> Subject: RE: ACTION-93 / ISSUE-63: Initiated work on OWL-1.1-Full semantics Date: Mon, 31 Mar 2008 12:49:02 +0200 > Hi Peter! > > Peter F. Patel-Schneider wrote on Wednesday, March 26, 2008: > > >> >2/ I do not believe that a comprehension principle is needed for > >> > owl11:disjointUnionOf (so long as there is a > >> > comprehension principle > >> > for lists of descriptions) and the syntax requires that the > >> > disjointUnion be a named class. > >> > >> I don't understand your last remark about the requirement of > >> a named class. > > > >If a named class is required (and it currently is) > > > >disjointUnion := 'DisjointUnion' '(' { annotation } > >owlClassURI description description { description } ')' > > > >then there is no need to ever require the existence of a node on the > >"left hand side" of an owl:disjointUnionOf because the only nodes that > >are needed there to make entailment work out are named classes. > > I don't see a way to perform such a restriction to only /named/ > classes in OWL-Full. > > This is, of course, possible in OWL-DL, which demands that an ontology > has to be syntactically valid to its Abstract/Functional syntax. This > syntax can then restrict the use of a node within a certain language > construct to be only an URI. And the OWL-DL semantics are then only > specified for such a syntactically valid expression. > > But how can I specify such a constraint in OWL-Full, for which /every/ > RDF graph is a syntactically valid input and gets interpreted by > OWL-Full semantics? You can't. But if all you are interested in is extending the OWL-DL semantics, then you don't need to be able to infer :_b owl:DisjointUnionOf ..... for arbitrary blank nodes. However, the question is moot! Because there is a comprehension principle for owl:unionOf for any sequence of descriptions there is going to be a blank description node (_:u) related to that sequence via an owl:unionOf link. If the sequence is pairwise disjoint, then by the semantics of owl:DisjointUnionOf _:u will be (or should be!) related to the sequence by owl:DisjointUnionOf. > [...] > > >> (A) How do you think about my approach to introduce the > >> "missing" axiomatic > >> triples? Was is intended to not include them, and if so, for > >> what reason? Or > >> has it just been forgotton? > >It was intended not to include them. It's not as if there are any real > >problems if these are not included, and, again, putting them in just > >increases the chance of some unintended consequence. > > In principle, I share this stance, because I have not yet seen a real > >advantage for having axiomatic triples in RDF(S). But in this case, I > >would have expected to see /no additional/ axiomatic triples at all > >in OWL-Full. However, OWL-Full has lots of them! > * Everything listed in the section "OWL built-in syntactic classes and > * properties" is in fact an axiomatic triple, even if it is not called > * so explicitly. For example, saying "I(owl:FunctionalProperty) is in > * C_I" (btw: it should be "S_I(owl:FunctionalProperty)", right?) > * corresponds to the axiomatic triple > owl:FunctionalProperty rdf:type rdfs:Class Well, the semantic condition implies that that triple is in each interpretation, yes. > There are 33(!) axiomatic triples of this kind alone in this single > section. And there are several more in the "parts of the OWL universe" > table. For example, the third entry about E := owl:Restriction > contains two of them: > owl:Restriction rdf:type rdfs:Class # "S_I(E) in C_I" > owl:Restriction rdfs:subClassOf owl:Class # "IOR subset IOC" > There are no premises of the form: "if a certain triple containing > these entities exist in the graph, then...", and so these assertions > are true for every graph, in particular they are entailed by the > /empty/ graph. Agreed. > My idea was to just add the /missing/ axiomatic triples. I did not see > a clear criterion for why those which exist are in, and why those > which do not exist are not in. The selection looks all a bit random to > me. I wanted to have a somewhat more systematic approach, or at least > follow existing precedence, and so I thought to follow the lead of > RDFS. I put it to you that following the lead of RDFS is not a good idea. In any case, the RDFS axiomatic triples do not follow from the other RDFS semantic conditions, which I believe is not the case for your triples. > Btw: I believe that there are people in the RDF-semantics world who > actually assume that the missing axiomatic triples are in > OWL-Full. For example, I can see that the domain and range axiomatic > triples for the owl:onProperty property is listed in the pD* > paper. But since it is not given in the OWL-Full spec, this means that > pD* is /not/ a semantical sublanguage of OWL-Full. I suspect that this > will come to a surprise to the author of pD*. In OWL 1.0 Full it is not the case that the domain of owl:onProperty is owl:Restriction nor is it the case that the range of owl:onProperty is owl:Property. Whether or not this is a bug (and I do not believe that it is), it does mean, as you point out, that reasoning in pD* is not sound with respect to OWL 1.0 Full. > >> (B) Why are there only "ONLY-IF" semantic conditions for > >> restrictions? The > >> introduction of sec. 5.2 in the AS&S says: > >> > >> "The only-if semantic conditions for the [restrictions] are needed > >> to prevent semantic paradoxes and other problems with the > >> semantics." > > > >> Can you please elaborate on this? [...] > Many thanks, I now understand the [principal] problem. > > >Which I suppose is not a complete collapse of the semantics, but is > >certainly not what you want. > > Would it surprise you to hear that the collapse (i.e. the > unsatisfiability of OWL-Full) would happen under IFF semantics for > restrictions? :) No I would not. A demonstration of this would be interesting. > Cheers, > Michael peter
Received on Monday, 31 March 2008 23:36:57 UTC