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

Re: response to issue pfps-09 (second try)

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Wed, 05 Feb 2003 15:42:28 -0500 (EST)
Message-Id: <20030205.154228.36400892.pfps@research.bell-labs.com>
To: phayes@ai.uwf.edu
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 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.

> I agree with 1, but have been arguing against 2. I thought you were 
> arguing for 2, but I now suspect that you are in fact arguing for 1. 
> It was my understanding that the current document actually specified 
> 1.  already, but on reading it carefully I see that it is implicit
> (in the text: "Urirefs which denote recognized datatypes are required 
> to have the same denotation in all D-interpretations, so recognizing 
> a datatype amounts to fixing the meaning of a uriref. ") rather than 
> explicit (in some equations), so I propose as a purely editorial 
> change to make it explicit. To emphasize, this is not a change to the 
> intended MT, only an editorial (expository) change to make the 
> intended meaning clearer.
> So if you were arguing for 1., then yes, and moreover that was always 
> the intention, so I will try make this clearer, see below.  If 
> however you wish to argue for 2 above, then we are in for a longer 
> argument.
> >  > I feel that this is
> >>  entirely appropriate for a semantic specification, and that the
> >>  general issue of how meanings can be associated with urirefs is
> >>  beyond the scope of this WG.
> >
> >I disagree.  Datatyped interpretations need to know which uriref denotes a
> >datatype. 
> >
> >In the absence of this connection in a datatyped interpretation, the only
> >way to make datatyped interpretations useful in the model theory is to
> >create semantic extensions that provide for the connection.  Thus any
> >useful theory of datatypes will be a semantic extension of datatyped
> >interpretations, just as RDFS is a semantic extension of RDF (but on a
> >considerably smaller scale).
> >
> >>  A more practical answer to this comment is that the inference rules
> >>  for datatypes each specify a certain kind of information about the
> >>  datatype, and clearly state that the rule can be applied only when
> >>  that kind of information is somehow made available to an inference
> >>  engine. Since the use of urirefs as URLs which provide access to APIs
> >>  is well established on the Web, this seems to provide an clear guide
> >>  to implementers as to how to proceed.
> >
> >Sure, if I want to create a datatyped version of RDF, I know how to
> >proceed.  I define my datatype, say octal integers <O,V,L2VO>, and say that my
> >datatyped version of RDF has this datatype.  I also need a semantic
> >constraint that says something like
> >	IS(my:octal) = <O,V,L2VO>
> >I thus have created not a form of D-interpretation, but a semantic
> >extension of a D-interpretation.  Without this semantic extension, my
> >datatype is useless, as there is no way of determining that
> >	I("10"^^my:octal) = 8
> >
> >However, if RDF datatypes included information about their ``name'', and
> >this was made part of D-interpretations, then I could just say that my
> >datatype was <my:octal,O,V,L2VO> and then D-interpretations that included
> >this datatype would have
> >	I("10"^^my:octal) = 8
> >without the need for any semantic extension.
> 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?

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.  Without both of these, I don't see how RDF datatyping is useful.

> Pat

Received on Wednesday, 5 February 2003 15:42:38 UTC

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