The point of RDF Datatyping (in case it wasn't clear ;-)

It seems that the fundamental, practical "get the job done"
point of RDF Datatyping is not a point of concensus of the
WG, much to my disappointment, so I thought I'd briefly
summarize what I consider it to be.

Who knows, maybe we really do all agree about the
following... ;-)


RDF has no native representation for any datatyped values.
It knows nothing about integers, dates, strings, etc. And
this is a good thing, because it keeps RDF platform and
system independent, which one would expect from a standard
intended for the global interchange knowledge.

Literals belong to a pseudo catch-all datatype that is not
much use insofar as "real" datatyping is concerned. But it
has a simple job to do and it does it well. It represents
strings. Plain and simple. Fair enough.

What is needed is a way for system A to exchange datatyped
knowledge with system B in a manner that is independent
of either systems native representations yet which will
preserve meaning across that exchange.

Take the following example:


           System A

          8506131627
              |
              V
  <date,"1985-06-13T16:27:00">
              |
              V
         [RDF Graph]
              |
              V
  <date,"1985-06-13T16:27:00">
              |
              V
    "00198506131627000000"

           System B

The underlying, native representation for dates
is different for each system, but the representation
of interchange is standardized. And what counts most
is not the particular idiom used in the RDF graph,
but that it is unambiguous and consistent in which
datatype context the lexical form is to be
interpreted by System B in order to obtain the
value originally expressed by System A.

Now, it may be that system B doesn't know what 'date'
means, in which case, it's stuck. But if it does know
what 'date' means, then it knows which value is identified
by the pairing <date,"1985-06-13T16:27:00"> which is
unambiguously expressed in the RDF graph by a particular
idiom, and can map that pairing to the actual value, as
it is represented within system B.

For various practical reasons, how those pairings are
expressed in the RDF Graph varies, and each variation
is called an idiom. And the sole purpose of an idiom
is to capture a pairing of datatype and lexical form.

Thus, the very heart of RDF Datatyping is the
"literal-in-context", the pairing of the lexical form
with a datatype, a datatyped literal, whatever you
want to call it, it's all the same.

An idiom is just a means to that end. Period.

Yes, it's important for those idioms to be well defined,
and for there to be as few standard idioms as possible
(simply for practical reasons). But "all idioms are
created equal" in that their common purpose is to
associate a lexical form with a datatype context for
consistent and unambiguous interpretation.

Whether or not folks want/need the datatyping MT to provide
a formal definition for such datatyped literal pairings
seems an open question. It could be argued that failure
to capture such a fundamental basis of datatyping is
a shortcoming of the MT, or that the MT is to that extent
incomplete. This is not to criticize Pat's excellent work,
but simply to suggest that perhaps it is not finished.

Personally, I don't need it in the MT. Sections 1-4 work
just fine for me (and probably will for most RDF users).
But if others will sleep better with a formal MT definition,
that's also quite fine by me. I certainly appreciate such
concerns and am happy to do what I can to help address them.

I don't consider the present WD to shift the stake in the
ground one bit. Now, perhaps extending the MT to provide
a formal definition of datatyped literal pairings would
require a little twisting or bending at the stake, but it
also probably wouldn't pull it out.

Anyway, just thought I'd get that off my chest before going
to bed...

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Tuesday, 16 April 2002 14:31:58 UTC