Re: RDF Semantics review: RDFS interpretations

> On Thu, 2003-02-06 at 13:05, herman.ter.horst@philips.com wrote:
> > RDF Semantics, version of 23 January 2003
> 
> Could you please summarize your review with one bit,
> i.e. RDF semantics is acceptable or unacceptable
> as is for use by WebOnt?

In my previous message I summarized the status of my
review, which is not yet completely finished [3].
So I cannot yet give the one bit summary.

> 
> Also, I can't tell if these are editorial suggestions
> or substantive issues.

I would label this as a somewhat substantive, editorial 
suggestion.

> 
> If they're substantive, I'd very much appreciate
> example/test case(s) where the outcome is
> wrong as written and would be correct if the
> document were changed as you/we are requesting.
> 
> 
> Details below...
> 
> > There is confusion about the definitions of IC / ICEXT
> > in the WebOnt Working Group (see the discussion
> > on RDFS-compatible OWL semantics pointed to in [1]).
> > 
> > In order to eliminate this confusion, this is a somewhat 
> > extensive request for clarification of Section 3.3, 
> > RDFS interpretations.
> 
> 
> This seems like a matter of editorial preference.
> (That doesn't mean the comment isn't in order...)

In my view, it is more than a matter of editorial
preference.  The point is that Peter and I read the definitions
of IC and ICEXT differently, and this leads to somewhat
different details in Section 5 of AS & S, on
RDFS-compatible OWL semantics.

I read these definitions where they are first given,
and, naturally, interpret later statements about IC/ICEXT 
in the light of these original definitions. 
Peter chooses to ignore the textually first, original definition,
and interprets the later statements as definitions,
in a different way.
In my view, Peter's reading changes the design of the
RDF MT as it is now really written.
I have labeled my response a "request for clarification",
and suggested in my response to add several fragments to
the text in order to make everything abundantly clear, 
so that no false interpretation will be made.

An advantage of choosing my "my interpretation" is that the 
published Last Call version of RDF Semantics only
needs to be clarified, and not redesigned on this point.

There is another bonus of choosing my reading, which is 
admittedly somewhat subjective.
The RDF model theory gets more internal "symmetry",
simplicity, and uniformity, by treating
IP/IEXT and IC/ICEXT in exactly the same way.
Moreover, it is not at all natural to allow the speaking of 
ICEXT(x) when x is not a class.
Moreover, the complex tables in Section 5 of the 
OWL AS & S document can become somewhat simpler:
the entries CEXTI(SI(rdfs:Class)) can be replaced by CI.

(Peter: note that the entries CEXTI(SI(rdf:Property))
should now already be replaced by PI, as you now
also include this as the more fundamental entity from
the RDF model theory.)

Furthermore, the formal definition of OWL Full becomes somewhat
simpler than is currently described:
an OWL Full interpretation of a vocabulary V is an
OWL interpretation such that IOT=RI, IOC=CI, and IOP=PI.


> 
> > In an earlier email to www-rdf-comments [2]
> > I noted that there seemed to be a circularity
> > between the definitions of IC and ICEXT.
> > Subsequently the text was slightly extended, and made
> > clear to me that IC is defined before ICEXT.
> > 
> > For convenience I include below rather concrete suggestions
> > for extending the text further, in order to clarify the intent that 
> > seems to be already expressed.
> > (I do not claim that what I describe below would be sufficient
> > editorial work, of course.)
> > 
> > A central point is that the distinction between definitions 
> > and semantic conditions should be made more clear.
> > 
> > Another central point is that there is much analogy between
> > IP/IEXT and IC/ICEXT.  IP/IEXT is already defined as part
> > of a simple interpretation, while the definition of IC/ICEXT
> > is given for each rdf-interpretation.
> > 
> > > 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. 
> > It seems to be desirable to introduce the symbol IC here, 
> > for example in the following way:
> > For an rdf-interpretation I of a vocabulary that includes
> > rdfV as well as rdfsV, the set IC (of classes) is defined to be
> >    IC = {x in IR: <x,IS(rdfs:Class)> in IEXT(IS(rdf:type))}.
> > > 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)) }
> > It seems that clarity is improved if the reference
> > to semantic conditions is deleted here, and if it is said that,
> > for the same rdf-interpretation I as I just described,
> > the function 
> >    ICEXT from IC into the powerset of IR
> > is defined by 
> >    ICEXT(x) = {y in IR | <y,x> is in IEXT(I(rdf:type)) } 
> > (for x in IC).
> > 
> > [...]
> > 
> > (Note that similarly, the definition of simple interpretation
> > speaks of the function "IEXT from IP into the power set of IRxIR")
> > 
> > 
> > > The first condition can be understood as a definition of ICEXT 
> > > and hence of IC, the set of classes.
> > > Since I is an rdf-interpretation, this means that 
> > > IP = ICEXT(I(rdf:Property))
> > 
> > > [table:]
> > 
> > > x is in ICEXT(y) iff <x,y> is in IEXT(I(rdf:type))
> > > IC = ICEXT(I(rdfs:Class))
> > 
> > The last condition here, IC = ICEXT(I(rdfs:Class)), follows from 
> > the definition of IC and the assumption that I(rdfs:Class)
> > is in IC.  So this is not really a condition, and can be
> > stated before the table, in conjunction with the already
> > noted conclusion that
> >   IP = ICEXT(I(rdf:Property)).
> > In other words, IC = ICEXT(I(rdfs:Class)) is a true characterization
> > of the set IC, but not the original definition of the set IC.
> 
> Again, editorial, yes?

