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

Re: how a perl programmer might do datatypes in RDF

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Thu, 6 Dec 2001 16:45:04 -0600
Message-Id: <p05101010b835a2aa067a@[]>
To: Dan Connolly <connolly@w3.org>
Cc: w3c-rdfcore-wg@w3.org
>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...)

The distinction is that rdfs:range isn't an operation; it doesn't get 
done to anything, but is rather asserted about something. That is 
part of RDF not being a programming language, right?

>  > 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>
>	<ex:shoeSize>10</ex:shoeSize>
>denote different things.
>The S/DC/PL proposals don't muck with things at that level.

I'm not sure to what intuitions you are appealing when you use the 
term 'muck with'. Leaving aside the rhetoric, it is true that the 
P-style proposals allow different occurrences of the same lexical 
literal to denote different values. But isn't that exactly what XML 
datatyping does, and aren't we under a mandated requirement to 
respect that? More generally, isn't that what ANY datatyping scheme 
does? If all literals were unambiguous then there would be no need to 
even use datatyping schemes. Traditional logical notations for 
example have felt no need for datatyping schemes for exactly this 
reason: they fix the meanings of things like numerals, and use other 
syntactic constructions to denote things like character strings. If a 
literal always denotes the same value, then there really is no 
datatyping in the language at all, seems to me. I'm not averse to 
that idea; it makes for a cleaner model theory , for one thing.  But 
I would like us to call a spade a spade, and if we decide to go with 
one of the S/DC/PL proposals, to say loud and clear that we have 
simply eliminated data-typing from RDF and do not plan to support XML 

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Thursday, 6 December 2001 17:45:19 UTC

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