From: <herman.ter.horst@philips.com>

Date: Thu, 23 Jan 2003 14:18:26 +0100

To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>

Cc: www-webont-wg@w3.org

Message-ID: <OF7638A053.AE218D95-ON41256CB7.00380681-C1256CB7.00494644@diamond.philips.com>

Date: Thu, 23 Jan 2003 14:18:26 +0100

To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>

Cc: www-webont-wg@w3.org

Message-ID: <OF7638A053.AE218D95-ON41256CB7.00380681-C1256CB7.00494644@diamond.philips.com>

[...] > > > > 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. I do not agree with your last sentence. When the definition is given, it is given, and then later statements have to be interpreted in the light of the definition. So I interpret this sentence as: for each y in IC and x in IR, x is in ICEXT(y) iff <x,y> is in IEXT(I(rdf:type)) > > > > > > 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. In my view, it is in the part of the RDF Semantics document I quoted. Which semantic conditions don't work, are they in the RDF Semantics or the OWL Semantics? > > [...] > > > > > 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. According to the definition of simple interpretation in the RDF Semantics document, you can define the value IEXT(I(ex:prop)) only if I(ex:prop) is in PI. I see no problem here. > [...] > > > > > > 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. For the first of these two lines, see my comment above. For the second line: IC = ICEXT(I(rdfs:Class)) is a true characterization of the set IC, but IC was already defined earlier, before the function 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. Peter: please comment here as well: this is independent from the IC/ICEXT issue. > > > > > > > > > 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. This is true, but this does not help to prove ("syntactically", using axioms and/or theorems) that {v: <u,v> in EXTI(p)} is a set. This is the main point. Another argument to make this change: I noted that in the direct semantics in Section 3, this set is written in the exact corresponding way as I propose to do here: there it is {y in R union LV : <x,y> in ER(p)}; compare here {v in IOT union LV : <u,v> in EXTI(p)} so R union LV there takes the place of IOT union LV here. So you help the reader by writing it here in the same way. > > > 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. I do not know what you mean here. Let me make clear that I do NOT object to the notation + for disjoint union: there is no really standard notation for this. I only suggest to mention, in the first place in the document where it is used (which is probably here), that it stands for disjoint union. [...] > > > 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. Do you communicate this with RDF Core? > > > 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. OK: I saw this in your new version of 22 January. So it only depends on that RDF Core changes the definition of D-interpretation in the expected way. > > > > > Herman ter Horst > > Philips Research > > peter > HermanReceived on Thursday, 23 January 2003 08:20:27 UTC

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