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

burned at the stake (was Re: datatyping unstaked)

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Sun, 16 Jun 2002 17:19:09 +0300
To: Pat Hayes <phayes@ai.uwf.edu>, RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B932790D.16DDB%patrick.stickler@nokia.com>

Thanks, Pat, for making this effort, and while I think we agree
on ultimately what the interpretation of literals should involve,
I'm going to go one step further and simply pour gasoline on
the stake and set it alight (see below).


On 2002-06-14 6:04, "ext patrick hayes" <phayes@ai.uwf.edu> wrote:


> Everything else works as before; graphs are tidy on literal nodes.
> 
> What follows? First, note that this allows the literal to 'indicate'
> a different value than it denotes (ie something other than itself),
> and a different one of those in each triple. So although it is indeed
> true that "10" denotes "10" in this graph, nevertheless the meanings
> of the the two triples containing that literal can refer to different
> things than "10". This means in turn that the entailment rules need
> to be modified slightly: it isn't valid to existentially generalize
> on literals. For example, the above graph does NOT entail
> 
> <ex:Jenny> <ex:age> _:x .
> _:f <dc:title> _:x .
> _:f <rdf:type> <ex:movie> .
> 
> It does, however, entail
> 
> <ex:Jenny> <ex:age> _:x .
> _:f <dc:title> _:y .
> _:f <rdf:type> <ex:movie> .
> 
> via the graph below.

It seems to me that you are defining untidy literals without admitting
that literals are untidy. Don't get me wrong, I'm all for a MT that
allows the inline idiom to denote values rather than lexical forms,
but if we're going to have untidy interpretation for literals yet
not make them untidy, we miss the benefit of being able to use
RDFS range semantics for defining global datatyping contexts.

Thus, it's like having your cake but being forced to eat it
through a straw.

If literals have untidy interpretation (and I think they should) then
we can also simply say that the literal node denotes the value and
then use rdfs:range to assert global datatyping for the inline
idiom and define datatyping in terms of RDFS semantics.

> What this is all about, of course, is tidyness; we can't assume that
> a tidy literal indicates the same thing in each triple.

Sounds like just saying that literals are untidy.

Apologies in advance, but I'm going to get "right in the face" of
the WG and strongly insist that we got it completely wrong when we
decided that literals were tidy, and that all the MT gymnastics
that has to happen to make things work the way people are actually
using datatyping is getting rather pathetic.

We should stop, back up, make literals untidy, and use RDFS
semantics "as God intended" to define datatyping of literal values,
adding the necessary definitions for the special characteristics
of datatype classes and their relationship to RDFS class extension
and be done with it.

> Then all the 
> current idioms work out as they do now, except that the in-line idiom
> is datatype-sensitive, as Patrick wants.

Well, I'd rather say that it's what users of DC, CC/PP, and other
applications already *use* (not simply what I want, though that
is true).

--

I formally call for the WG to consider replacing the stake in the
ground with the earlier simpleDatatypes2 which is grounded in
RDFS semantics and reflects common perceptions and expectations
regarding RDF datatyping as it relates to the inline idiom
and introduces less vocabulary and brings datatyping into
full compatability with RDF typing proper.

It's far simpler, clearer, and reflects what users are doing.

See the attached materials.

I would like to see this addressed during the F2F when datatyping
is discussed.

Regards,

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 Sunday, 16 June 2002 10:14:54 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:49:19 EDT