RE: Cutting the Patrician datatype knot

From: Patrick.Stickler@nokia.com
Subject: RE: Cutting the Patrician datatype knot
Date: Sat, 8 Dec 2001 00:51:53 +0200 

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

This is *not* what I mean.  See below for clarification.

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

Then what is your scheme?

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

Then what is the following wording doing in your message
(http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0579.html)?

[[[
Note: The following constraints/requirements apply:

   * the anonymous node has one and only one rdf:value
   * the anonymous node has one and only one rdf:type
   * the property value of rdf:value is a literal
   * the property value of rdf:type is a URI Ref
]]]


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

Not according to your message.  

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

The *point* is that your message restricts anonymous nodes to having ``one
and only one rdf:value'' and ``one and only one rdf:type''.  This is a
gigantic extension to RDF.

> > Moreover, part of this constraint 
> > does not have
> > any analogue in the semantics.
> 
> There is no such constraint. No conflict with the semantics.

Not according to your message.

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

Not according to your message.

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

The what is the meaning of the construct as far as RDF is concerned?

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

Not according to your message, ``one and only one'' does not seem to allow
for zero.

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

No.  Some datatypeing proposals provide a meaning for such constructs.

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

Well I did try to understand the message that you told me contained the
best definition of PDU.  If you now come back and state that PDU is not
what was in this message, then how am I supposed to be able to understand
PDU?

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

Both P and P++ provide meaning for such constructs.  

> RDF does and should permit one to create broken knowledge.

Even if one considered the above to be broken, which I don't, RDF has to
provide a meaning (or a collection of possible meanings for every legal RDF
knowledge base.  If it doesn't, then it is just not suitable for use.

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

Sure, but any datatyping scheme has to be able to handle contradictions and
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.

Huh?  What is S doing here.

> Eh?
> 
> Cheers,
> 
> Patrick

peter


> 
> --
>                
> 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 23:36:40 UTC