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

Re: Semantics of non-datatyped literals: Rationale (version 2)

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Thu, 03 Oct 2002 19:33:48 +0100
Message-Id: <>
To: Sergey Melnik <melnik@db.stanford.edu>
Cc: RDF Core <w3c-rdfcore-wg@w3.org>

At 17:57 02/10/2002 +0200, Sergey Melnik wrote:


>    <jenny> foo:age      _:l .
>    <film>  foo:shoeSize _:l .

I believe we all agree this entailment holds.

>apparently meaning that Jenny's age is the same as John's shoe size.

'Apparently' being the key word.  But your argument seems to contain the 
logical fallicy that you have taken an abstract token (well two actually, 
"age" and "shoesize") that name an abtract logical thing and inserted them 
directly into a natural language sentence and are then suggesting 
inconsistency.   That is too easy a game to play:

   <John> foo:isa foo:girl.

apparently saying that John isa girl.

There is a famous paper I recall reading, by Drew McDermott I think, (I 
don't have a reference to hand) which makes the point that one must be 
careful about reading things into the text names we give things that are 
not really there in the logic.  Neither FOL nor a machine interprets the 
tokens "age" or "shoesize" as having anything to do with time or feet.

It is a useful test in cases like this, to replace those terms that might 
be suggestive to a human, with meaningless terms:

   <a> <b> _:l .
   <c> <d> _:l .

and see if your argument still holds.

>  We cannot forbid the above entailment - why do we care about the one below?

Because there are folks who want to know if it holds or not.  That seems 
like a reasonable question.

>  We owe the explanation to the developers such as Adobe folks who do not 
> see the problem we are discussing, and do not care about the one or the 
> other solution.

I currently believe that this affects implementations and 
interoperability.  If you can convince the WG that this is not the case ...

Received on Thursday, 3 October 2002 14:36:47 UTC

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