RDF Semantics review: RDFS interpretations

RDF Semantics, version of 23 January 2003

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.

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.

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)

==

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