- From: <herman.ter.horst@philips.com>
- Date: Thu, 10 Apr 2003 15:38:42 +0200
- To: phayes@ai.uwf.edu, www-rdf-comments@w3.org
Pat, 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 policy.) 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 ICEXT: 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. 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