Re: RDF Semantics: IC / ICEXT

Pat,

Thank you for your replies to my messages.

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

Reading your comments, I noticed that the issue can perhaps best 
be described as consisting of two parts:
a) put definition of IC/ICEXT before the tables
b) what is the domain of ICEXT: IC or IR?
Here a) is entirely expository, and b) goes perhaps somewhat further.
I respond below to your separate comments.

In spite of the number of lines below, this is not a difficult issue.
In essence, I said everything I want to say about this
in 13 lines in a mail in November to rdf-comments [4]:
>- 3.3: The introduction of the set IC looks a little circular, 
>and can be made smoother (when I first read this, I had to stop 
>for some time at this point).
>Namely: the mapping ICEXT is defined from classes to extensions
>(so the set of classes IC is assumed to be already there, although 
>it is not explicitly specified) and subsequently, in the table, 
>IC is described in terms of ICEXT.
>In my view, the going would become smoother when the explicit 
>definition of IC,
>  IC := {x in IR : <x, I(rdfs:Class)> in IEXT(I(rdf:type))},
>is given before the definition of 
>  ICEXT : IC -> P(IR)
>given in the text.
Upon this comment you added the sentence
"Classes are defined to be things of type rdfs:Class." 
to the document, and I concluded, somewhat prematurely, that the 
problem I had was solved.

>
>>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. (?)

It is entirely clear that ICEXT is mathematically defined in terms of
IEXT.  In my view, a separate appendix that shows that one can work
without ICEXT would not be very helpful.  ICEXT is a very useful 
function.

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

The tables are indeed hard to follow because of the new notation.
Looking more closely, it turns out that the only new notation used
in these tables is  IC / ICEXT. 
It seems most natural to me to define formally before the table
what this notation means, so that no further explanation needs
to be given about the tables before the tables:
The tables then explain themselves, since they do not use new notation.
The data summarizing an rdf-interpretation (IR, IP, IEXT, IS, IL)
of a vocabulary that includes rdfs:Class, can be extended before
the tables in a well defined way with IC and ICEXT.
In this way, clarity would be very much improved.

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

I am surprised to hear about this table-definitive policy, and
find it confusing that the formal definition of the new notation 
(IC/ICEXT) is weaved together with conditions in this way, in the table. 
For example, there is not really room in the tables to say what 
the domain and range of ICEXT are, as would be required in a complete
and explicit formal definition of this function.
Therefore, I interpreted the text before the table as the definitions
of IC/ICEXT.

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

The asymmetry is clear: ICEXT is defined in terms of IEXT.
IEXT is the basic item, ICEXT is only a (very convenient) add-on.

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

See my remark above: I would prefer the definition of the as yet
undefined items (IC/ICEXT) formally before the tables, so that
the tables become clearer.  Then, the reader of the tables
does not need to go back and forth between table and exposition
before the table.

Something like the following could be a way to introduce IC:

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

No, it is not stated in this form there: the table describes IC by 
means of ICEXT.

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

This reference to the semantic conditions introduces a circularity in
the text.
When the definitions of new terminology are described before the tables,
everything is easier to read, in a linear fashion.

Something like the following could be the introduction of 
the function ICEXT:

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

ICEXT is defined in terms of IEXT here, so I do not see this.

>fact, ICEXT can be viewed as *defined* in terms of the meanings of 
>rdfs:Class and rdf:type, stated using IEXT.

This is exactly what I also tried to do.

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

There is no need to say something indirect like "can be understood
as a definition" or "is intended to be a definition" or
"a semantic condition which fully characterizes" or
"expository aid to the reader"
when the definition is simply given, directly and completely
and formally, before the tables.

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

It is a surprise to me that the domain of ICEXT is intended
to be IR.  See my next comment

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

The text before the tables says that the function ICEXT is
defined "from classes to their extension", where classes
"are defined to be things of type rdfs:Class", and where
"ICEXT(x) = {y : <y,x> is in IEXT(I(rdf:type)) } "

In this way I read that the domain of ICEXT is IC, the set of 
classes, and not all of IR.
And since this came before the tables, I interpreted
the first line of the table
  x is in ICEXT(y) iff <x,y> is in IEXT (I(rdf:type))
as applying only to y in IC (and x in IR).

Since the "table-definitive policy" is not stated explicitly
in the Last Call version of the RDF Semantics document, it
seems that, strictly speaking, making IR the domain of ICEXT
would be a change to the Last Call design.
(I said more or less the same earlier in [3].)
Even if it is the "intent of the MT design" to make IR the
domain of ICEXT, this is not made explicit in, and seems to
contradict another statement in, the Last Call document.
The difference is not dramatic, but there is a difference.

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

What I meant here is that, since ICEXT is a function "from classes 
their extensions" (quote from your document), ICEXT(x) makes sense 
only when x is a class, i.e., when x is in IC, i.e., when IC
is the domain of ICEXT.

>If x is the object of any rdf:type assertion, then x *is* a class.

Yes: this follows from the axiomatic triple
  rdf:type rdfs:range rdfs: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 

Yes: they are classes and therefore in IC

>outside the domain of ICEXT in an RDFS interpretation of a graph 

I do not understand this: the domain of ICEXT at least includes IC, 
so would include these empty classes.

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

Received on Wednesday, 26 February 2003 11:14:20 UTC