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

> -----Original Message-----
> From: ext Peter F. Patel-Schneider 
> [mailto:pfps@research.bell-labs.com]
> Sent: 10 December, 2001 10:09
> To: Stickler Patrick (NRC/Tampere)
> Cc: www-rdf-interest@w3.org
> Subject: 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.) 

But what you are then talking about is a specific RDF API, not RDF
itself. If a given RDF API wishes to execute the mappings of typed
literals (based on pairings defined by the RDF graph) and pass
canonical internalized representations of the values to applications
which share the same value space representations as the API, fine,
in fact, that would be expected, but that's not RDF. That's out of
scope insofar as how we are going to capture that data typing
knowledge in the RDF graph itself, in a way that is independent of
any data typing scheme or any particular representation used by
any given platform.

I will reiterate, RDF should not use XML Schema data types natively
in the graph.

> ...
> > 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.  

BINGO! RDF itself should not *have* datatypes. It should provide
a generic mechanism for allowing data types to be associated with
literals (or really, any resource).

The RDF Core WG is not tasked to add XML Schema data types to RDF, IMO,
but to provide a consistent, clear, and well defined means to use
XML Schema data types in a way that applications which are XML Schema
aware can recognize the typing knowledge and apply XML Schema 
mechanisms accordingly.

RDF should not have any native data types itself, and should be fully
neutral with regards to data typing schemes, supporting other schemes
as well as it supports XML Schema data types.

The PDU proposal accomplishes this fully, and is also the way folks
are doing data typing in RDF now. And it works.

Yes, you may wish to have API layers above RDF that make it easier
for certain types of applications to deal with typed literals, but
that is not what "data typing in RDF" should provide (IMMHO).

> All that it has are some
> unspecified conventions 

The point is to have them explicitly and officially specified.

> on passing information that may or may not be
> datatype information on to downstream applications.  

Exactly, because RDF cannot know what that "downstream" application
is, and what its internal data type scheme/representations are.

> Because 
> RDF does not
> understand the conventions no RDF document should mention them.

I don't follow your argument here.

> > 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.  

The point is for RDF to define a meaning for data types that is 
independent of specific knowledge about value space representations
or actual mappings -- leaving these to applications which "know"
about the data typing scheme in question.

It's no different than XML just capturing <p> and leaving it to
the application to know what that means.

For RDF, we're just saying something like

   <typedDataLiteral>
      <xsd:integer>10</xsd:integer>
   </typedDataLiteral>

but you could just as well have

   <typedDataLiteral>
      <foo:count>10</foo:count>
   </typedDataLiteral>

The PDU approach is actually analogous to the treatment that typed
literals recieve in XML. It's up to the application (possibly an
API) to interpret the data. We don't have

   <typedDataLiteral>
      10
   </typedDataLiteral>

which is just presumed to be an xsd:integer. I.e. XML itself does not
have built in data types. Why should RDF?
  
> 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?

The meaning will be explicit and consistent. It is similar to an
expression that is not evaluated, but which fully and unambiguously
denotes the value. Thus "2+5" is not actually the value '7' but
it unambiguously denotes that value. Likewise (Literal,DataType)
unambiguously denotes a value in the value space of a data type.
Where and when that "expression" is evaluated to achieve the value
is up to the application layers above the RDF graph.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Wednesday, 12 December 2001 08:36:09 UTC