Re: AS & S review: RDFS-compatible OWL semantics

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