Re: how a perl programmer might do datatypes in RDF

Patrick.Stickler@nokia.com wrote:
> 
> I thought the idea of scalars in Perl was that their interpretation
> was delayed to the actual operation being applied.

You can look at it that way if you like... you won't
run into any contradictions, as far as I can tell; but that's not
how the perl designers specify it. Again, please see:
  <http://www.perldoc.com/perl5.6/pod/perldata.html>

> The rdfs:range
> property is not IMO an operation. An operation would be something
> like max(a,b) or add(x,y).

I don't see the distinction. (I'm not sure it matters, either...)

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

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

The S/DC/PL proposals don't muck with things at that level.

> What am I missing here? (or am I missing anything?)

I'm not sure; I would need you to be more precise
before I can tell.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Wednesday, 5 December 2001 14:20:52 UTC