W3C home > Mailing lists > Public > www-archive@w3.org > February 2002

Re: Apologies, groanings, and gnashing of teeth...

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Sat, 23 Feb 2002 07:50:45 +0200
To: ext Brian McBride <bwm@hplb.hpl.hp.com>
Message-ID: <B89CFA55.F6BA%patrick.stickler@nokia.com>
On 2002-02-22 20:53, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote:

> At 18:43 22/02/2002 +0200, you wrote:
>> Brian,
>> I apologise for speaking out of turn at the tail end of
>> the datatyping discussion
> Well, you shouldn't have done it of course, but no long term damage done.

I hope not.

>> -- but I was really frustrated that
>> Pat and others were saying "this can't be done" when the
>> reality is that, even if it can't all be captured in the MT,
>> it's a no-brainer that we can define a consistent interpretation
>> *somewhere* that would allow folks to clearly and consistently
>> express their typed literals in a way that any arbitrary
>> application (or human) following the same spec will know
>> exactly what was meant, and what value some lexical form
>> maps to.
> Patrick, what is your view on what the model theory is for, and what value
> do you think we can get from it.

I consider that some MT is manditory. I understand fully what
it is for, even if I can't write it myself.

The MT provides a very high precision, provable account of
what the functions of and relationships between the components
of the graph are, so that it is crystal clear what the
interpretation should be by any arbitrary application (or human)
considering the same graph in terms of the same MT.

It's one (very precise) way to express agreement about what
an RDF graph really means.

However, there is alot of knowledge and interpretation that
we can agree about which may not in fact be defined in terms
of the MT. Is that knowledge then as explicit or precise as
that addressed by the MT? Maybe. Maybe not. But probably it's
of sufficient precision and clarity to achieve consistent and
reliable interoperability between users and applications.

To claim that agreement and interoperability cannot be achieved
without a valid MT is simply wrong.

This is certainly born out by the fact that folks have managed
to achieve many interoperable, portable, solutions in the
absence of some precise MT interpretation. Does that mean that
such endeavors have been without their misunderstandings and
disconnects? Of course not. And if they had had an MT, they
probably would have derived benefit from it. But its absence
was not a show stopper.

Datatyping, in its entirety, cannot be addressed by the RDF MT.

This is because there are no native datatypes in RDF (nor should
be) and because we are not providing in RDF a means for fully
defining the semantics of any given datatype. In fact, even XML
Schema does not do that. XML Schema does not in fact define
any actual mapping function from lexical form to value is, but
leaves that implicitly understood.

What the majority of RDF users need is simply a consistent, clear,
portable, standardized way to associate a datatype with a literal,
so that it is clearly, consistently, and globally understood what value
is meant. The RDF MT will *never* be able to say what that value
actually is, all it can say is that the value is obtainable by
executing some extra-RDF interpretation of the literal in terms
of the extra-RDF datatype semantics. But I think that this truth
eludes Pat or that he does not appreciate the significance of it.

Such pairings are the very basis of the TDL concept (which unfortunately
was not captured by Jeremy's MT, though I greatly appreciate his efforts
in trying). TDL has never intended for the RDF MT to capture the explicit
details of datatype internals. Only to capture the pairing of
literal to datatype and define the idioms that express those pairings.
And that is all we have ever needed.

I can appreciate what Pat and Jos and Sergey and others *want* to
be able to do with the MT, to have an explicit mathematical model
for what datatypes are, but that is not what the majority of RDF
users want or need.

In the words of Spock: "The needs of the many outweigh the needs
of the few or the one".

From the very beginning of the datatyping debates, the needs of
the few have overshadowed the needs of the many, and the MT tail
has wagged the RDF dog so much that the dog can't walk straight.
I've said it before and I say it again now.

We do not need (nor perhaps even want) the RDF MT to talk about
the internal structure of datatypes in the way that the S MT or
Jeremy's MT for TDL or Pat's current MT on the table. At one time
I thought maybe such a thing could be useful, and if doable and
attractive for those that wanted it, then why not. But it has
become quite clear that it is far, far more difficult to achieve
than previously presumed, and I have never myself considered it
to be actually necessary. We need to step back and refocus on
the big picture, which is not just folks doing theorem proving,
but folks wanting to capture metadata about resources and share
that knowledge on a global basis in a consistent and practical

The "MT" interpretation that I have proposed in my "Dummies" quiz
provides a consistent RDF level interpretation of the components
of the graph which *contribute* to or *participate* in the upper
layer, extra-RDF interpretation for datatyping, and a consistent
RDF interpretation of the idioms -- meaning that if we know that
some URIref ddd is rdf:type rdfs:Datatype then we can precisely
and consistently determine pairings of literal and datatype and
know that the literal represents a lexical form and that *together*
the *pairing* (not the literal) identifies a specific value of that

But the determination of *which* value is identified by such a
pairing happens entirely outside of the scope of RDF -- as it must,
since RDF does not grok the actual datatypes.

All of the round-about debates and arguments with Pat, Graham, Jos,
Sergey, Dan, et al have been about problems with modelling *datatypes*
in the RDF MT, not modelling *datatyping* in the RDF MT, and the
two are not equivalent. The former tries to capture the internal
structure of datatypes. The latter captures the pairing of literals
and datatype identities for extra-RDF interpretation. All most folks
need is the latter. All most folks want is the latter. All we can
provide at the moment is the latter.

I fully appreciate the knowledge, wisdom, experience, and even
prestige that Pat and others bring to the WG, but the bottom line
is that many of them just don't "get it" with regards to what the
average, common, semi-technical to non-technical RDF user wants
and needs, and although it makes your job as chair that much harder,
I will *not* let them f**k up RDF for "the rest of us".

Apologies for being so blatantly offensive. But I want to be sure
you understand just how strongly I feel about this. The mathematicians
have ceased to provide benefit for RDF datatyping and are smothering and
killing it with complexity to make it meet their needs, not the needs of
the majority of RDF users.

Perhaps a time will come when some future version of the RDF MT is
able to capture more, or even all, of datatyping as Pat and the
others would like. If so, great. But *right now* we don't need it.
It's too much work. There are too many challenges. Enough already.

And punting on datatyping entirely is just as bad. The RDF world
acutely *needs* some standardized expression of datatyped literals.

So let's please stop candyassing around with trying to shoehorn
the entirety of datatyping in the MT, agree that insofar as the
MT is concerned, literals denote literals, and define the semantics
of the datatyping idioms elsewhere -- but in a way that *all* users,
and all applications can consistently know (even if without the anal
precision of the MT) what the hell to do with some pairing of literal
and datatype URI. OK?

Oh, and by the way...  ;-) ;-) ;-) ;-)


Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Saturday, 23 February 2002 00:49:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:42:04 UTC