RE: how a perl programmer might do datatypes in RDF

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