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


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. 
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).
By the way, only three of the entries in these tables are literally
equations.

Herman

[1] http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0494.html
[2] http://lists.w3.org/Archives/Public/www-rdf-comments/2003AprJun/0051.html

Received on Thursday, 17 April 2003 10:54:35 UTC