RE: Reject change to rdf:value

> -----Original Message-----
> From: ext Dan Connolly [mailto:connolly@w3.org]
> Sent: 05 November, 2001 10:39
> To: Stickler Patrick (NRC/Tampere)
> Cc: w3c-rdfcore-wg@w3.org
> Subject: Re: Reject change to rdf:value
> 
> 
> Patrick.Stickler@nokia.com wrote:
> > 
> > > Well, if that were indicated by a decimal then the
> > > string "10" would do it, but if it were represented by an 
> octal then
> > > you need "12" and if you use a binary then you need 
> "1010". There is
> > > no way to say what THE value of rdf:value is for any particular
> > > integer, until you specify what datatyping scheme is being used.
> > 
> > No. Data type does not define lexical representation,
> 
> In the context of this WG, it does...

Yes. Quite right. I was meaning to say that the value space
of a given data type is not necessarily tied to a given
lexical representation, and thus, if we are intending to
use e.g. xsd:integer to refer to the value space, then we
must employ other mechanisms to address any lexical representational
qualities, such as base notation, as the value space defined 
by 'xsd:integer' has no dependencies on such things.

Of course, XML Schema *does* say what the lexical representation
of XML serialized content data must be which are supposed to
define xsd:integer values, and to that end, base representations
other than 10 are not allowed, so a base 2 (binary) value "1010" 
is an invalid xsd:integer lexical form and the serialization
<xsd:integer>1010</xsd:integer> is invalid.

So, perhaps the question is whether, in the RDF encoded knowlege 
base, are *both* the value space and the lexical constraints implied 
when one assigns the rdf:type of 'xsd:integer' to a given RDF literal?
If the answer is 'yes', then one is not free to employ other lexical 
representations and one must then either abide by the lexical constraints
as defined or define another data type which allows/supports the
desired lexical form. 

Now, we can define a taxonomy of data types which includes several
notational variants of a given value space, such as 

   integer
      hexInteger
      octInteger
      binInteger

etc.

But I think we will run into problems there. For e.g. 'hexInteger'
to be a subClass of integer, that (at least to me) implies that 
any valid hexInteger value is also a valid integer value, and is
a specialization of integer. Unfortunately, that is not the case
for either point. A hexInteger lexical form is not a valid integer
lexical form and a hexInteger is not a specialized form of integer
(as is e.g. a nonNegativeInteger).

Thus, I see the only reasonable solution being either to "toe the 
line" with regards to the lexical forms defined for a given data
type, or come up with a mechanism by which data types can be
declared as "equivalent" insofar as the value space is concerned
but not necessarily with regards to their lexical representations.

Thus what we then end up with is

   integer ~ hexInteger ~ octInteger ~ binInteger

Though that seems rather kludgy to me...

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Monday, 5 November 2001 04:27:42 UTC