- From: <Patrick.Stickler@nokia.com>
- Date: Thu, 6 Dec 2001 14:16:21 +0200
- To: connolly@w3.org
- Cc: w3c-rdfcore-wg@w3.org
> > If the Perl scalar approach were taken, > > then *all* RDF would concern itself with would be the lexical forms > > and interpretation would be left to applications and particular > > operations of applications and those operations/applications would > > have to inspect and deduce data types and values themselves simply > > based on the lexical characteristics of the scalar representation. > > So far so good... > (I take it you're not using 'interpretation' in the sense > of the RDF model theory.) No (or at least I don't think so ;-) By 'interpretation' here, I mean figuring out what value in which value space is denoted by the lexical form embodied in the literal. (determining the pairing of lexical form and data type). A potential problem I see with the PL approach is that even if for the closed set of data types provided by Perl it is possible to deduce the intended data type, lexical form, value, etc. for a given scalar based on the operation or other contextual clues, I don't see this working in an open environment where there can be considerable intersection of lexical spaces for different data types with different mappings. You gave an example of coercion, but one would first have to know the data type lexical space of the scalar to know what to coerce it from, so if the knowledge of data type is imposed by operation, then that won't work. > > I don't really see how the PL proposal is different from the > > PDU proposal in that what is suggested is that the interpretation > > of a given scalar (lexical form) is based on the pairing of that > > scalar (lexical form) with a data type identifier. That's exactly > > what PDU suggests. > > Now it becomes critical to be clear whether you mean > 'interpretation' in the sense of the RDF model theory or not. > > I understand the P/P++ proposal to actually muck > with that level of interpretation; they actually > allow model-theoretic interpretaions where the objects of > <rdfs:label>10</rdfs:label> > and > <ex:shoeSize>10</ex:shoeSize> > denote different things. Well, those different objects with the same literal labels *might* denote different things -- if those nodes represent different values in different value spaces of different data types. > The S/DC/PL proposals don't muck with things at that level. I believe I understand your point -- that one can specify how a lexical form (literal) should be interpreted according to a given data type (inferred either by rdfs:range or operation) without having to state whether a given object node with a literal label represents a specific value in a particular value space. And maybe you're right that that is unnecessary. Though it seems to be important to alot of folks to have some node in the graph consistently and unambiguously denote a value. As far as I'm concerned (and am able to grok the problem) I'm happy if there is simply one or more consistent, standardized, and unambiguous ways to define the lexical form, data type pairing -- and base interpretation (mapping from lexical to value spaces) on that. So to that end, it looks to me that PL is the same as PDU. It just adds one more 'idiom' of defining that pairing, namely the expectations/needs of a particular operation outside of RDF space, if that pairing has not been defined by any of the other three idioms (P, DAML, U). We could refer to the combined set of 4 idioms from PDU and PL, all defining the pairing of lexical form and data type, as PUDL ;-) 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 Thursday, 6 December 2001 07:16:28 UTC