- From: <herman.ter.horst@philips.com>
- Date: Tue, 11 Mar 2003 14:09:08 +0100
- To: pat hayes <phayes@ai.uwf.edu>
- 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.
This response extends my earlier response.
To repeat, clarity is indeed improved. Mentioning IC and ICEXT
in the sentence defining rdfs-interpretations in the way done now
is a definite improvement.
Going with your table-definitive policy, I would like to ask
two small further extensions to make things completely explicit.
A) In the first line of the table, add what is between []:
"[If x is in IR and y is in IC, then]
x is in ICEXT(y) iff <x,y> is in IEXT(I(rdf:type)) "
(Note that this is currently the only table condition where x and y
are not "introduced" in such a way.)
B) To keep the text preceding the tables completely consistent
with the tables, add:
[for x in IC]
before or after the displayed formula
"ICEXT(x) = {y : <y,x> is in IEXT((rdf:type))}
Herman
>
>-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 Tuesday, 11 March 2003 08:11:02 UTC