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

"Datatyping for Dummies" (or Occam's Razor Slash Fest)

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 21 Feb 2002 11:55:48 +0200
To: Pat Hayes <phayes@ai.uwf.edu>, RDF Core <w3c-rdfcore-wg@w3.org>
CC: Brian McBride <brian_mcbride@hp.com>
Message-ID: <B89A90C4.F385%patrick.stickler@nokia.com>
On 2002-02-21 11:13, "ext Patrick Stickler" <patrick.stickler@nokia.com>
wrote:

> On 2002-02-21 0:29, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
> 
>> Ok, guys. Another version now at
>> http://www.coginst.uwf.edu/users/phayes/simpledatatype1.html
>> This changes the previous one as follows.

Pat,

Your latest treatment of inline literals seems to embrace
the outside-the-graph interpretation view that I've been
suggesting for the union-based minimal proposal (and
which in fact I've been suggesting for several months now).

What the rdfs:drange is really saying is that the property
value can be *either* a value bNode or a literal -- i.e the
datatype class contains the members of both spaces, i.e the
datatype class is the union of the value space and lexical
space of the datatype.

And the interpretation is that, if the property value is a
literal, it is treated as a lexical form (how else can you
equate it to the value triple idiom?) and if its a bNode it
is a value. This is my union-based proposal exactly.

Why not then, for the sake of the users (and us too ;-) toss
out all the extra d* vocabulary, and both the value triple
and doublet idioms (which were desparate measures before
considering datatype classes as unions) and say exactly the
same thing using the present RDF/S vocabulary using a treatment
of datatype classes as unions of lexical and value spaces?

I.e. That both of the following have the same datatyping
above-the-graph interpretation

   ppp rdfs:range xsd:integer .
   xxx ppp "34" .

   xxx ppp _:1 .
   _:1 xsd:integer "34" .

and in both cases, we're talking about the integer 34.

And that the statement

   xxx ppp "34" .

in isolation of any datatyping knowledge has no datatyping
interpretation. It might get some later, but that's the risk
of the inline, implicit idiom.

But, insofar as the graph syntax and MT is concerned:

   The literal "34" in all cases above, in the graph itself,
   denotes the literal "34". It *never* denotes 34, ever.

   The URI xsd:integer denotes the RDF datatype class, which
   contains both values and lexical forms of the xsd:integer
   datatype (is the union of the value and lexical spaces).

   The bNode _:1 denotes the value but *NOT* 34 (you need
   an application that knows about xsd:integer to *know*
   that the value is 34! Apart from the actual extra-RDF
   interpretation you can *never* know what value the bNode
   actually denotes! only that it denotes a single determinable
   value obtainable from the datatyping interpretation)

Simple. Clear. Unambiguous. Easy.

And with the additional assertions that:

   Everything denoted by a literal node has an rdf:type of
   rdfs:Literal.

   Everything denoted by a URIref node or bNode has an rdf:type
   of rdfs:Resource.

   rdfs:Literal is not a subclass of rdfs:Resource

Then using range intersection, folks can constrain property
values to either the inline idiom (lexical forms only) or
the datatype triple idiom (values only) using one of

   ppp rdfs:range ddd .
   ppp rdfs:range rdfs:Literal . (lexical forms only)

or

   ppp rdfs:range ddd .
   ppp rdfs:range rdfs:Resource . (values only)

Again, simple, clear, explicit, intuitive, easy.

Surely if you can make the MT work for your latest treatment of
the inline idiom, which really does assume a union treatment of
datatype classes, it can be made to work for the above minimalist
solution and we can achieve a solution that users will *enjoy*
using and not flail about over with moaning and gnashing of teeth.

Eh?

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 Thursday, 21 February 2002 04:54:17 EST

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