Re: questions about rdfs:Datatype [Was: RE: Seeking normative definition of datatyping]

>  > From phayes@ai.uwf.edu Thu Dec  5 18:05 MET 2002
>>  Mime-Version: 1.0
>>  X-Sender: phayes@mail.coginst.uwf.edu
>>  Date: Thu, 5 Dec 2002 11:05:24 -0600
>>  To: Roland Schwaenzl <roland@mathematik.uni-osnabrueck.de>
>>  From: pat hayes <phayes@ai.uwf.edu>
>>  Subject: Re: questions about rdfs:Datatype [Was: RE: Seeking normative   
>>     definition of datatyping]
>>  Cc: www-rdf-comments@w3.org
>>
>>
>>  The direct answer to your question is that they would, or could,
>>  generate potentially infinitely many conclusions, formed by adding
>>  '.0' at the end and any number of leading zeros at the beginning, of
>>  the lexical string.
>
>That is what i figured ...
>
>
>>  Obviously it would be more practical to restrict
>>  the use of the rules to a mode where the number of conclusions
>>  generated were restricted.
>
>Sure
>
>
>>  For example, it would be fine, in
>>  practice, to always use them so as to replace any lexical form
>>  representing a decimal by its canonical form with all irrelevant
>>  zeros suppressed. Whenever there is such a canonical lexical form,
>>  restricting the rules so as to generate only that canonical form will
>>  always find identities in at most two steps.
>
>That one would be allowed to do...so why not suggest
>to procede that way (at least) in the xsd primitive case in RDF Sema?

Well, some WG members prefer to not mention canonical DTs at all. But 
yes, I think that a sentence or two might be helpful, particularly as 
this is marked informative.

>
>[By the way: Why RDF Sema stresses "primitive" as opposed to "built in"?]

That is just an editing bug, will fix.

Pat
-- 
---------------------------------------------------------------------
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 Thursday, 5 December 2002 18:13:49 UTC