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

Message-ID: <OFF453B947.F2B5D9B7-ON41256CDE.003AB906-C1256CE6.00486883@diamond.philips.com>

Date: Tue, 11 Mar 2003 14:09:08 +0100

To: pat hayes <phayes@ai.uwf.edu>

Cc: www-rdf-comments@w3.org

Message-ID: <OFF453B947.F2B5D9B7-ON41256CDE.003AB906-C1256CE6.00486883@diamond.philips.com>

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

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:15:20 UTC
*