- From: pat hayes <phayes@ihmc.us>
- Date: Tue, 13 Jan 2004 22:07:10 -0600
- To: Herman terHorst <herman.ter.horst@philips.com>, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
- Cc: jjc@hpl.hp.com, hendler@cs.umd.edu, schreiber@swi.psy.uva.nl, connolly@w3.org, sandro@w3.org, www-rdf-comments@w3.org, bwm@hplb.hpl.hp.com
Gentlemen, in trying to satisfy both of you I find myself in a dilemma, one which must be resolved in the very near future. Let me try to put the technical case as clearly as I can, in order to resolve this in time in a rational way. The issue concerns how to specify the class extension of a datatype name. Suppose x is a datatype, ie x=I(ddd) for some datatype name ddd. Clearly all well-typed literals "sss"^^ddd in the vocabulary V must denote something in the class extension. Herman wants this to be the only requirement. This handles literal checking, but it does not handle datatype clashes, since this does not rule out, say, the class extension of xsd:string from overlapping with that of xsd:int; so, as Peter pointed out, _:aaa rdf:type xsd:string . _:aaa rdf:type xsd:int . would be XSD-consistent; and this is not acceptable. So we need to extend this condition in some way so as to rule this kind of case out: in other words, if the value spaces are disjoint, then the class extensions must be disjoint also. (Peter's other examples involve subset relationships between value spaces, and in my view are more controversial: but the disjointness conditions must be retained.) One way to extend this is to require that the class extension of x be a *subset* of the value space of x. This seems to be the minimal extension which would handle datatype clashes appropriately. But now, the finite-value class examples give difficulties for completeness arguments, since now the 'boolean' example is rejuvenated: a p "true"^^boolean a p "false"^^boolean c type boolean |= a p c In order to block this, we would need to allow ICEXT(I(boolean)) to be a proper superset of the boolean value space. It can't be both a subset and a proper superset. Certainly, to abandon the datatype clash notion at this stage is not acceptable; and there seems to be little utility in requiring the subset condition without the identity condition (?); so my (reluctant) conclusion is that we should retain the semantic condition that ICEXT(I(ddd))= the value space of x, when <ddd,x> is in D. The other wording changes suggested by Herman can be retained, of course. The apparent mismatch between the treatment of rdf:XMLLiteral in RDF itself and as part of a D-interpretation can be accounted for by the observation that the difference is only visible when there is more than one datatype present, which can only happen in D-interpretations. Herman, do you agree with this decision? I can see no way around it. I know it hurts, but you are to consider that it may still be possible to state a general 'finite datatype' rule in order to achieve completeness; and that having 'extra' values in an interpretation is admittedly an inelegance, but does not of itself invalidate completeness (only make it more complicated to prove). Peter, thanks for being so stubborn. With this modification|2, no changes are now needed to any OWL documents. The revised RDF document can be seen at http://www.ihmc.us/users/phayes/RDF_Semantics_2004a.html http://www.ihmc.us/users/phayes/RDF_Semantics_2004a.html#defDinterp I have restored the elided text from section 7.4, amended the change log, and by the way fixed a couple of typos I noticed in the glossary. Brian, I will give you a decision on whether to ask the WG about 2004 or 2004a tomorrow at the latest, but I think 2004 a is the likely contender. Comments by tomorrow, please. After tomorrow, discussion has to be closed on this. 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@ihmc.us http://www.ihmc.us/users/phayes
Received on Tuesday, 13 January 2004 23:07:13 UTC