- From: pat hayes <phayes@ai.uwf.edu>
- Date: Wed, 26 Feb 2003 17:04:09 -0600
- To: herman.ter.horst@philips.com
- Cc: www-rdf-comments@w3.org
>Pat,
>
>Thank you for your replies to my messages.
--------------------
Herman, after reading all through this carefully, I altered the prose
and tables in the relevant section so as make the main points clearer
and state things slightly more formally. Please don't bother to
respond to the following point-by-point, therefore, but check the
current editor's draft.
I'll send the rest of the message in any case to make my intentions
slightly clearer.
-Pat
---------------------
>
>>>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:
Right, I will try to keep these separate.
>a) put definition of IC/ICEXT before the tables
>b) what is the domain of ICEXT: IC or IR?
On reflection, my earlier response to you on (b) was misleading. It
is more correct to say that the domain of ICEXT is IC, indeed. I
apologize for causing this confusion. further comments below.
>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.
Im sure it is not. Regarding the expository point (a), I have to say
that I am still not quite able to discern what the issue actually is.
The ordering of items in the tables is not supposed to be of any
significance (other than clarity to the reader). The semantics
consists of a large number of conditions all of which are required to
hold, and an interpretation is any structure which satisfies them
considered conjointly; so writing the conditions in a different order
does not affect the model theory.
As a related point, there really is no distinction between
'definition' and 'semantic condition'. The "definition" of ICEXT
given in the test is purely an expository aid to comprehension, not a
definition in the mathematical sense. I believe the prose makes this
clear, by using phrases such as "could be viewed as" and so on. It
was deliberately written in this way in order to avoid giving the
reader a false impression of its being definitive. You seem to have
read it differently, and most of your comments concerning IC and
ICEXT arise from this mis-reading.
To reiterate, my intent when writing the document was that the formal
conditions would be listed in tables and surrounded with expository
text. It should be possible in principle (I do not recommend it) to
elide all the prose but the tables and still reconstruct the entire
model theory. So to have a critical definition in the prose but not
in a table would be inappropriate.
>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 that case, I do not understand what point you were making in the
earlier messages included above. What did you mean by 'circularity',
for example? How can a conjunction be circular?
>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.
OK, thanks for letting me off that hook :-)
>
>>
>>>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
I have read the above several times and I am unable to make it come
out consistently. Are you urging that the explanatory definition
should be given before the tables or that it should not?
I am not willing to have the meaning of the tables depend on any
formal definition given in the surrounding text. At present, the
tables summarize all the actual conditions on an interpretation:
anything satisfying all these conditions is an RDFS-interpretation.
>:
>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,
Apparently I should state it explicitly. The section in question begins
"An rdfs-interpretation of V is an rdf-interpretation I of (V union
rdfV union rdfsV) which satisfies the following semantic conditions
and all the triples in the subsequent table.."
which is intended to be understood fairly strictly.
> 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.
BUt there is no distinction between formal definition and condition,
as I said earlier. Strictly speaking, IC is never 'defined'; it is
introduced as part of an RDFS interpretation and conditions are
imposed upon it. In this particular case, the conditions restrict it
so tightly as to render it eliminable in favor of IEXT, I(rdf:type)
and I(rdfs:Class), but that really isn't a formal part of the MT
conditions themselves, more an observation about them.
>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.
the 'iff' in the condition
x in ICEXT(y) iff <x,y> in IEXT(I(rdf:type))
defines the domain and range implicitly. Perhaps it would be clearer
if these were stated explicitly, however.
>Therefore, I interpreted the text before the table as the definitions
>of IC/ICEXT.
The text says "the first semantic condition in the table below
amounts to the following definition of this mapping ...".
Isn't it clear that this is not a formal definition, but rather an
explanation of the table entry?
> >
>>>
>>>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.
I would not be happy with this kind of presentation.
>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.
Yes, but it also says (in the same box of the table) that
x is in ICEXT(y) iff <x,y> is in IEXT(I(rdf:type)).
Putting this with
IC = ICEXT(I(rdfs:Class))
it is a single substitution to get
x is in IC iff <x,I(rdfs:Class)> is in IEXT(I(rdf:type))
which is a direct transcription of your version above.
> >
>>>
>>>> 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.
There is a forward reference, yes. But to avoid this requires putting
the exposition after the tables, which rather detracts from its
expository role.
>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.
BUt I want it to be the case that the tables contain the actual,
precise, formal conditions in a self-contained form, independently of
any surrounding exposition.
>
>>
>>>
>>>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
Allow me to explain. In one sense, all the semantic functions apply
to all of IR. Some of them, as a result of the various conditions
imposed on them, in fact only take arguments in some subset of IR.
ICEXT is such a case. So I think we have been at cross purposes,
hence your surprise.
The technical point here is that there is no semantic reason why IC
should not be all of IR, ie everything can be a class. 'IC' and 'IR'
are merely names for sets; they have no intrinsic meaning outside the
model theory itself. So speaking purely mathematically, the domain
can be all of IR. Put another way, nothing in the model theory
requires that anything is outside IC.
However, it would do no harm to state explicitly that the domain of
ICEXT is IC, if you feel that would be helpful.
> >
>>>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.
It is IC, in this sense. IC might be 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).
True, but this follows from the semantic conditions themselves, so
does not need to be stated independently.
>
>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.
I believe that it has always been the case that the semantic
conditions have entailed that ICEXT is defined on all classes, and
that anything which is a value of an rdf:type must be a class.
Allowing classes which are not values of rdf:type was a change made a
few versions ago but that has been stable for some time. So all of
this discussion has been a matter of exposition rather than a change
to the design.
>
>>
>>> 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.
Right, but it follows from the first condition on ICEXT and the
axiomatic triple
rdf:type rdfs:range rdfs:Class .
that anything with a class extension *must* be in IC. So I do not
know what it means to speak of the 'introduction of ICEXT(x) when x
is not a class'. If ICEXT(x) is introduced, then x must be a class.
>
>>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 .
Yes, quite. We seem to be going in circles here. You are agreeing
with what I say but complaining that I'm not saying things correctly
(??)
>
>>
>>>
>>>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.
Yes, forgive me, I was confused there for a second. (I was forgetting
the distinction between an x for which ICEXT is not defined versus an
x with ICEXT(x) = { } )
Pat
>
>>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
--
---------------------------------------------------------------------
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 Wednesday, 26 February 2003 18:04:17 UTC