W3C home > Mailing lists > Public > www-rdf-logic@w3.org > August 2001

Re: Summary of the QName to URI Mapping Problem

From: Thomas B. Passin <tpassin@home.com>
Date: Tue, 21 Aug 2001 19:38:50 -0400
Message-ID: <000801c12a9a$6ec021a0$7cac1218@reston1.va.home.com>
To: <www-rdf-logic@w3.org>
[Drew McDermott]

>
>    [<Patrick.Stickler@nokia.com>]
>
>    >
>    > The core mechanisms of RDF *must* preserve the integrity of all data.
>    >
>
>    [Tom Passin]
>    Aha!  I'm going to strongly disagree with you here.  One of the
features of
>    the current web is that it is not self-consistent, ....
>
>    ...
>    There is no way the SW is going to be any more self-consistent or
stable
>    than what we have today.  Now, what's the difference between
inconsistent or
>    changing data, and mechanisms that don't "preserve the integrity of all
>    data"?  Nothing, really, it's just a matter at what point
inconsistencies
>    creep in.  In either case, our systems are going to have to deal with
it.
>
> At the risk of starting (or restarting) a discussion on an issue
> too fuzzy ever to be resolved ---
>
> I don't like the tactic of refuting every argument by saying, "Oh,
> well, the SW is going to be inconsistent anyway."  I have several
> reasons:
>
> 1) Some of the same people who say this also say the SW will provide
>    formal proofs of statements such as "You owe me 3000 Deutschmarks."
>    I don't see how this is possible in an inconsistent system.
>    (Rather, I don't see why anyone should pay any heed to formal
>    proofs in an inconsistent system.)
>
> ....

> 4) The whole mindset of those who play the inconsistency card is too
>    anthropomorphic for me.  I believe they are thinking along the
>    following lines: People can cope with inconsistency, so our
>    programs should be able to as well, not like those "brittle" formal
>    systems.  To quote from Tom's posting (italics mine):
>
>       The web is extensible without central repositories or contracts
>       in large part because it isn't required to be self-consistent.
>       But *we* learn to deal with it anyway.
>
>       After all, no two *people* have exactly the same definitions of
>       or connotations for any word, yet somehow *we* communicate and
>       get things done.  It will have to be like that with the SW, I
>       imagine.
>
>    This style of reasoning is a perennial blind alley in AI,
>    especially, but not only, among novices.  The problem with it is
>    that you don't get anywhere by observing what people do; you get
>    somewhere by proposing an algorithm for a task.  I don't see many
>    inconsistent-SW fans proposing any algorithms.
>

Well, it's true I was being somewhat provocative, and possibly too extreme,
and it's true I don't say I know how to deal (with software) with these
kinds of issues.  But it is interesting to think about "proofs" when we
don't have certainty, isn't it?  I don't really expect to get machines
applying "common sense" to the degree people can, for example, nor to
understand all the nuances and contextual signals either.  But this doesn't
automatically lead to the opposite of certainty and non-fuzzy proof, either.

As for formal proofs of your "You owe me 3000 Deutschmarks", they would seem
to require some kind of verification, authentication, or belief that the
agent claiming that the debt is owed is being truthful.  It seems simple
enough when the scenario is that the system can back up the claim by
referring to invoices, previous orders, and shipping records.  But what is
supposed to happen when something goes awry in that chain?  Or some agent
illegitimately redirects the responses?  Or it continues to make the claim
and automatically enters it as a mark against your credit rating, even
though your agent has rejected the claim?

I suspect that there's going to be a lot more to the SW than formal proofs
and digital signatures, and that's what I was getting at.  Well, it all
remains to be seen, doesn't it?

Cheers,

Tom P
Received on Tuesday, 21 August 2001 19:35:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:40 GMT