Re: RDFCore WG: Datatyping documents

I agree in general with Frank's approach, though I want to stress
that one of the proposals does not require any of this extra
machinery to capture all the required semantics -- and that we
should avoid the addition of any such extra machinery if it is
at all possible.

It is a side-effect of the "philosophy" about datatyping taken
by some proposals that such extra machinery must be created,
and I would consider that a mark against the overall acceptability
of such approaches -- given another approach that does the job
without the addition of extra URIs, vocabulary, etc.



On 2002-02-02 21:59, "ext Frank Manola" <> wrote:

> Sergey--
> I think we agree.  As long as we're talking about the XML schema
> datatypes *as datatypes*, we ought to be able to use the XML schema
> URIs.  But, as I said, when RDF Core introduces new concepts, it should
> label them using an RDF namespace.  I should have also added, "when RDF
> Core needs URIs for existing concepts that don't currently have URIs, it
> should create them using an RDF namespace".  That seems to be the case
> with things like the value spaces of XML schema types, as you noted with
> the example of  As you say,
> perhaps we should ask for these URIs to be created (or for permission to
> add them).  In the meantime, it seems to me that one way to proceed,
> from the "modeling" point of view, would be to define a set of RDF
> predicates (in an RDF namespace) which define our view of the "standard"
> relationships between XML schema datatypes and their value spaces,
> lexical spaces, and any other stuff we want to be able to name in
> RDF-level discussions.  So we would then be able to say that something
> like the following (inventing some names) holds:
> [XMLSchema#int]---RDFdatatypevalue_space--->[RDFdt#int.val]
> Here, we're preserving the meaning of the XMLSchema URL (it refers to
> the datatype concept defined in XMLSchema), but adding some additional
> information of our own that we happen to need (which we're always free
> to do, as long as we don't claim that XMLSchema defines it).  This
> approach could also be a way to define the "simple and normative
> mapping" that Uche Ogbuji suggested (at least, pending any action that
> the XML Schema folks might take to do this for us).
> --Frank
> Sergey Melnik wrote:
>> 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
>> 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
>> 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 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]
>> 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:
>>>>>> ata
>>>>>>> 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
>>>       voice: 781-271-8147   FAX: 781-271-8752

Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email:

Received on Sunday, 3 February 2002 05:07:36 UTC