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

RE: datatypes and MT

From: <Patrick.Stickler@nokia.com>
Date: Wed, 7 Nov 2001 09:47:26 +0200
Message-ID: <2BF0AD29BC31FE46B78877321144043114C070@trebe003.NOE.Nokia.com>
To: melnik@db.stanford.edu, jjc@hplb.hpl.hp.com
Cc: w3c-rdfcore-wg@w3.org

> > Charter:
> > [[[
> > Specifically, the RDF Core Working Group is not chartered 
> to develop a
> > separate data typing language that duplicates facilities 
> provided by XML
> > Schema data types
> > ]]]
> > 
> > XML Schema provides a mechanism for defining complex hence 
> we MUST use that.
> XML Schema provides a mechanism for defining complex 
> datatypes (it's not
> going to be easy to use such custom types defined by means of 
> XML Schema
> though). I referred to complex numbers, just as an example; to my
> knowledge, XML Schema does not define complex numbers.

I think it is very important that we keep distinct complex
data types and simple (anySimpleType) data types. Complex data types 
are built up of components which may be complex or simple
data types. Simple (anySimpleType) data types are value spaces 
for which an explicit lexical space is defined.

Thus, the issue of data typing of literals only applies to
simple XML Schema data types. Complex data types are no
different that assigning type to any other URI distinct
resource. Though one would wonder just how meaningful it
is to assign an XML Schema defined complex data type to
an RDF resource since an XML Schema complex data type
defines a sub-tree structure and not a knowledge structure
embodied in an RDF graph...

Thus, as much as it is meaningful or possible given the differences
between XML tree and RDF graph structures, RDF already fully "supports"
XML Schema complex data types as one can assign any type to any resource, 
and lexical issues are not of concern. 

The problems at hand have to do with consistent support of XML 
Schema simple types and their relation to literal objects.


Received on Wednesday, 7 November 2001 02:47:35 UTC

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