RDF Semantics: presenting the definition of rdfs interpretations


Some time ago we had a long discussion on rdf-comments
on the question where to put the definition of IC and ICEXT [1].

You defended your "table-definitive policy", which
includes the definition of these items in the table in Section 3.3
of the RDF Semantics document.
I proposed to take the definition of IC and ICEXT before the
table.  Then, the table would become simpler, since it would 
not use new terminology, and there would be no forward reference.
(By the way, you never said why you wanted the table-definitive

At first I was happy with your adaptation of the table-definitive 
text, but I am afraid I now want to discuss the point further.
I have two excuses for this: 1) the definition of rdfs interpretation
is undoubtedly the most complicated thing in the RDF Semantics document,
so it is valuable to make it as simple as possible.
2) Peter Patel-Schneider pointed to an interpretation of the new editor's
version text which is clearly undesirable.  You said earlier that
you view IC and ICEXT as add-ons, and not (as fundamental as for example
IP and IEXT) as part of the definition of RDFS interpretation. 
However, the new 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 ...

allows the confusion that IC and ICEXT are part of the tuple 
that forms an rdfs-interpretation.

This view would be undesirable.  It would be simplest if 
each semantic extension of simple interpretations (rdf interpretations, 
rdfs interpretations, owl full interpretations, owl dl interpretations 
etc.) would still be the same kinds of 6-tuples, with more and more 
conditions being satisfied.
Otherwise, for example, the OWL semantics document
would need to reconsider each of the many uses of rdfs-interpretation.
And even within the RDF Semantics document the interpretation that
IC and ICEXT are part of an rdfs interpretation seems to lead to problems
of presentation.  For example, the rdfs closure lemma would
need a somewhat awkward reformulation: the Herbrand interpretation of the
rdfs closure of E (this is a simple interpretation - no IC and
ICEXT yet) is (subinterpretation of) an rdfs-interpretation of E 
(where did IC and ICEXT come from?)

In view of this, I propose something like the following simplification
of the text defining rdfs interpretations.  This is a slight adaptation
of text that was proposed by Peter.  The following text seems to be
make it completely equivalent to what is now in the editor's version 
(26 February), apart from the confusion about the position of IC and 

        An rdfs-interpretation of V is an rdf-interpretation I of (V union
        rdfV union rdfsV) which satisfies the following semantic 
        and all the triples in the subsequent table, called the RDFS
        axiomatic triples.  For convenience, and to make the semantic
        conditions easier to understand, 
        the set of classes IC is defined as
                IC = { y in IR | <y,I(rdfs:Class)> is in IEXT(I(rdf:type)) 
      and the function ICEXT from IC into the powerset of IR is
      defined, for each x in IC, as
                ICEXT(x) = { y in IR | <y,x> is in IEXT(I(rdf:type)) }.
        These definitions imply that
            IP = ICEXT(I(rdf:Property))
                IC = ICEXT(I(rdfs:Class)).

The other discussion of IC and ICEXT before the definition of 
an rdfs-interpretation could then (largely) be removed.
And the first and second conditions could be deleted from the table.
These changes would make the document somewhat shorter and the definition
of rdfs interpretations simpler: there would be no forward reference
anymore, and the table does no longer make use of any new terminology.

With this mail, I retract my previous reply [1], to which you have not
replied and which does not seem to have had effect on the editor's
version of the RDF Semantics document.

Herman ter Horst

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

Received on Thursday, 10 April 2003 09:44:18 UTC