RE: Cutting the Patrician datatype knot

From: Peter F. Patel-Schneider (
Date: 12/01/01

PDU depends completely on the ability to have a unique datatype for each
syntactic literal construction.  If this can be done, then PDU will work,
otherwise it will not.

The first method, using rdf:type, works by itself, but only because of the
requirement that anonymous literal nodes have exactly one rdf:type.  This
is considerable change to RDF, requiring a completely new kind of
constraint on RDF syntax.  Moreover, part of this constraint does not have
any analogue in the semantics.

The second method, using rdf:range, has severe problems.  Suppose you
have the following

	age rdfs:range xsd:integer .
	age rdfs:range xsd:[string union integer] .
	john age "10" .

which is allowable under the new reading of rdfs:range.  Then you get the

	john age _:1 .
	_:1 rdf:value "10" .
	_:1 rdf:type xsd:integer .
	_:1 rdf:type xsd:[string union integer] .

which violates the condition in the first method.

There are two choices now.  Either disallow the second method, which
destroys the claim that PDU can capture P and P++ or allow multiple
rdf:type on anonymous literal nodes.  This second option, however, destroys
the very condition that allows the first method to work at all.

Moreover, how can PDU handle

	john age "10" .

as there is no type information available here at all?

The third method also works by itself.  It also works in conjunction with
the first method.  However, one example in the third method does not work,
as it results in a double-typed anonymous node.  The third method does not
work in conjunction with the second method.

So the PDU method is not general and only works in the presence of a
completely new kind of extension to RDF.


PS:  Why do I say that the single-type requirement is key?  Well consider
the following example

	john age _:1 .
	_:1 rdf:value "10" .
	_:1 rdf:type xsd:[string union integer] .
	_:1 rdf:type xsd:[integer union string] .

What is John's age here, 10 or "10"? 

Subject: RE: Cutting the Patrician datatype knot
Date: Sat, 1 Dec 2001 13:14:48 +0200 

> > -----Original Message-----
> > From: ext Peter F. Patel-Schneider 
> > []
> > Sent: 30 November, 2001 13:08
> > To: Stickler Patrick (NRC/Tampere)
> > Cc:;;
> >
> > Subject: RE: Cutting the Patrician datatype knot
> > 
> > 
> > OK.  Lets see how PDU handles various inputs.
> > 
> > Where is the definition of PDU?  When I get it, I'll try to 
> > come up with
> > some example inputs and how I think PDU behaves on them.
> > 
> > peter
> PDU is defined in
> The recently adopted short acryonym PDU is not mentioned there,
> but that's the most complete definition of the PDU approach and
> it is what I mean when I refer to PDU.
> Note that PDU is not new. In fact, its just the combination of
> the P proposal, the DAML idiom (viewed as a minor modification
> of the DC proposal), and the U idiom (URVs) as synonymous idioms
> defining the pairing of lexical form and data type -- and is also
> future compatible with the P++ proposal as noted in 
> Cheers,
> Patrick
> --
> Patrick Stickler              Phone: +358 50 483 9453
> Senior Research Scientist     Fax:   +358 7180 35409
> Nokia Research Center         Email:

This archive was generated by hypermail 2.1.4 : 04/02/02 EST