RE: RDF speficiations (was RE: Cutting the Patrician datatype kno t)

From: Patrick.Stickler@nokia.com
Subject: RE: RDF speficiations (was RE: Cutting the Patrician datatype kno	t)
Date: Sat, 8 Dec 2001 00:51:30 +0200 

> > For example, for XML Schema, the interface could pass a pair like
> > <integer,10> or even <integer,"10"> instead of <decimal with 0
> > fractionDigits union string,"010">.  This would be much easier for
> > applications to handle than requiring them to understand all 
> > of XML Schema
> > constructed datatypes.
> 
> I believe this is very similar to what I am presently arguing, that data 
> typing insofar as RDF is concerned is simply capturing the pairing of
> lexical
> form and data type identifier, and that there may be various ways to
> do that, such as globally via rdfs:range or locally via an anonymous
> node with rdf:value and rdf:type values. 

Not at all.  I don't see how our approaches could be any more different.  

The description above talks solely about the interface between an RDF
systems and RDF applications, not about how the RDF system itself works.
However, the above interface requires that the RDF system pass only
primitive XML Schema datatypes to applications.  It thus *requires* that
the RDF system has some deep understanding of XML Schema datatypes.  (I
also argue that this understanding can be embodied in an XML Schema
datatypes implementation, which is called by the RDF part of the system.) 

[...]

> An application, when it needs to "deal with" a given value, should
> simply be able to obtain the pairing (if it is defined) and execute
> the mapping to the actual value in terms of that pairing.
> 
> A particular API could provide such mapping transparently, including
> support for several idioms, global and local.
> 
> And by sticking to just this pairing of lexical form an data type,
> we are able to support arbitrary data types in RDF, leaving the
> interpretation/mapping to applications which support/understand
> the particular data types in question.
> 
> Is this what you are also suggesting?

Not at all.

> If so, then it would seem that the only real question requiring
> resolution is which idioms should be used to define those pairings.
> We'd need at least one each for global and local typing, and the
> two current idioms in use (rdfs:range and DAML, as shown above) 
> seem to do the job. There are others that may be useful in particular
> contexts (e.g. U) and folks would be free to use them but they wouldn't
> be the "standard" idioms that conformant tools would need to support.
> 
> So, to recap:
> 
> Do we really need anything more than the definition of the
> pairing and at least two idioms for global and local definition
> of such pairings? I say no.

> Do we really want the MT itself to say whether the pairings 
> (xsd:integer,"10") and (xsd:integer,"010") actually denote the 
> same value or not? I think not.

> Or do we rather leave such questions up to applications that 
> "know about" the specific data types and is able to determine
> such things? Yes, definitely.

In this case RDF does not have datatypes.  All that it has are some
unspecified conventions on passing information that may or may not be
datatype information on to downstream applications.  Because RDF does not
understand the conventions no RDF document should mention them.

> We still need to work through some issues of class relations
> and the semantics of e.g. rdfs:subClassOf and rdfs:subPropertyOf
> with regards to data types (lexical vs. value spaces) but those
> are issues that will have to be addressed no matter what idiom
> is used to define pairings.

If you don't provide a meaning for datatypes, then you can't determine
how they interact with other parts of RDF, and thus there is nothing that
can be done.  

> Cheers,
> 
> Patrick


I really do not understand how it is possible to include in RDF something
whose meaning is explicitly not given in RDF.  How can this generate a
consistent definition of RDF?

Peter F. Patel-Schneider
Bell Labs Research

Received on Monday, 10 December 2001 10:09:10 UTC