W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2001

RE: RDFCore Update

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Fri, 19 Oct 2001 07:57:48 -0400
To: Patrick.Stickler@nokia.com
Cc: devon@taller.pscl.cwru.edu, www-rdf-interest@w3.org
Message-Id: <20011019075748A.pfps@research.bell-labs.com>
From: Patrick.Stickler@nokia.com
Subject: RE: RDFCore Update
Date: Fri, 19 Oct 2001 13:35:23 +0300

> It is also important to note that, unless RDF itself defines
> a single, standard mechanism for data type validation, it can
> do nothing more than ensure that statements about data types
> do not conflict.

I don't see why.  There is no technical reason to prevent one defining RDF
as a functor over a type theory.  (For the ML-phobes out there, this means
that RDF would be somewhat like a function, with the formal parameter being a
type theory and the output being a version of RDF.)

Not that I'm particularly endorsing this view, but it is possible.


> Then it will be, *must* be, satisfied with that, since
> RDF does not define itself what "xyz:integer" is and
> cannot therefore test that "foo" is not an instance of
> that data type.

Yes, the result of the RDF Core WG would be like that, but if we think of a
possible datatype extension to RDF it is possible.  RDF(xyz) would use a
function from the xyz type theory to do the test.

> Thus, just as one may argue that "foo" is not an integer,
> it is just as out of scope for RDF as arguing that any
> statement is "false".
> The determination of true or false is outside the scope
> of RDF, right?

Where in the world did you pick this up?  It is the case that RDF is so
weak that no statement it says can be invalid, but that does not mean that
some extension of RDF could express invalid statements.  In particular,

  John age "Susan" .
  age rdf:range xsd:integer .

would be invalid in an XML Schema extension to RDF.

> We must employ higher layers to do that. In the case of
> typed data literals, we can use an XML Schema validating
> parser (or a portion of it), or some other data type
> checking layer, which knows what an "xyz:integer" is and
> can tell us if "foo" is one.

I know that some people have been expressing views that XML Schema
validation belongs ``above'' RDF, but I don't see how this can possibly
work.  Surely determining whether an entity is an integer or not is
something that we would like RDF to have access to.

> But RDF should not, and cannot care. An particular *system*
> will likely care, but not the RDF or RDFS layer explicitly.

Why not and why not?  RDFS certainly cares about the type of entities.  If
datatypes are not accessible to RDFS then rdfs:range will act rather

> Thus, at best, rdfs:range can only be prescriptive in the
> context of an explicitly locally typed value, and only
> insofar as the type URIs are compatible. Otherwise, it should
> be seen as primarily descriptive. Eh?

I come down firmly for the descriptive reading of rdfs:range.  I can see
that there are some reasons for having a prescriptive reading.  However I
can not image how a mixed reading would work.  (By the way, you may be
confusing descriptive and prescriptive above.)

> So I think that the RDF Core WG should focus on (a) clarifying
> just what RDF or RDFS actually define/constrain with regards to
> data type declarations, and (b) define the various equivalent
> means by which data type can be declared or inferred. But
> RDF should not, IMO, adopt an actual data type validation
> mechanism a'la XML Schema which can tell us if e.g. "foo"
> is an "xyz:integer" or not. That should be left to each
> individual data type scheme, and no particular data type
> scheme should have any special status over any other.

I suggest that the RDF Core WG is not chartered to do any datatyping.  My
concerns about datatyping with respect to the WG all center around the fact
that the way the WG was proceeding was precluding reasonable datatyping

> Cheers,
> Patrick

Peter F. Patel-Schneider
Received on Friday, 19 October 2001 07:59:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:32 UTC