- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Wed, 22 Jan 2003 19:37:26 -0500 (EST)
- To: herman.ter.horst@philips.com
- Cc: www-webont-wg@w3.org

From: herman.ter.horst@philips.com Subject: Re: AS & S review: RDFS-compatible OWL semantics Date: Mon, 20 Jan 2003 15:32:22 +0100 > > From: herman.ter.horst@philips.com > > Subject: AS & S review: RDFS-compatible OWL semantics > > Date: Fri, 17 Jan 2003 17:13:06 +0100 > > > > > Here is the next part of my review comments on the Semantics > > > document: > > > Section 5 RDFS-Compatible Model-Theoretic Semantics > > > Version of 16 January [...] > > > A related point is that the domain of the function CEXTI consists > > > only of the set of classes CI, which may also not be all of RI > > > (this was already the case with the RDF MT version of April). > > > > This is not correct. ICEXT is still defined for all resources, even for > > literals. This may be a bug in the RDFS semantics. > > ICEXT is defined for literals/datatypes. > This is an explicit policy of the RDF Semantics: see the definition > of D-interpretation, in particular the fourth condition in the table > and its explanation in the text below. > > But ICEXT is not necessarily defined for all resources. > In November, I pointed to a seeming circularity in the definitions > in the RDF MT, between the notions IC and ICEXT [1]. > Subsequently, the text was slightly expanded and does not leave > any room for doubt: IC is defined first, and ICEXT is > defined in terms of IC. > I quote from the most recent version of the RDF Semantics at [2]: > > "Although not strictly necessary, it is convenient to state the > RDFS semantics in terms of a new semantic construct, a 'class', > i.e. a resource which represents a set of things in the universe which > all have that class as the value of their rdf:type property. > Classes are defined to be things of type rdfs:Class. > We will assume that there is a mapping ICEXT (for the Class Extension > in I) from classes to their extensions; the first semantic condition > in the table below amounts to the following definition of this mapping > in terms of the relational extension of rdf:type: > ICEXT(x) = {y | <y,x> is in IEXT(I(rdf:type)) } " But then the RDF Semantics document goes on to state that x is in ICEXT(y) iff <x,y> is in IEXT(I(rdf:type)) For this to make sense, ICEXT has to be defined for all resources. > > > In view of this, the given summary of RDF semantics should be > > > replaced by an up to date and somewhat more extensive summary. > > > Let me briefly summarize the basic definition of the RDF semantics, > > > in order to be able to describe the additional assumptions that > > > need to be made in the OWL semantics, and in order to facilitate > > > the replacement of the given summary of the RDF semantics. > > > I use the slight adaptation made by Peter of the original notation > > > of Pat, however without making many final I's a subscript, of > > > course. > > > An RDFS interpretation of a vocabulary V is a five-tuple consisting > > > of: > > > - a set RI (the universe) > > > - a set PI subsetOf RI > > > - a function EXTI : PI -> P(RI x RI) > > > - a function SI : V -> RI > > > - a function LI : {typed literals} -> RI > > > satisfying many special conditions specified in the RDF Semantics. > > > (By the way, referring to an earlier part of this review, > > > note that the P(X) notation for power set is very convenient here.) > > > > > > Given such an RDFS interpretation, the set of classes is defined > > > to be > > > CI := {x in RI: <x,SI(rdfs:Class)> in EXTI(SI(rdf:type))}. > > > This set is defined to be the domain of the function > > > CEXTI : CI -> P(RI) > which function is defined by: > > > CEXTI(c) := {x in RI : <x,c> in EXTI(SI(rdf:type))} (c in CI) > > > > This is not in the RDF Semantics document. > > It is: see my quote above. I still don't see any requirement that the domain of ICEXT be IC, and, in fact, I see semantic conditions that don't work if the domain of ICEXT is restricted to IC. [...] > > > So each table in Section 5.2 needs to be expanded with an > > > assumption > > > SI(E) in CI (in case CEXTI(SI(E)) is used) or > > > SI(E) in PI (in case EXTI(SI(E)) is used). > > > > > > In the second table of Section 5.2 this is easy: each of > > > the empty cells in the second column can just be assigned > > > the content CI. > > > > Not needed. > > It is really needed. It is central to the purpose of this > document to define, with mathematical precision, the semantics > of OWL in terms of that of RDFS. If it is not ensured that the > mathematical functions used are only used inside their domains, > then mathematical rigor is lost. > > > > In the later tables it is also possible to incorporate the > > > required additional assumptions, in the bold header texts. > > > > Not needed. > > See previous comment. I still don't think that this is needed. Suppose I wanted to define a very simple extension to RDF. It would be acceptable to say that interpretations in this extension were RDF interpretations of a vocabulary that included ex:prop and that satisfied IEXT(I(ex:prop)) = < I(ex:prop), I(ex:prop) > It would not be necessary to directly state that I(ex:prop) had to be in PI because this would fall out of the RDF semantic conditions. [...] > > > The equations (*) above can be used to simplify many entries > > > in the tables in Section 5.2, by taking CI or PI instead of > > > the expansions in the right-hand sides of these equations. > > > It should be noted that CI and PI are more fundamental in the > > > RDF Semantics then these expansions. > > > > CI actually is subordinate to ICEXT(I(rdfs:Class)). > > Given that CI is subordinate, I prefer to keep consistency by using > ICEXT > > throughout. > > As I explained above, ICEXT is defined in terms of CI, > so CI is more fundamental than ICEXT and the > expression CEXTI(I(rdfs:Class)). The LCC version of RDF Semantics says x isin in ICEXT(y) iff <x,y> is in IEXT(I(rdf:type)) IC = ICEXT(I(rdfs:Class)) This looks to me as if IC is subordinate to ICEXT. [...] > > > The first table in Section 5.2 uses sets IOP, IOC etc. whose > > > meaning is not yet clear. Therefore I propose to move this table > > > to the third position. Then, moreover, we get three more coherent > > > "groups of tables" in a row: > > > 1. universe/syntactic categories; classes/datatypes/properties > > > 2. the "iff tables": domains/ranges; equivalence > > > 3. the "DL tables": Boolean combinations; restrictions; > > > comprehension principles > > > > I don't think that this reordering is helpful. > > In view of your addition just cited, is now even necessary > to move the first table. The sets IOP, IOC, IDC appearing in > the first table (the iff conditions for domains and ranges) > are only defined in the next table (on universe and syntactic > categories). > I propose to move the table on domains and ranges just before > the table on equivalences, since both work with iff conditions. > > > > > > I feel that Section 5.2 could use more text to motivate these > > > different kinds of tables. For example, can it be 'explained' > > > why is there an iff for owl:sameClassAs and owl:disjointWith > > > but not for owl:complementOf? > > > > There is very little motivation now. However, I think that a useful > amount > > of motivation would turn out to be a large amount of motivation. I've > been > > too busy with RDF to attend to it. > > > > > > > In my view, the first condition on oneOf is an unsuitable integration > > > of dissimilar conditions. In fact, the next table, which is > > > completely devoted to oneOf, could be omitted by slightly > > > extending the condition in the previous table, as follows: > > > ( x in IOC and l is a sequence of y1,...,yn over IOT > > > or x in CI and l is a sequence of y1,...,yn over LV ) > > > and CEXTI(X) = {y1,...,yn} > > > > The condition for oneOf is similar to the ones for unionOf and > > intersectionOf. I thus think that it should stay. The change you > suggest > > would cause problems for OWL DL. > > > > [...] > [...] > > > The table on the semantics of the cardinality restrictions > > > does not yet include the corrections which I believe you > > > confirmed earlier. > > > It should be, three times: > > > card{v in IOT union LV : <u,v> in EXTI(p)} > > > (In our earlier discussion I missed the LV part. > > > In this way, both object properties and datatype properties > > > are covered, in the correct, intended way.) > > > Without this addition, formally, there is no set, so > > > no cardinality can be taken. Instead, formally, there is > > > only a class, not in the sense of OO or RDF or OWL, but > > > in the sense of Zermelo-Fraenkel set theory. > > > > I disagree. I believe that the definitions are fine as they are. > > I am surprised that you retract the confirmation that you > earlier made in [3]. > Let me ask you a technical question: > How do you know ,in terms of axioms and/or theorems from set > theory, that {v: <u,v> in EXTI(p)} is a set? EXTI(p) is a subset of P(RxR) so there is a natural limit on what v can be. > The fact that {v in IOT union LV : <u,v> in EXTI(p)} is a set > follows directly from one the first axioms of set theory, the > specification axiom: a set is given, and a predicate for > forming a subset. > Apart from this set-theoretic argument, I am in favor of > making completely explicit, in this definition of the > semantics of minCardinality, maxCardinality, and cardinality, > which elements should be counted. > > > > > > I find it confusing, in the definition of separated OWL > > > vocabulary in Section 5.3.2, to identify a vocabulary > > > with a partition of it. I am in favor of omitting the > > > = sign, and of speaking of a vocabulary V' with partition > > > <...>. This would also affect (improve) the next paragraphs, > > > including the statement of Theorem 1. > > > > I should have used V = VI + VC + VD + VOP + VDP > > I believe you should add that + stands for disjoint union, since > this is non-standard notation. Sigh, I guess that I should then retreat to the vanilla, but much less readable form. [...] > > > In Sections 5.3.1/2, three RDF Graphs should become RDF graphs. > > > > Technical terms can (and often should) be capitalized, I believe. > > > You should be consistent in your choice: most often there is g, and > only three times G. More importantly, technical terms specifying > an individual item should indeed be capitalized, but generic technical > terms such as RDF graph or abstract OWL ontology (recall the earlier > part of my review) should not be capitalized. > As +to RDF graphs, moreover, let us be consistent with the > RDF Semantics document, which speaks of RDF graphs. > [...] OK, OK, ``RDF graphs'' it is. > > > As to notation, I prefer the standard notation for empty set > > > instead of {} (this also appeared in earlier sections). > > > > I prefer {}, as it uses the same notation as non-empty sets. > > Since {} is non-standard, it would need explanation. With > set theory as with RDF, I believe it is preferable to follow > the standard. I have seen {} many times, and do not count it as non-standard. [...] > I need to make some further remarks about Section 5. > > The definition of OWL interpretation does not yet have PI > added in the tuple I. Added. > There is a problem with the use of the word D-interpretation > in the same definition. The RDF Semantics speaks > of D-interpretations of RDF graphs, > not of vocabularies, so as to be able to refer to > the typed literals appearing in graphs. Well, actually the RDF Semantics document should be fixed here so that D-interpretations are defined in the same way as RDF- and RDFS- interpretations. > So the AS & S document cannot speak of D-interpretations > of vocabularies. I think that the RDF Semantics needs to be cleaned up here, and that any clean-up will result in D-interpretations of vocabularies. > I therefore believe that this definition should read as > follows: > An OWL interpretation I=<..> of a vocabulary V, where V > includes ..., is an RDFS interpretation of V that > satisfies all constraints in this section. > Before reacting, read also the next comment, where > D-interpretations return! > > The definition of OWL DL interpretation of an RDF graph > (and analogously of OWL Full interpretation) > should be slightly changed, to make it fit with the > RDF Semantics. Proposal: > Let K ... and V ... . An OWL DL interpretation of K > is an OWL DL interpretation of V that is also a D > interpretation of K and that satisfies K. > Motivation: see the preceding comment, and note also that > that the RDF Semantics speaks of satisfaction of graphs > rather than interpretation, when dealing with the > truth of the statements in the graph. I agree, however, > to make one shortcut with the definition of OWL > interpretation of a graph, in the way just indicated. I've changed this around somewhat to make it fit better with the newish RDF model theory. > > Herman ter Horst > Philips Research peter

Received on Wednesday, 22 January 2003 19:37:45 UTC