Re: RDF Semantics: corrections

>From: pat hayes <phayes@ihmc.us>
>Subject: Re: RDF Semantics: corrections
>Date: Tue, 13 Jan 2004 17:37:33 -0600
>
>>  >From: pat hayes <phayes@ihmc.us>
>>  >Subject: Re: RDF Semantics: corrections
>>  >Date: Tue, 13 Jan 2004 15:36:29 -0600
>>  >
>>  >[...]
>>  >
>>  >
>>  >>  For clarification, my question to you was concerned with the effects
>>  >>  on OWL rather than on RDF as such. I was not meaning to ask your
>>  >>  opinion on the change in a general sense: as indicated, I will take
>>  >>  responsibility for that. I was asking you only to give an opinion on
>>  >>  whether the suggestion made by Herman for a 'protective' modification
>>  >>  to the *text* of the OWL document is indeed sufficient to ensure that
>>  >>  the RDF and OWL specs, with these changes, will still be compatible.
>>  >>  The intention is that this will make no change to OWL itself.
>>  >
>>  >Well, you are really asking for us to approve both the change to RDF and
>>  >related change to OWL to insulate OWL from the effect of the change to
>>  >RDF.  From what I see about the changes I would vote against both.
>>
>>  No, any changes or otherwise to RDF will be the result of decisions
>>  made by the RDF WG.  What I was really asking your opinion of was the
>>  insulation device proposed by Herman.  There are three options:
>>
>>  1.  do nothing
>>  2.  this change is made to RDF and a textual 
>>edit in OWL insulates OWL from it
>>  3. This change is made to RDF and OWL is damaged as a result
>>
>>  I am anxious to avoid 3.  I know you prefer 1., but what I was really
>>  asking you is whether 2 is possible, or whether the choice is between
>>  1 and 3. If indeed that is the only possible choice, I will have to
>>  choose 1.  I myself would vastly prefer 2 to 1, and I think that the
>>  overall design will be better and will be more generally useful with
>>  2 rather than 1.  So I know you would vote for 1 given your druthers:
>>  but can you please tell me if, given the choice between 2 and 3,
>>  whether 2 is even an option?
>
>Well, if I was voting I would vote against 2.

Yes, I understand that. My question is, however, 
is 2 even possible? That is, I want to know if I 
(actually the RDF WG) am choosing between 1 and 
2, or will I (etc.)  be forced to choose between 
1 and 3? My (our) decision depends on the answer.

>
>>  >[...]
>>  >
>>  >>  The substantive change is that, as noted above, the class extension
>>  >>  of a datatype name is required to contain only the denotations of
>>  >>  typed literals in the vocabulary, rather than required to *be* the
>>  >>  value space of the datatype. This brings D-interpretations in line
>>  >>  with the way that XML typed literals are treated in the RDF
>>  >>  semantics, which imposes no explicit requirements on
>>  >>  ICEXT(I(rdf:XMLLiteral))
>>  >>
>>  >>  The only example I am aware of which makes the change visible is this:
>>  >>
>>  >>  ex:a ex:p "true"^^xsd:boolean .
>>  >>  ex:a ex:p "false"^^xsd:boolean .
>>  >>  ex:c rdf:type xsd:boolean .
>>  >>
>>  >>    |=?=
>>  >>
>>  >>  ex:a ex:p ex:c .
>>  >
>>  >What about
>>  >
>>  >ex:a ex:p "2"^^xsd:short .
>>  >
>>  >|=?=
>>  >
>>  >ex:a ex:p _:a .
>>  >_:a rdf:type xsd:int .
>>  >
>>  >I think that this is a valid {xsd:short,xsd:int}-entailment in the PR
>>  >version of RDF but would not be valid under the proposed change.
>>
>>  Hmm. It is hard to tell since the XSD specs seem to be ambiguous
>>  about whether or not value spaces of distinct datatypes are disjoint
>>  or not. 
>
>In this particular case it is even more clear than in the case of xsd:float
>vs xsd:int that the values spaces are not disjoint, as xsd:short is a
>restriction of xsd:int, and thus its value space is, by definition, a
>subset of the value space of xsd:int.

