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 12:21:31 -0000
To: "Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
Cc: <w3c-rdfcore-wg@w3.org>
Message-ID: <JAEBJCLMIFLKLOJGMELDKEOOCCAA.jjc@hplb.hpl.hp.com>
Summary: warm fuzzies agreeing with much of Graham's analysis.
Status:  skippable.

Jeremy:
> >TDL allows clarity about this distinction, and allows query
> researchers to
> >explore both possibilities.
Graham:
> So does S.  In the case of S, the method used (value or literal) is
> explicit in the vocabulary used.  (For me this is an observation, not a
> show-stopper either way.)


This is nice it gives one possibly factor in deciding for S or TDL.

- S expects/requires the document author to determine whether the value or
literal is used.
- TDL expects/requires the RDF processing to determine whether to operate on
the value or literal.


Jeremy:
> >Thus, S-B maintains a theoretical purity by pushing all typing
> problems into
> >the application layer.
Graham:
> Yes, this is true.  And I do think that early deployment of RDF into
> applications will require this kind of approach, in some form or
> another.  Applications that take datatyping and generic inference more
> seriously should probably not use this idiom.
>
> Idiom B allows RDF to be presented to developers as a kind of
> stylized XML
> -- at worst, mostly harmless and a painless way to accommodate the more
> advanced technology geeks like me.
>
> (This is a re-run of an argument I've made previously about
> deployability,
> in another context.  In a sense, idiom B could be our Trojan Horse for
> getting RDF compatible formats into XML applications.)
>

I suppose I see idiom B as more than this.
I think idiom B has been, and will remain, the basic most widely used RDF
idiom. Hence I am deeply concerned to actually *do* RDF datatyping for this
idiom rather than punt it into the application space. This may be a key
difference between our positions.


> >So, S-B is seriously flawed in that it does not assist the application
> >developer to avoid logical errors associated with datatyping.
>
> OR: S-B is powerful, because it allows the datatyping issues to be
> deferred, avoiding having to burden the developer with the
> logical details
> of datatyping.

OK there's more than one way to perceive it.

>
>
> >=====
> [...]
> >So TDL assists the application developer in being logically correct.
>
> I think you've argued convincingly that TDL has certain advantages, *if*
> TDL can be deployed in a way that is broadly compatible with
> existing practice.
>
> However, I don't think you've successfully argued that these
> considerations
> make S unworkable.

OK - I am increasingly convinced that any one issue with S by itself is not
a complete showstopper; but I find the weight of issues compelling.

Jeremy
Received on Wednesday, 30 January 2002 07:21:05 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:44:02 EDT