W3C home > Mailing lists > Public > www-rdf-comments@w3.org > April to June 2003

Re: RDF Semantics: presenting the definition of rdfs interpretations

From: pat hayes <phayes@ai.uwf.edu>
Date: Thu, 17 Apr 2003 12:38:57 -0500
Message-Id: <p05111b0dbac47627c310@[]>
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.
>>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
>>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.
>>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
>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
>is something like a tuple (I,IC,ICEXT).  It seems that this
>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
>>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

That is true, I should not have used the word "equation" so loosely.


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

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