Re: RDFCore WG: Datatyping documents

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Jeremy Carroll" <jjc@hplb.hpl.hp.com> writes:

> The RDF Core WG has been considering datatyping for a while.
> 
> Currently there are three documents.
> 
> A desiderata document:
> 
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Jan/att-0291/01-RDF-D
> atatyping-Desiderata.html
> 
> 
> A discussion of XML Schema datatyping as relevant to RDF, and a proposal for
> using it within RDF:
> 
> http://lists.w3.org/Archives/Public/www-archive/2002Jan/att-0131/01-RDF_Data
> typing.htm
> 
> A second proposal for using XML Schema datatyping within RDF:
> 
> http://lists.w3.org/Archives/Public/www-archive/2002Jan/att-0128/01-RDF_Data
> typing.htm
> 
> 

Having read these, and had Jeremy explain the issues in Bristol on
Friday (for which thank you), I must confess the second proposal (TDL)
confuses me. Specifically:

"Those with predicate rdf:value or rdf:type are both treated
specially: rdf:value as equality, and rdf:type knows the supported
datatypes and treats them essentially as the map of the datatype
(i.e. <s, rdf:type, d> iff I(s) is a literal-value pair in the map of
d)"

What I was expecting to find was something like 'iff <value> =
I(d)(I(s))', i.e. the value is given by applying the function d to
lexical s.

Naturally that can't work, since (generally) datatypes aren't
functions. However some clauses could be added, perhaps.

TDL's method, which doesn't require those clauses, appears much more
troublesome. <"0.0",0> != <"0",0> is a typical problem.

This is hardly an original thought (it was discussed on Friday), but
could somebody explain why TDL does this? I can see hope for the
'almost a function' approach, but not for the lexical-value pairs.

Damian Steer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard <http://www.gnupg.org/>

iD8DBQE8Xq4zAyLCB+mTtykRArLYAJ9ZlAnUPeS3JzyxBxT/yd2axliazwCeLlkJ
GqPnluV5HAbCw6dkGMgLmVQ=
=WrZI
-----END PGP SIGNATURE-----

Received on Monday, 4 February 2002 10:58:30 UTC