Under my interpretation of the definitions, this would indeed be
only an editorial addition, as I tried to explain above.

> 
> > Most of the next to last condition here,
> > x is in ICEXT(y) iff <x,y> is in IEXT(I(rdf:type)),
> > is implied by the definition of ICEXT.
> > One point that is not implied is the following:
> >   if <x,y> is in IEXT(I(rdf:type)), then y is in IC.
> > However, this is implied by two later conditions
> > listed in the table:
> > 
> > > rdf:type rdfs:range rdfs:Class
> > 
> > > If <x,y> is in IEXT(I(rdfs:range)) 
> > > [then x is in IP and y is in IC] and 
> > > [if, in addition,] <u,v> is in IEXT(x) then 
> > > v is in ICEXT(y)
> > (Between brackets [] I have made some additions which
> > seem to be implied here.  See separate remark below.)
> > 
> > Therefore, the condition
> > x is in ICEXT(y) iff <x,y> is in IEXT(I(rdf:type))
> > could be dropped from the table.
> > For clarity, I would add that the statement
> >   if <x,y> is in IEXT(I(rdf:type)), then y is in IC.
> > is implied by the table, in the way noted above.
> > 
> > ==
> > 
> > A consequence of the new setup of the RDF model theory
> > is that for each occurrence of IEXT(x) or ICEXT(x), it
> > should be clear that x is in IP or that x is in IC,
> > respectively.  For example, the semantic conditions
> > on subClassOf and subPropertyOf take care of this
> > explicitly.
> > 
> > In this connection, I would move the semantic conditions
> > > IC contains ...[many items]
> > > IP contains ...[many items]
> > to become the first conditions, as each of the other
> > conditions actually uses one or more of these 
> > conditions.
> > 
> > Note that IP is listed to contain I(rdfs:label) twice.
> > 
> > Note that IC is not listed to contain I(rdf:XMLLiteral).
> > This seems to be an error.
> > 
> > The semantic conditions on rdfs:range and rdfs:domain
> > do not yet incorporate an explicit domain assumption as just
> > discussed.  It seems that additions such as the following need 
> > to be made:
> > 
> > If <x,y> is in IEXT(I(rdfs:range)) 
> > [then x is in IP and y is in IC] and 
> > [if, in addition,] <u,v> is in IEXT(x) then 
> > v is in ICEXT(y)
> > 
> > If <x,y> is in IEXT(I(rdfs:range)) 
> > [then x is in IP and y is in IC] and 
> > [if, in addition,] <u,v> is in IEXT(x) then 
> > u is in ICEXT(y)
> 
> That seems substantive, but I'm not sure I understand
> the problem. Could you state it as an entailment test,
> please?

(There is a typo in the second item: it should be domain instead
of range.)

These are omissions, which seem to be a remnant from the April 2002 
version of the RDF MT, where the IEXT had all of IR as a domain.
In the current version, something needs to be added.
You cannot speak of IEXT(x) unless you assume that
x is in IP.
In both Peter's and my reading of the text, there should
be the additions "then x is in IP" and "if, in addition",
in both items.
In "my interpretation" of IC/ICEXT, the assumptions
"y is in IC" should also be added to both items.

So here the Last Call text has an inappropriate omission 
of a mathematical detail (a small error).
I cannot relate this to entailment tests.

> 
> > ==
> > 
> > Finally, not related to these IC/IP domain issues,
> > note that the rdfs:ContainerMembershipProperty condition
> > speaks of rdfs:Property instead of rdf:Property.
> > 
> > Herman ter Horst
> > 
> > [1]
> > http://lists.w3.org/Archives/Public/www-webont-wg/2003Jan/0426.html
> > [2]
> > http://lists.w3.org/Archives/Public/www-rdf-comments/2002OctDec/0096.html
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> 
> 
> 
Herman ter Horst

[3] http://lists.w3.org/Archives/Public/www-webont-wg/2003Feb/0179.html

Received on Thursday, 13 February 2003 06:05:45 UTC