- From: <Patrick.Stickler@nokia.com>
- Date: Sat, 8 Dec 2001 00:51:18 +0200
- 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. Cheers, Patrick
Received on Friday, 7 December 2001 17:51:29 UTC