Re: RDFCore WG: Datatyping documents

I agree with your point. The trouble of using those genuine XML
datatypes is that the XSD document introduces those URIs for datatypes
as a whole, which are some kind of complex abstract objects.
Specifically, datatypes are defined as 3-tuples, so that the URI like
http://www.w3.org/2001/XMLSchema#int effectively denotes a 3-tuple, but
not the value space or lexical space of the datatype.

Some datatyping schemes and idioms that are currently under
consideration require explicit identifiers for say value spaces. For
this reason, I introduced URIs like
http://www.w3.org/2001/XMLSchema#int.val in [1]. Using such URIs would
be "politically correct" only if the authors of the XSD spec assign them
explicitly the meaning we think they should carry - in fact, maybe we
(the RDFCoreWG) could ask them to do so, or they could authorize us? I
understand there is no written rule that prohibits us to define URIs in
the xsd: namespace (in fact, we would just give an explicit name to
something that's already defined in XSD). However, defining vocabulary
in someone else's namespace feels like setting up your own Web page on
someone else's Web server without authorization (I think DanC can argue
better for this cause).

It is still quite likely that RDF datatyping could do without new
vocabulary. For example, we could define the class extensions (CEXT) of
resources like http://www.w3.org/2001/XMLSchema#int as datatype mappings
(or sets of pairs). One could claim that by doing so we just give an RDF
interpretation for an existing concept, and not specify a new one...

Sergey

[1] http://www-db.stanford.edu/~melnik/rdf/datatyping/


Frank Manola wrote:
> 
> For the benefit of the uneducated among us, would you care to explain
> this a bit more fully?  To the extent that RDF Core truly introduces new
> concepts, it certainly should label them using an RDF namespace.
> However, if RDF wants to use values that have genuine XML datatypes
> (especially if those values are going to be represented in RDF's XML
> syntax), why should we not say "xsd:integer" rather than
> "rdfdt:integer"?  I'm not talking now about datatypes that are "sort of
> like" XML datatypes, but are really and truly XML datatypes (as is, I
> believe, what we're trying to do).  What's the point of having URIs if
> you have to invent new ones in order to refer to what is supposed to be
> the same concept from a different language?  Talk about a "chaos of
> namespaces and architectures"!
> 
> --Frank
>
> Sergey Melnik wrote:
> >
> > Janathan, Uche, DanC,
> >
> > thank you for identifying the problem (I do remember DanC's posting
> > related to grazing on someone else's grass ;)
> >
> > I'm going to replace xsd: by rdfdt: in the next revision of the
> > document.
> snip
> >
> > Uche Ogbuji wrote:
> > >
> > > > http://lists.w3.org/Archives/Public/www-archive/2002Jan/att-0131/01-RDF_Data
> > > > > typing.htm
> > > >
> > > > I am concerned that this document  element names into the XML Schema
> > > > namespace. It seems to me that concepts that RDFCore introduces should be
> > > > labelled by an RDF namespace. It seems to me that the XML Schema namespace
> > > > should be reserved for XML elements and URIs introduced by this WG.
> > >
> > > I agree with this, but I'd go farther.  I think that even though RDFCore is
> > > not chartered to come up with a new data typing scheme, that they should
> > > consider defining XSD data types using URIs under the control of RDFCore, and
> > > providing a simple and normartive mapping between these and the XSD data types.
> > >
> > > I think that given the current chaos of namespaces and architectures in the
> > > W3C, that this is the only safe approach for consistency *within* the RDF
> > > space.
> > >
> snip
> > > >
> > > > i..e. just don't call it "xsd:integer" rather "rdfdt:integer"
> > >
> 
> --
> Frank Manola                   The MITRE Corporation
> 202 Burlington Road, MS A345   Bedford, MA 01730-1420
> mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752

Received on Friday, 1 February 2002 18:33:49 UTC