W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2003

Re: response to issue pfps-09

From: pat hayes <phayes@ai.uwf.edu>
Date: Wed, 5 Feb 2003 19:17:40 -0600
Message-Id: <p05111b00ba676244cf42@[]>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: w3c-rdfcore-wg@w3.org

>From: pat hayes <phayes@ai.uwf.edu>
>Subject: Re: response to issue pfps-09
>Date: Wed, 5 Feb 2003 17:15:53 -0600
>>  >From: pat hayes <phayes@ai.uwf.edu>
>>  >Subject: Re: response to issue pfps-09
>>  >Date: Wed, 5 Feb 2003 13:46:11 -0600
>>  >
>>  >>  >From: pat hayes <phayes@ai.uwf.edu>
>>  >>  >Subject: response to issue pfps-09
>>  >>  >Date: Tue, 4 Feb 2003 17:49:00 -0600
>>  >>  >
>>  >>  >>  I believe that there is a missing part of datatypes in the RDF model
>>  >>  >>  theory, and, moreover, that this missing part makes 
>>datatypes unusable
>>  >>  >>  in RDF.  The missing part is a mechanism for tieing a URI 
>>reference to
>>  >>  >>  a datatype.
>>  >>  >>
>>  >>  >>  ----
>>  >>  >>
>>  >>  >>  The MT assumes that datatypes are defined externally to 
>>RDF, and that
>>  >>  >>  part of this defining process involves associating a 
>>uriref with each
>>  >>  >>  datatype which can be used as its 'name', ie the semantic assumption
>>  >>  >>  is that the denotation is defined externally.
>>  >>  >
>>  >>  >The MT provides mechanisms for communicating the lexical space, value
>>  >>  >space, and L2V map of these externally defined datatypes to datatyped
>>  >>  >interpretations.  However, it is lacking a mechanism for 
>>communicating the
>>  >>  >RDF ``name'' of the datatype to datatyped interpretations.
>>  >>
>>  >>  I think there are two issues here that I (we?) have been 
>>getting confused.
>>  >>
>>  >>  1. A D-interpretation should require that the denotation of a
>>  >>  recognized datatype uriref is a particular datatype, as a semantic
>>  >>  condition.
>>  >>
>>  >>  2. Some *mechanism* should be provided in the semantics document for
>>  >>  assigning or attaching the denoted datatype to the datatype uriref.
>>  >
>>  >It appears to me that 2 is part of 1.  If a ``recognized datatype uriref is
>>  >a particular datatype'' then it is surely the case that that 
>>datatype must be
>>  >somehow assigned or attached to the datatype uriref.
>>  Yes, somehow. But how, exactly, is not for the RDF WG to decide, 
>>seems to me.
>Why not.  Without this, how can I use datatypes?

You can use any datatype that has a uriref. We define the urirefs for 
the XML schema datatypes and the built-in datatype. You can do things 
like this yourself: go ahead, feel free. You could put up a website 
somewhere with definitions of your datatypes on it and tell the world 
to use appropriate fragIDs attached to the page's URL to identify 

I guess Im not sure what kind of answer you expect here. It sounds 
like you wanted us to give you a universal but also rigorously formal 
datatype-creating kit. But I have no idea how to do that, or even 
what it would really be like. I have the impression that the XML 
schema group tried valiantly to provide such a kit, but it wasn't 
easy and it's not universal. I think it would need work by a 
different *kind* of WG.

[Later: thinking this over, maybe one could do it in OWL (?? how to 
do the L2V mapping??) But then of course one would automatically have 
'given' the datatype a uriref, simply by using the uriref that one 
was using to describe it in OWL, right?]

