- From: pat hayes <phayes@ai.uwf.edu>
- Date: Thu, 17 Apr 2003 12:38:57 -0500
- To: herman.ter.horst@philips.com
- Cc: www-rdf-comments@w3.org

> >Herman, while doing a hopefully close-to-final edit of the semantics >>document, and bearing in mind your concerns about the initial >>presentation of the material on rdfs interpretations in section 3.3, >>I now propose to simplify the introductory prose so as to avoid the >>misleading impression of giving duplicate definitions, and to clarify >>the point raised in your recent message, as follows. Please let me >>know if you would find this acceptable. >> >>Pat >> >>-------- >> >>3.3 RDFS Interpretations >> >>RDFSchema extends RDF to include a larger vocabulary rdfsV with more >>complex semantic constraints: >> >>RDFS vocabulary (table) >>rdfs:domain rdfs:range rdfs:Resource rdfs:Literal rdfs:Datatype >>rdfs:Class rdfs:subClassOf rdfs:subPropertyOf rdfs:member >>rdfs:Container rdfs:ContainerMembershipProperty rdfs:comment >>rdfs:seeAlso, rdfs:isDefinedBy rdfs:label >> >>(rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy and rdfs:label are >>included here because some constraints which apply to their use can >>be stated using rdfs:domain, rdfs:range and rdfs:subPropertyOf. Other >>than this, the formal semantics does not assign them any particular >>meanings.) >> >>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, and the set of all classes >>in an interpretation will be called IC. The semantic conditions are >>stated in terms of a mapping ICEXT (for the Class Extension in I) >>from classes to their extensions. The meanings of ICEXT and IC in a >>rdf-interpretation of the RDFS vocabulary are completely defined by >>the first two conditions in the table below. Notice that a class may >>have an empty class extension; that (as noted earlier) two different >>class entities could have the same class extension; and that the >>class extension of rdfs:Class contains the class rdfs:Class. >> >>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, called the RDFS >>axiomatic triples. >> >>(table) >>x is in ICEXT(y) iff <x,y> is in IEXT(I(rdf:type)) >> >>IC = ICEXT(I(rdfs:Class)) >>..... >> >> > >There is one thing missing from this. >Namely, it seems that it cannot be deduced from the formal definition >that the domain of ICEXT is IC. True, it cannot. See below. >This is stated in the informal >description >before the formal definition, but your rules say that these informal >additions should be removable from the spec. >Our extensive earlier interactions about this point (see [1]) led to >the previous editor's version text: >> An rdfs-interpretation of V is an rdf-interpretation >> I of (V union rdfV union rdfsV) *with a distinguished subset IC >> of the universe and a mapping ICEXT from IC to the set of >> subsets of IR*, which ...: > >However, this text led to Peter's misunderstanding that an >rdfs-interpretation >is something like a tuple (I,IC,ICEXT). It seems that this >misunderstanding >can be prevented by adding a period, as in the following proposal which >apart from this period is almost identical with your previous text >just cited: > > 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, called the RDFS > axiomatic triples. The semantic conditions are specified by means > of a distinguished subset IC of the universe, and a mapping ICEXT from > IC to the set of subsets of IR. > (table) > x is in ICEXT(y) iff <x,y> is in IEXT(I(rdf:type)) > IC = ICEXT(I(rdfs:Class)) > >With this addition, the formal definition of rdfs interpretations >is complete and explicit, and acceptable. Well then I will insert this sentence, if it makes you happy. With my reading, this makes formal difference to the model theory, however, and is simply part of the explanatory text. >With the extra sentence it follows, and therefore it does not need to be >stated explicitly, that in the first line in the table, x can only be >any member of IR, and y can only be any member of IC. > >(In order to explain the need for the additional sentence further, >note that the first line in the table implies >that x in ICEXT(y) implies y in IC, >> since the range of rdf:type is rdfs:Class >as you noted in your previous message [2]. >Indeed, we get the following deduction: > x in ICEXT(y) > <x,y> is in IEXT(I(type)) (first line in table) > type range class > I(type) in IP, I(class) in IC > <I(type,I(class)> in IEXT(I(range)) > y in ICEXT(I(class)) (semantic condition on range) > y in IC (second line in table). >However, this only shows that if ICEXT(y) is nonempty, then >y is in IC. If ICEXT(y) is not nonempty, then it is either >empty (and y is in IC) or it is undefined (and y is not in IC). >There is nothing in the table that implies that ICEXT(y) >is defined iff y is in IC. So this needs to be added to >make the specification completely precise.) I fail to see what you mean here by 'completely precise'. The model theory says that any interpretation which satisfies the conditions is an rdfs-interpretation; surely that is precise enough? The issue you raise isn't germane, since the case that you wish to exclude is an interpretation in which ICEXT is undefined on a member of IC; but this is semantically harmless. Consider an interpretation I with z in IC but ICEXT(z) undefined; and consider a similar interpretation I' in which ICEXT'(z) = { }. Now, I' and I make the same triples true for any vocabulary, so I see no reason to exclude one of them but not the other from consideration; on the other hand, if you wish to interpret the inserted sentence as ruling one of them out, I also have no problem with this interpretation. As a general methodological principle when giving semantic conditions, I prefer to state the semantic constraints as weakly as possible in order to get the right sentences come out true. >Even though in this way the text becomes acceptable, I must >admit that I would prefer my own proposal in [2], which puts the >formal definition of IC and ICEXT before the table. >In reaction to what you said in [2], > >>>( you never said why you wanted the table-definitive >>>policy.) >> >>Partly for aesthetic reasons, partly so that the entire MT can be >>captured unambiguously in equations by simply merging the tables. My >>own view is basically that an MT actually *is* a set of equations, >>strictly speaking, and the rest of the text is just commentary, >>introduction etc. for the benefit of various categories of human >>reader. But some readers can do best with simply the equations. > >I would like to say the following, to make my considerations >somewhat more clear: >The starting point of the MT is the definition of >simple interpretation: this gives the basic "meta-ontological" >construction, and is not described by means of a table. Good point, it should be. I will rectify that. >The tables on rdf interpretations, rdfs interpretations, and >datatyped interpretations list restrictions on this basic construction, >except for the first two lines of the table on rdfs interpretations, >which add two auxiliary items to the basic construction (IC and ICEXT). They also describe restrictions, since the new vocabulary is introduced respectively by an equation and a biconditional which make them obviously eliminable. >By the way, only three of the entries in these tables are literally >equations. That is true, I should not have used the word "equation" so loosely. Pat -- --------------------------------------------------------------------- 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 Thursday, 17 April 2003 13:39:01 UTC