Re: RDF Semantics: presenting the definition of rdfs interpretations

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