>>  Look, RDF assumes that urirefs denote, and that's all it assumes.  If
>>  a uriref is being used to *name* something, ie if its denotation is
>>  supposed to be fixed somehow and publicly accessible, then this
>>  requires a process of baptism, of assigning a name to the thing
>>  named. I do not know how to do that, and you are saying that neither
>>  do you, and until there is such a process you don't know how to
>>  baptize a new datatype. Indeed, I agree, I don't know either. But our
>>  charter only requires us to incorporate the XML Schema datatypes, and
>>  we have baptised those.
>>  I think this larger problem - what are the appropriate protocols for
>>  achieving baptism on the Web - is more than the RDF WG can tackle. It
>>  is a larger and more comprehensive issue which impacts many other
>>  things than RDF.
>Well, why not just make RDF datatypes be four-tuples, instead of triples,
>adding a URI reference?  A D-interpretation would then be required to
>interpret the URI reference for datatypes as the datatype.  What is wrong
>with this?

Nothing wrong with it, except its beside the point. This puts the 
uriref in the semantic domain, but how does it make the same uriref 
used in the syntax *denote* the datatype?  Requiring the uriref to 
even be in the vocabulary is itself a semantic extension. We already 
require a recognized datatype uriref to denote an actual datatype (ie 
a thing satisfying the semantic conditions involving L2V); I don't 
see what extra is added by putting the uriref into the 
interpretation; after all, you can always quote its unicode string as 
a simple literal and refer to it that way if you really want to. And 
in any case, how would doing this provide you with a *way* to define 
a new datatype? We havn't got any vocabulary for specifying the 
lexical or value spaces, or the L2V mapping,  other than ordinary 
mathematics in a document somewhere; and we havn't got any APIs 
worked out for you to use to tell any software what they are supposed 
to be.  Just putting a uriref into a 4-tuple in a model theory 
doesn't *enable* you to do anything at all. Consider the difference 
between saying that my datatype is the 4-tuple <'some:uriref', 
whatever....>. and saying that my datatype is the 3-tuple 
<whatever...> and its name is 'some:uriref'. Seems like a toss-up to 

>>  [...]
>>  >  >
>>  >>  Right, this was always the intention, that if ex:foo is a recognized
>>  >>  datatype uriref, then there is some datatype x such that in any
>>  >>  D-interpretation I , I(ex:foo) = x. I should make that more explicit,
>>  >>  clearly.
>>  >
>>  >But which URI reference denotes which datatype?
>>  That is determined, presumably, by the agency which creates the
>>  datatype and describes it in some standards document, or otherwise
>>  publicises it. How is the meaning of any uriref determined? Im not
>>  sure what kind of an answer you were expecting here.
>>  >
>>  >What I want to be able to do in D-interpretations is
>>  >
>>  >1/ Create some datatypes, say octal and hexidecimal numbers.
>>  >2/ Be able to create typed literals that use these datatypes, for example
>>  >    "A"^^me:hexidecimal and "10"^^me:octal.
>>  >
>>  >I don't see how the current definition of D-interpretations gives me this
>>  >ability.
>>  I don't think it does, indeed. All it is is a model-theoretic
>>  semantics, not a universal datatype-defining system. In itself, it
>>  doesn't give you the means to *create* anything, all it does is
>>  define some semantic constraints to conform to.
>Then D-interpretations are pretty much useless.

I think they failed to live up to your very high expectations, but I 
never had those expectations, myself.

>>  >Without both of these, I don't see how RDF datatyping is useful.
>>  Well, it lets you use the XML schema datatypes and it provides a
>>  framework, or part of a framework, for future extensions.
>But then datatype extensions each have to be full-fledged semantic
>extensions to RDF, instead of being just instantiations of the RDF
>datatyping framework.

Yes, they do. I think this is inevitable, since each must introduce a 
new referring name. However, we do our best to give a general 
framework for specifying what might be called the 'schema' for such 
semantic extensions. Each one has to define an L2V mapping, its 
domain and range, and associate the datatype with a uriref., and 
that's all (in the MT.).

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@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam
Received on Wednesday, 5 February 2003 20:17:45 UTC

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