Re: RDF Semantics: presenting the definition of rdfs interpretations

As I describe below, there was some misunderstanding on my part - 
apologies.

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

It seems that it should be in the formal text - I comment further on 
this below.

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

By completely precise I mean that the function ICEXT is specified
completely, that is, that its domain is given, its range, and that
its value is defined for each element of its domain.
Without such a complete specification, there is an inconsistency
between with the corresponding statement in the explanatory
text before the table.

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

I believe that there is a technical advantage of ruling the first
interpretation out - in proofs you do not need to distinguish these cases,
you can be more specific about ICEXT.

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

In fact, I meant this differently.  Apparently, I still did not
understand completely what you mean by 'table-definitive policy'.
I thought that the tables contain a large part of the semantics
spefication - listings of semantic conditions etc. - and that
several of the sentences outside the tables are also vital
parts of the complete semantic specification.

It is good that you make the policy explicit now with the next, new
sentence before the new, first table:

>Throughout this document, precise semantic conditions will be set 
>out in tables which state semantic conditions, tables containing 
>true assertions and valid inference rules, and tables listing 
>syntax, are distinguished by background color. 
Here a small correction should be made: , ? are ...
>These tables, 
>taken together, amount to a formal summary of the entire semantics.

You state that all the text except the tables could be deleted, because
it is only explanatory.  In several comments below, I try to take this
literally. The tables, without the surrounding text, should be 
understandable on their own.  I believe that some more 
editing would be needed to make this consistent throughout the document,
to make the tables really complete and understandable on their own.
It seems that some more information needs to be moved to the tables.
Note that the new, first table starts, *in the table*, with the
words "A simple interpretation I of a vocabulary V is defined by ...".
This is an essential part of this table: without these words, the
table would be incomprehensible.

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

Would it be correct to say that the tables
can readibly be extended into complete, English/mathematical sentences
that together define the entire semantics?

Several editorial changes would be needed to make this completely
consistent:
The table in Section 1.4 would for example need the addition that 
I is a simple interpretation.
In Section 3.1, to be consistent with this, the sentence preceding the 
table 
should be put in the table: "An rdf-interpretation of a ..."

In the light of this, to come back to our discussion point, it seems that
in Section 3.3, the following sentence and something like the second
sentence should be put *in the table*, to make this table on its
own a complete specification of what is an rdfs interpretation:
   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.

The repetition that you mention in your next mail [1], could then
be prevented by changing one or more of the symbols in the corresponding
sentence in the preceding, explanatory text back to words.

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

Herman

[1] http://lists.w3.org/Archives/Public/www-rdf-comments/2003AprJun/0070.html

Received on Wednesday, 23 April 2003 12:12:23 UTC