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

[...]

> > > > 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
> 

Herman