RE: Cutting the Patrician datatype knot

> -----Original Message-----
> From: ext Peter F. Patel-Schneider 
> [mailto:pfps@research.bell-labs.com]
> Sent: 01 December, 2001 08:44
> To: Stickler Patrick (NRC/Tampere)
> Cc: ashokma@microsoft.com; www-rdf-interest@w3.org;
> joint-committee@daml.org; w3c-rdfcore-wg@w3.org
> Subject: RE: Cutting the Patrician datatype knot
> 
> 
> 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.

I'm not sure I fully understand what you mean here. If you
mean that each data type defines its own value and lexical
spaces and the mapping from lexical to value space, then 
yes, but I think that's the basic definition of a data type
defined by XML Schema.

Perhaps you should leave URVs out of the question and
only consider the P (rdfs:range) and DAML (rdf:type+rdf:value)
idioms for global and local typing respectively.

> 
> The first method, using rdf:type, works by itself, but only 
> because of the
> requirement that anonymous literal nodes have exactly one 
> rdf:type.  

There is no such requirement. There can only be one value, yes,
but there can be more than one type.

The PDU proposal is based on pairings of lexical form to 
data type, not on a particular idiom. If one has e.g.

   x ex:property _:1 .
   _:1 rdf:value "10" .
   _:1 rdf:type xsd:integer .
   _:1 rdf:type foo:count . 
   _:1 rdf:type scm:number .
   _:1 rdf:type bar:byte .

then you have four pairings defined

   (xsd:integer,"10")
   (foo:count,"10")
   (scm:number,"10")
   (bar:byte,"10")

Likewise, one could define multiple pairings via rdfs:range
or a combination of rdf:type and rdfs:range.

The determination of whether those type declarations are
compatable is beyond the scope of RDF. One would presume
that they are, and the different type declarations could be
for the benefit of different systems that understand
different data type schemes where (fortunately) the types
share a common lexical space and mapping to value space.

Though, I'd recommend a more refined approach using
rdfs:subClassOf or similar relations.

But the point is that a given literal node can have multiple
types associated with it.

> This
> is considerable change to RDF, requiring a completely new kind of
> constraint on RDF syntax. 

Eh? Firstly, I don't see any considerable change, even *if* it
restricted literal nodes to a single type (which it doesn't)
and the who *point* of the PDU proposal is to avoid any change
to the RDF syntax, so I really don't know what you mean here.

> Moreover, part of this constraint 
> does not have
> any analogue in the semantics.

There is no such constraint. No conflict with 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
> following
> 
> 	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.

No violation, as there's no such condition for a single type.

The above defines two pairings

   (xsd:integer, "10")
   (xsd:[string union integer], "10")

Which of these an application uses, or whether they constitute a
contradiction or other problem with the knowledge, is not IMO
RDF's concern. RDF has provided the knowledge to the application
in a consistent and explicit manner and the application has to
make whatever sense of it that it can.

No problem (at least for RDF using the PDU proposal).
 
> Moreover, how can PDU handle
> 
> 	john age "10" .
> 
> as there is no type information available here at all?

PDU does not demand that data typing be defined, only that
if it is, it is done via specific "blessed" idioms and has
a consistent interpretation.

If you have a literal with no assigned data type, then it is
up to the application to decide what, if anything, it will do.

But this is the case with *all* of the datatyping proposals
presently on the table, no?
 
> So the PDU method is not general and only works in the presence of a
> completely new kind of extension to RDF.

Not at all. In fact, the PDU method is the most true to the 
present idioms and practices in use right now! It is clear
that you have not understood the PDU approach if you see it as
anything "new".

> 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"? 

Good question, and one that an application is going to have
a tough time figuring out, but how does any other data typing
proposal offer any kind of solution to this?

RDF does and should permit one to create broken knowledge.

Contraditions and ambiguity is a reality of the SW. It is
not PDU, or any data typing scheme, that is the cause of
the above ambiguity.

Don't think that the S proposal avoids this. It doesn't, as
it doesn't preclude the use of rdfs:range, and therefore,
one can associate any arbitrary number of types to any
literal. This is a problem that all data typing proposals
face and cannot escape.

Eh?

Cheers,

Patrick


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

> 
> 
> From: Patrick.Stickler@nokia.com
> Subject: RE: Cutting the Patrician datatype knot
> Date: Sat, 1 Dec 2001 13:14:48 +0200 
> 
> > 
> > 
> > > -----Original Message-----
> > > From: ext Peter F. Patel-Schneider 
> > > [mailto:pfps@research.bell-labs.com]
> > > Sent: 30 November, 2001 13:08
> > > To: Stickler Patrick (NRC/Tampere)
> > > Cc: ashokma@microsoft.com; www-rdf-interest@w3.org;
> > > joint-committee@daml.org
> > > 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
> > 
> > http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0579.html
> >  
> > 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 
> > 
> > http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0637.html
> > 
> > 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 Friday, 7 December 2001 17:51:59 UTC