Re: 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].

For the record, the editor accepts this as an editorial comment 
(concerning exposition), and has been trying to find a change which 
would satisfy Herman. So far the editor is having trouble 
understanding what the issue is, but will do his best to find a 
mutually satisfactory way of expressing the intent of the MT design. 
Further responses below.

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

Strictly speaking, ICEXT is *defined*, in the mathematical sense, in 
terms of IEXT; in fact, all the RDFS semantic constructions *can* be 
expressed purely in terms of IEXT and stated as constraints on the 
RDFS vocabulary. The text does not labor this point since it would be 
a rather lengthy mathematical diversion from the main purpose of the 
text, but it could be expounded in an informative appendix if this 
would be found helpful. (?)

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

The intention is that table entries are the formal semantic 
conditions, while surrounding text is expository. In section 3.3 
putting the tables first would render them very hard to follow, 
however, since they introduce quite a bit of new notation, so some 
exposition comes before the tables.

Perhaps it would help if this table-definitive policy were stated explicitly?

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

There is indeed an analogy, but to emphasize it too much could be 
misleading in that there is also a very basic definitional asymmetry.

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

The intention is only that this text is an expository introduction to 
help the reader follow the tables below.

>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))}.

This condition is stated directly in the tables, in this form, so I 
do not quite see the point of repeating it in the text.

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

I fail to see how not referring to the semantic conditions can 
improve clarity, when the point of the text is to expound the 
semantic conditions.

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

Right. But to re-state the ICEXT condition in this way would suggest, 
wrongly, that ICEXT had a similarly primitive status as IEXT does; in 
fact, ICEXT can be viewed as *defined* in terms of the meanings of 
rdfs:Class and rdf:type, stated using IEXT.

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

I will try to find a way to re-word this prose so as to remove the confusion.

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

The intention is that it is a condition; the 'definition' of ICEXT in 
the text is intended purely as an expository aid to the reader, not 
as a formal definition.

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

This equation is intended to be a definition of IC; or, if one 
prefers, as a semantic condition which fully characterises IC. (There 
is no distinction between these terms when stating a semantics, which 
is the intended point of the present phrasing "...can be understood 
as a definition..".)

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

Right, that was the intention.

>However, this alternative interpretation ignores the
>original definitions of IC and ICEXT, given already
>before these tables.

The text is not intended to be definitive, only expository. I believe 
however that the statements in the text are all accurate and can be 
derived from the conditions listed in the 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.

I do not know how to respond to this comment. If x is the object of 
any rdf:type assertion, then x *is* 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.

It is important (eg for OWL/RDFS layering) that RDFS allow for 
distinct empty classes. These entities are all in IC but may be 
outside the domain of ICEXT in an RDFS interpretation of a graph 
which makes no rdf:type assertions about them.

Pat Hayes

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


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Monday, 24 February 2003 11:38:51 UTC