RDF Semantics: IC / ICEXT

RDF Semantics
Last Call version, 23 January 2003.

This comment was mailed earlier, in an earlier form, 
to the WebOnt WG [1].  This comment arose out of confusion 
about the definitions of IC / ICEXT in the WebOnt WG 
(compare the discussion on RDFS-compatible OWL semantics 
pointed to in [2]; compare also [3]).
In order to eliminate this confusion, this is a request 
for clarification of these definitions.

In an earlier email to www-rdf-comments [4]
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, and that ICEXT is defined 
with IC as domain.
For convenience I include below rather concrete suggestions
for extending the text further, in order to clarify the design that 
seems to be already expressed.

A central point is that in Section 3.3 the distinction between 
definitions and semantic conditions should be made more clear, 
in my view.

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 make the definition that is made here
more clear by introducing the symbol IC here with a displayed formula, 
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 this reference
to semantic conditions is not made, 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.
This sentence is confusing, since no mention is made here of the 
domain of ICEXT.  Definitions of ICEXT and IC were
just made before the table.

> Since I is an rdf-interpretation, this means that 
> IP = ICEXT(I(rdf:Property))

> [in the 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 by this definition
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 here which
seem to be implied.  See another remark I make today in a separate 
mail to rdf-comments.)

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, it seems to be appropriate to add that the 
statement (*) above is implied by the semantic conditions, 
in the way just noted.

==

In an alternative interpretation, the first two lines
in the tables in Section 3.3 defining rdfs-interpretations,
are interpreted as the definitions of ICEXT and IC,
with all of IR being the domain of ICEXT.
However, this alternative interpretation ignores the 
original definitions of IC and ICEXT, given already 
before these tables.  It seems that the first two lines
in these tables should be interpreted in the light of these
original definitions given just before, as I describe above.

It is not at all natural, moreover, to allow the introduction of
ICEXT(x) when x is not a class.

Another advantage of letting IC be the domain of ICEXT is that
more symmetry and simplicity and uniformity seems to be obtained 
in the RDF semantic theory, because of the analogy between IP/IEXT
and IC/ICEXT.

Herman ter Horst

[1] http://lists.w3.org/Archives/Public/www-webont-wg/2003Feb/0067.html
[2] http://lists.w3.org/Archives/Public/www-webont-wg/2003Jan/0426.html
[3] http://lists.w3.org/Archives/Public/www-webont-wg/2003Feb/0180.html
[4] http://lists.w3.org/Archives/Public/www-rdf-comments/2002OctDec/0096.html

Received on Friday, 21 February 2003 10:55:31 UTC