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

Re: n-triples for datatype values [was: Agenda for RDFCore WG Telecon 2002-10-18]

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Mon, 4 Nov 2002 09:41:20 +0200
Message-ID: <004001c283d5$90d42490$399316ac@NOE.Nokia.com>
To: "Tim Berners-Lee" <timbl@w3.org>, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
Cc: "Jos De_Roo" <jos.deroo.jd@belgium.agfa.com>, <w3c-rdfcore-wg@w3.org>



[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]


----- Original Message ----- 
From: "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
To: "Tim Berners-Lee" <timbl@w3.org>
Cc: "Jos De_Roo" <jos.deroo.jd@belgium.agfa.com>; <w3c-rdfcore-wg@w3.org>
Sent: 03 November, 2002 12:28
Subject: Re: n-triples for datatype values [was: Agenda for RDFCore WG Telecon 2002-10-18]


> 
> My problem is that rational cannot be handled as an optimization of any of 
> these others:  there are some values that rational can represent that 
> cannot be represented exactly by the others (e.g. 1/3). 

Right. Like

   "1/3"^^my:rational

which is a perfectly acceptable typed literal, and also a good example
of why we cannot be constrained to only XML Schema datatypes even though
we want to fully support them (as well).

>  (This was an 
> objection I had to XML schema datatypes, to which I never really received a 
> satisfactory response, but that's another story.)
> 
> This idea of only allowing "extended by standards body work" seems to me at 
> odds with the W3C's approach to extensibility in other areas.  In the case 
> of RDF, we're allowing that certain entailments may not be available if the 
> datatype mapping (lexical->value) is not understood by the software, but 
> the framework is still usable for applications that don't need to 
> understand those datatypes.  That seems like a good approach to me.
> 
> So, if in your software you see "foo"^^datatypeURI with some datatype URI 
> you don't understand, you just keep the whole thing together and treat it 
> as an opaque blob, equal to somne other instance of "foo"^^datatypeURI but 
> different from "bar"^^datatypeURI or "foo"^^someOtherURI.

Exactly. The core RDF MT should remain datatype agnostic and "ignorant",
allowing one to use any datatype whatsoever which conforms to rdfs:Datatype.

Patrick


> #g
> --
> 
> At 05:31 PM 11/1/02 -0500, Tim Berners-Lee wrote:
> >I think fixed in this case means "a small number extended by standards body
> >work",
> >rather than 'anyone can make a new one".  Interoperability at the atomic
> >datatype
> >level is important.  But maybe I am being near-sighted.  In languages like
> >python
> >it is important to have a very well-defined common set of atomic datatypes,
> >but the again the ability to make new ones is rather neat.
> >
> >I guess I could imagine the implementations of code for integer, real,
> >floating point
> >and rational arithmetic being handled as optimizations.
> >
> >Tim
> >
> >----- Original Message -----
> >From: "Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
> >To: "Jos De_Roo" <jos.deroo.jd@belgium.agfa.com>
> >Cc: <w3c-rdfcore-wg@w3.org>; "Tim Berners-Lee" <timbl@w3.org>
> >Sent: Friday, November 01, 2002 4:58 AM
> >Subject: Re: n-triples for datatype values [was: Agenda for RDFCore WG
> >Telecon 2002-10-18]
> >
> >
> > > At 01:31 AM 11/1/02 +0100, Jos De_Roo wrote:
> > > > > I feel that "^^", being syntactic, should only be usable with a
> > > > > fixed set of type URIs.
> > > >
> > > >that's indeed better
> > >
> > > I have a concern with that.  For example rational values as described in
> > > CC/PP.  I'm rather concerned that the type system would be closed.
> > >
> > > [later]
> > >
> > > Or does "fixed" in this context mean non-variable?  I have no problem with
> > > that.
> > >
> > > #g
> > >
> > >
> > > -------------------
> > > Graham Klyne
> > > <GK@NineByNine.org>
> > >
> 
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> 
Received on Monday, 4 November 2002 02:41:31 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:53:56 EDT