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

Re: Datatyping Summary

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Wed, 30 Jan 2002 09:38:14 -0000
To: <w3c-rdfcore-wg@w3.org>

My responses to Brian's issue list.
Note none of my "can't live with" issues made it to the list, I hope Brian
can correct this.

B1: property bloat in S

I can live with this.
I haven't yet discussed this with my colleague who is going to do the
implementation. If he can't live with it, I will change my position.

B2: multiple lexical representations
I like this, I do find it a strength in S.

B3: log:implies
Since this is DanC's private implementation anything he says about it is
more likely to be correct than anything I say.
I think this is better addressed under B4.

B4: TDL breaks existing code
If you want complete backward compatibility then under TDL it is possible
- use an empty set of datatypes
- always refer to the literal string not the value part of the pair

If you want datatyping in existing code then some parts of existing code
break in any proposal.
TDL differs from S in the following sense:
- TDL differentiates between the (untyped) lexicalization and the (typed)
- S-B does not give access to the typed value.
Hence a TDL oriented API will have potentially distinct methods to access
the lexicialization and the typed value. Since old APIs will have one method
to access the string label, any old code will need to be reviewed as to
which is more appropriate.
For migration purposes mapping the old string label method onto the new
lexical form method will suffice, and code will not break.
It is not clear to me how S (particularly idiom B) helps improve existing
(or new) code.

B5: 	Storage
This is a red herring that has been adequately addressed in my view.
If anyone seriously wants an account of how to do "tidy" TDL storage with
"untidy" access methods I will add that to my queue.
Sergey, do you withdraw this objection?

Received on Wednesday, 30 January 2002 04:38:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:54 UTC