W3C home > Mailing lists > Public > www-rdf-interest@w3.org > December 2001

RE: Cutting the Patrician datatype knot

From: <Patrick.Stickler@nokia.com>
Date: Sat, 8 Dec 2001 00:51:57 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B160B23@trebe006.NOE.Nokia.com>
To: tpassin@home.com, www-rdf-interest@w3.org

> -----Original Message-----
> From: ext Thomas B. Passin [mailto:tpassin@home.com]
> Sent: 01 December, 2001 10:36
> To: www-rdf-interest@w3.org
> Subject: Re: Cutting the Patrician datatype knot
> [<Patrick.Stickler@nokia.com>]
> > It appears to me to be a requirement for a data typing scheme
> > which must preserve the lexical forms. And because RDF does not
> > and IMO should not have native internal representations of values,
> > a pairing approach seems the most efficient for preserving the
> > data typing knowledge until applications can use it in the context
> > of their own internalized data typing schemes.
> >
> Seems to me that there are two parts to this discussion.  
> I'll try to break
> them out for clarity here.
> 1) Should the RDF processor (and the resulting graph, if 
> that's what gets
> built) understand the datatypes of the values, or should it 
> simply capture
> the string (and any datatype indicators that come with the value)
> representing the value?
> If yes, then the processor does not perform validation 
> against the values.
> The using application does this (or possibly the xml processor, if XML
> Schema datatypes end up being used).

Right. Interpretation (mapping of lexical forms to internalized values
in a given system) is the domain of the application, including a validator,
not an RDF parser/triples store.

> If no, then the RDF processor interprets the values.  But 
> then we get into
> the problem of the internal representation of the processor, 
> as Pat . S.
> mentioned.  Should the original literal value get reproduced 
> if the graph
> were to be re-serialized)?

We should definitely avoid having native, internalized data types
in the RDF graph. That is a gonzo huge can of worms. 

> 2)  Should the datatype of a literal value be represented by an RDF
> statement or by some other syntax?
> Whatever approach gets adopted, it needs to accomodate plain 
> strings with no
> assigned datatype.  This is needed to let people build RDF 
> structures by
> hand, and to allow the datatype to be omitted if it could not 
> be determined
> or were otherwise not needed.


We need three levels of data type definition (or lack thereof):

1. global: by which type is associated with all literal values
   of a given property

2. local: by which type is associated with a specific literal 
   in the graph

3. external: by which type of a literal is left undefined in
   the RDF space and left to a given application (presuming
   that it is defined by some other means than provided by 
   RDF, such as URVs or application specific knowledge not
   encoded by RDFS semantics)

The PDU proposal addresses all three levels of data type
definition (P=1, D=2, U=3 ;-) by providing a specific idiom
for each level and defining a common consistent interpretation
of data typing which is synonymous across all three idioms.



Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Friday, 7 December 2001 17:52:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:38 UTC