Ah, yes, I had not noticed that. OK, in that case 
I concede that one reasonable way to interpret 
the XSD spec in this case is that the value space 
is a true subset. However, these are the only 
cases, since there is an explicit prohibition (in 
section "4.2.1 equal") against any other 
equalities being considered true; and since other 
parts of the text of the document strongly 
suggest otherwise (for example the definitions of 
the value spaces of hexBinary and of base64Binary 
are both stated to be "the set of finite-length 
sequences of binary octets", yet these sets are 
required to be disjoint by section 4.2.1), the 
moral I draw from this text, one reinforced by 
subsequent discussions with members of the WG, is 
that it is using a notion of 'equality' and/or of 
'set' which does not entirely correspond to 
normal mathematical usage, and in any case is 
certainly open to reinterpretation: so I retain 
my preference for adopting a conservative notion 
of identity when it comes to formal semantics.

One merit of the proposed change is that it 
entirely insulates RDF D-entailment from the 
answers to such questions, in fact: D-validity 
would depend only on the lexical form of 
literals. I believe this is closer to the 
intentions of the XSD designers, since it is 
closer to the way that datatypes are used in 
programming environments, where questions about 
class extensions of datatypes rarely arise (and 
are in any case determined, when they do, by the 
particular language rather than by the XSD spec.)

>  > My best understanding of the intent of the XSD group (and
>>  what they were planning to make official in version 2, the last time
>>  I checked) is that those value spaces should be considered to be
>>  disjoint in the sense that their members are not identical, but that
>>  there is a relation called 'equality', distinct from the relation of
>>  identity, which holds between them.  (An alternative account of the
>>  situation was provided by Henry Thompson, who indicated that the best
>>  way to think of the elements of these value spaces is as pairs
>>  consisting of the value plus the datatype: rather like typed
>>  literals, in fact.)  Whether or not this 'equality' is the same as
>>  owl:sameAs, I leave others to decide.  I tend to assume that the
>>  safest thing for us to do in the semantics is to go with the most
>>  conservative possibility.  As far as the RDFS semantics is concerned,
>>  therefore, the value spaces of any two different XSD datatypes MAY be
>>  distinct disjoint sets, so your example is not a valid entailment on
>>  either the PR or with the proposed change.
>
>I totally disagree.  The normative documents for XML Schema are totally
>clear

The wording seems unambiguous, I agree, but 
unfortunately it seems just as unambiguous in 
other cases where it clearly cannot be 
interpreted in this way. Hence my enduring 
mistrust of what exactly was intended.

This discussion is slightly aside from the main 
point, but let me phrase it this way. Suppose 
some folk were having a debate about your 
example, using the PR RDF semantics.  A says that 
it is valid since the class extension of 
xsd:short is required to be a subset of that of 
xsd:int. B says that doesnt follow because it is 
possible to read the XSD spec in such a way that 
if a is of A and b of B, with A and B distinct 
built-in datatypes, then a =/= b, so 
interpretations exist in which the class 
extensions are disjoint. I would side with B, 
myself; but more to the present point at issue 
(the proposed change), I would prefer that the 
debate had never been allowed to arise in the 
first place, and that D-entailment was insulated 
from such questions as whether or not facets 
confer datatype identity: particularly since the 
relevant point at issue can be expressed directly 
in RDFS: so, rather than arguing about what is 
'true', what A and B ought to do is for each of 
them to be explicit about their assumptions, and 
then they will be able to, if not agree, at least 
be usefully explicit about what they are 
disagreeing about. If B asserts the relevant 
subclass relationship, then A will know what his 
assumptions are. They might disagree about the 
*need* to do this, since A could argue that it is 
obvious: but then, we all need to acknowledge the 
unfortunate necessity, when communicating with 
others, to be explicit about things that seem 
obvious to us.

>, particularly in this case, that the value spaces are not disjoint.
>(Note that this is a separate issue from whether a value typed as a short
>would validate as an int.)
>
>>  It would be valid if you also asserted
>>
>>  xsd:short rdfs:subClassOf xsd:int .
>>
>>  under either semantics.
>
>Well, yes, but so what?  For example what about switching xsd:short and
>xsd:int above?

So, if you want subclass relationships to be 
involved in your reasoning, you need to state 
your assumptions explicitly. That seems to me to 
be an eminently appropriate methodological 
conclusion for RDFS.

I fail to follow your point about switching.

Pat

PS. One point about the change which I guess I 
didnt make explicit is that SOME change is 
required: the text in the PR version is buggy, in 
a way that Herman identified (acting, as I 
understand it, on behalf of the Webont group, by 
checking the text extremely carefully). So 1. 
above should really say, rather than 'no change', 
'not this change'.

>
>>  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
>
>Peter F. Patel-Schneider
>Bell Labs Research


-- 
---------------------------------------------------------------------
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 21:23:24 UTC