W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2002

Re: access to MT editors version

From: pat hayes <phayes@ai.uwf.edu>
Date: Wed, 6 Nov 2002 18:24:20 -0600
Message-Id: <p05111b26b9ef61ab0f95@[]>
To: "Jos De_Roo" <jos.deroo.jd@belgium.agfa.com>
Cc: w3c-rdfcore-wg@w3.org

>  > As might have been predictable, this is taking longer than I thought.
>>  In case anyone wants to start reading, Im keeping the current version
>>  (being updated by the minute) at
>>  http://www.coginst.uwf.edu/~phayes/RDF%20Model%20Theory_Oct_draft.html
>that's very good to read and I have no fundamental remarks
>just something that I don't understand in 3.4
>   If x is in D, then ICEXT(x) is the value space of L2V(x)
>so the class extension of a datatype x *is* its value space
>i.e. the range of L2V(x)
>then how could it be that we should take care
>   not to identify the value space of a datatype
>   with the class of its members

This came from some recent email with Henry Thompson about XML 
schema. XML schema has a very weird notion of 'value equality'. The 
same thing - the SAME thing - looks 'different' to XML depending on 
which value space you look at it 'through'. For example base64binary 
and hexBinary value spaces are both binary octet streams, and Henry 
says that we can say they are the same class with the same members, 
but XMLSchema insists that one of these things seen as a member of 
one value space is different from itself seen as a member of the 
other value space. So XML value spaces are not sets, ie class 
extensions. They are some other eldritch kind of entity, not known to 
set theorists or mathematicians, in some strange world of their own. 
I just thought I ought to caution users, that is all.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam
Received on Wednesday, 6 November 2002 19:24:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:18 UTC