W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2002

Re: simplified datatyping proposal

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 20 Feb 2002 12:50:42 +0200
To: ext Graham Klyne <Graham.Klyne@mimesweeper.com>, Pat Hayes <phayes@ai.uwf.edu>
CC: RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B8994C22.F0DA%patrick.stickler@nokia.com>
On 2002-02-20 11:13, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>

> Oh dear, it's looking as if I seriously dropped the ball on this...
> With my CC/PP hat on I don't see the following "long-range" usage is
> supported:
>   _:SomeClientComponent client-property:dpi "100" .
>    :
>   client-property:dpi rdfs:range datatype:number .
> i.e. does not define support for idiom B in the datatyping desiderata
> document:
>   http://lists.w3.org/Archives/Public/www-archive/2002Jan/att-0133/00-gk.htm
> What also now seriously bothers me is that I can't see how the full
> proposal [1] supports this either.  I had earlier convinced myself that
> this was all OK, but now I can't see it.   Aaargh!

It was specifically to provide this support that I suggested
the union interpretation of rdfs:drange, so that it would
provide a consistent interpretation for both the S-B idiom
and the bNode idioms.

Folks can still use the S-B idiom *without* any defined
range constraints to interpret all such inlined literals as just
literals. If you have long range datatyping, you are doing
datatyping. Tough. If you don't want any datatyping in your
application, either strip out range constraints or just
ignore them.

But CC/PP and other similar applications can use the inline
idiom and datatyping to obtain a consistent interpretation.

I appreciate your comments, Pat, about the weaker nature of the
union interpretation, but the point is to obtain consistent
interpretation of (mapping to) values, and the union treatment
of rdfs:drange provides that, as my long list of use cases in

> I was thinking that there was a way to say that
>   client-property:dpi rdfs:range datatype:number .
> expressed the property range as the lexical space of some datatype.

You can. You could say

   client-property:dpi rdfs:lrange datatype:number .


> --
> [1] http://www.coginst.uwf.edu/users/phayes/DatatypeSummary3.html
> At 10:11 PM 2/19/02 -0600, Pat Hayes wrote:
>> Guys, Ive put up a quick draft of a simplified version of the datatyping
>> proposal at
>>  http://www.coginst.uwf.edu/users/phayes/simpledatatype
>> I think this version is simple enough for the DPH. It uses the datatyping
>> triple idiom:
>> Jenny ex:age _:x
>> _:x xsd:number "15"
>> as primary, and treats rdfs:dlex as a kind of 'empty case' for when you
>> don't know the datatype, and then links rdfs:drange directly to that, so
>> you don't need to use rdf:dtype or the doublet form at all unless you want
>> to. This keeps everything simpler and also much more robust against clashes.
>> BTW, notice I have NOT said that all datatype properties are subproperties
>> of rdfs:dlex. There isn't any need to, and that would introduce a lot more
>> potential clashes if we did. Also this way of doing  it means that 'local'
>> dtypes always take priority over 'range' dtypes, which seems right.
>> Anyway, for your amusement.
>> Pat
>> --
>> ---------------------------------------------------------------------
>> IHMC                                    (850)434 8903   home
>> 40 South Alcaniz St.                    (850)202 4416   office
>> Pensacola,  FL 32501                    (850)202 4440   fax
>> phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
> ------------------------------------------------------------
> Graham Klyne                    MIMEsweeper Group
> Strategic Research              <http://www.mimesweeper.com>
> <Graham.Klyne@MIMEsweeper.com>

Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Wednesday, 20 February 2002 05:49:18 UTC

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