RE: Datatyping Summary

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 UTC