FW: Even more simplified datatyping proposal

 


------ Forwarded Message
From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 20 Feb 2002 15:22:32 +0200
To: ext Jos De_Roo <jos.deroo.jd@belgium.agfa.com>, Pat Hayes
<phayes@ai.uwf.edu>, Brian McBride <brian_mcbride@hp.com>
Subject: Even more simplified datatyping proposal



*** I'm sending this offlist for the moment...


On 2002-02-20 11:36, "ext Jos De_Roo" <jos.deroo.jd@belgium.agfa.com> wrote:

> we actually wonder if ... could be simplified ???

How about this...

If we take only the inline and datatype triple idioms (no doublet,
no value triple) and take a union interpretation of datatypes in
general (a datatype class contains both values and lexical forms,
not tying such an interpretation exclusively to rdfs:drange but
making it so for the datatype in all contexts), then perhaps the
following is enough:

> rdfs:Datatype a rdfs:Class .
> 
> { ?d a rdfs:Datatype } log:implies { ?d rdfs:domain ?d } .

Though, I recall the fixed domain of a datatype property is
its value space and the fixed range of a datatype property is its
lexical space? ie.

 { ?d a rdfs:Datatype } log:implies { ?d rdfs:domain ?d.val } .
 { ?d a rdfs:Datatype } log:implies { ?d rdfs:range ?d.lex } .

The latter we can capture generically with

 { ?d a rdfs:Datatype } log:implies { ?d rdfs:range ?d ;
                                         rdfs:range rdfs:Literal } .

And we don't have to worry about the domain of a datatyping
property also including literals since literals can't be subjects
so the subject of a datatype property will always be a bNode
denoting the value.

--

Thus, no addition of vocabulary whatsoever, and only one extra
class, for convenience and clarity more than anything. To recap
my earlier examples, with the reduced, traditional vocabulary:

Case 1: Both inline/bnode idioms allowed

   dc:date rdfs:range xsd:date .

   xxx dc:date "2002-02-20" .  (ok)

   zzz dc:date _:2 .
   _:2 xsd:date "2002-02-20" . (ok)

Case 2: Only inline idiom allowed

   dc:date rdfs:range xsd:date .
   dc:date rdfs:range rdfs:Literal .

   xxx dc:date "2002-02-20" .  (ok)

   zzz dc:date _:2 .
   _:2 xsd:date "2002-02-20" . (not ok)

Case 3: Only bNode/value idiom allowed

   dc:date rdfs:range xsd:date .
   dc:date rdfs:range rdfs:Resource .

   xxx dc:date "2002-02-20" .  (not ok)

   zzz dc:date _:2 .
   _:2 xsd:date "2002-02-20" . (ok)


The key to making this all work is treating datatype classes
as the union of both value space and lexical space, and leaving
it up to the graph syntax to differentiate which is which.

Eh? 

Note, although the above uses the original S idioms, it
has anything but the S MT interpretation of those idioms, in
case anyone feels like shouting "but that's S", because it
isn't... not by a long shot -- in fact, I got the union idea
during intense deliberation with Sergey over using multiple
URIs or vocabularies to solve the cohabitation problems of S,
and suggested that treating datatypes as the union of
lexical and value spaces might alleviate that conflict,
but of course, that would have meant totally changing the
S MT and was not taken seriously at the time... not that it
seems to be taken seriously now either... but I still hope ;-)

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com


------ End of Forwarded Message

Received on Thursday, 21 February 2002 04:03:12 UTC