W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > December 2001

RE: PL: how a perl programmer might do datatypes in RDF

From: <Patrick.Stickler@nokia.com>
Date: Sat, 8 Dec 2001 00:51:18 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B160B17@trebe006.NOE.Nokia.com>
To: Graham.Klyne@MIMEsweeper.com, connolly@w3.org
Cc: w3c-rdfcore-wg@w3.org

> -----Original Message-----
> From: ext Graham Klyne [mailto:Graham.Klyne@MIMEsweeper.com]
> Sent: 05 December, 2001 02:23
> To: Dan Connolly
> Cc: w3c-rdfcore-wg@w3.org
> Subject: Re: PL: how a perl programmer might do datatypes in RDF
> Nicely presented :-)

Yes, it was very well presented.
> This looks like an approach I could live with.

Insofar as it is functionally equivalent to the P approach and
thus subsumed by the PDU proposal, I could also live with it, but
not only with it alone (see below).

If PL is merely interpreting a given "scalar" literal based on
some data type inferred sometime, somehow -- either by rdfs:range or
the actual operation of an application -- then PL is no different
really than P. It just uses different terminology and offers some
additional (undefined) mechanisms for pairing the literal with
a data type. 

It seems that the only significant difference between P and PL is
that P (per my understanding) posits that different bNodes labled 
with the same literal (potentially) denote different values
and PL makes no such assertion but leaves this determination for later
interpretation. Yet this is a secondary issue IMO to the fundamental 
fact that both are inferring a pairing of lexical form (or scalar)
and data type and interpretation is based on that pairing. 

One other shortcoming of PL, and why I could not live *only* with PL
is that the need for local data typing is not addressed at all.

There are pros and cons to both local and global typing mechanisms,
and there is a need for both. As with P, the PL approach does not allow 
for local typing, which is necessary for ensuring that the 
interpretation of literals intended by the content producer is explicit,
and thus it cannot provide a complete solutoin by itself.

This need for both local and global typing mechanisms is why the PDU
proposal suggests more than one idiom -- but defines all such idioms
as synonymous ways of defining the key information needed for data
typing, namely a pairing of lexical form to data type.


Received on Friday, 7 December 2001 17:51:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:07 UTC