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

Re: Datatyping Summary

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 31 Jan 2002 11:04:14 +0200
To: ext Brian McBride <bwm@hplb.hpl.hp.com>, Dan Connolly <connolly@w3.org>
CC: RDF Core <w3c-rdfcore-wg@w3.org>, Jeremy Carroll <jjc@hplb.hpl.hp.com>, Sergey Melnik <melnik@db.stanford.edu>
Message-ID: <B87ED52E.CCE0%patrick.stickler@nokia.com>
On 2002-01-30 19:28, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote:

> Consider an implementation model where we have an application built on a
> generic RDF processing tool.
>                 Application
>           ---------------------  the line
>           Generic RDF Processor
> Lets take S idiom B:
>  <book> <dc:Title> "1984" .
>  <mary> <age>      "1984" .
> Below the line only processing which conforms with the RDF model theory is
> sanctioned.  Below the line, both occurences of the string "1984" denote a
> string.
> This does not preclude an application applying above the line knowledge
> that ...  But than happens above the line.

It seems to me that any "datatyping" solution that pushes interpretation
above that line is not actually doing datatyping, just providing a
more explicit interpretation of literals as strings than presently
provided by the MT.

The whole point, as I understand it, of doing datatyping in RDF is
so that the graph would be free of application specific interpretation
insofar as the denoted values are concerned so that we would have
greater interoperability between different applications and greater
portability of knowledge.

If a given proposal pushes responsibility for interpretation to
the application, such that two applications can arrive at different
interpretations, then that defeats the whole purpose of trying
to achieve a datatyping solution for RDF, no?


Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Thursday, 31 January 2002 04:03:25 UTC

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