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

Re: Datatyping Summary

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Tue, 29 Jan 2002 10:06:37 +0000
Message-Id: <>
To: Brian McBride <bwm@hplb.hpl.hp.com>
Cc: RDF Core <w3c-rdfcore-wg@w3.org>
I think the killer issue for TDL is self-entailment (Dan's "duh" test).  I 
have been following with interest to see if Jeremy can come up with a 
workable MT for this:  his comments about treating literals like 
existentials sounded as if it had promise.  But, lacking a plausible MT 
proposal by next telecon I do wonder if we don't need to just go with S, 
because I've not seen any convincing fundamental problem with it...

At 09:58 PM 1/28/02 +0000, Brian McBride wrote:
>Issue B1:
>In S, if one wants to use both idiom A and idiom B, e.g.
>   <mary> <age> "10" .
>   <age>  <rdfs:range> <xsd:integer.lex> .
>   <mary> <ageD> _:a .
>   _:a    <xsd:integer.map> "10" .
>two properties have to be used, <age> and <ageD>, in this example.
>I believe there is a agreement that this is a difference between the two 
>Indeed, it may be said that the main aim of TDL is to avoid requiring 
>different properties for these different idioms.
>Does anyone in the WG consider this feature of S, on its own, to be a 
>"can't live with" issue with S?

I agree with the assessment.  It's not ideal, but so far seems to be 
standing up better than the alternatives.

>Issue B2: Multiple Lexical Representations of a data value
>S, idiom A, permits multiple lexical representations of a data value:
>   _:i <xsd:double>    "10.1" .
>   _:i <xsd:double.de> "10,1" .
>I believe there is agreement that S-A allows this.
>Does anyone in the WG consider this, on its own, to be a "can't live with" 
>issue with S?

I'd say that is a strong plus.

>Issue B3:  the "duh" issue
>DanC is concerened that with TDL:
>   <mary> <haircolor> "red" .
>and a rule:
>   ?x <haircolor> "red" => ?x <rdf:type> <redhead> .
>one cannot conclude
>   <mary> <rdf:type> <rdfhead> .
>since one conclude that both "red"'s denote the same thing.
>Jeremy has responded:
>   <mary> <haircolor> "red" .
>   <haircolor> <rdfs:range> <xsd:string> .
>and the same rule one can draw the required inference.
>DanC:  Does that solve the problem?  Do you withdraw that objection?
>Jeremy/Patrick:  Do you accept that without the range constraint, DanC is 

I am persuaded by Dan's argument, especially about self entailment.  I 
think the above is a consequence of that simple requirement.

>Issue B4 - TDL breaks existing code
>This is similar to B2.  I've changed the example slightly from Sergey's.
>Consider the graph:
>   _:f <rdf:type> <film> .
>   _:f <dc:Title> "10" .
>   <mary> <age> "10" .
>Given a query:
>   (?x <dc:Title> ?y) & (?z <age> ?y)
>existing applications will return:
>   ?x = _:f, ?y = "10", ?z = <mary>
>Under TDL, they would return null.
>Sergey:  Does this version of the issue illustrate your point?
>Jeremy/Patrick:  Do you accept this analysis; would the query return null 
>under TDL?

I don't see this (query case) as a decider, either way.  I suspect it only 
breaks existing code for poorly conceived queries (find me a value that is 
both a title and an age).

>Issue B5:  Storage Requirements
>TDL requires significantly more storage to implement.
>Jeremy/Patrick:  do you accept this statement?

No comment.

>Issue B6: S requires 4 URI's be registered for each data type
>S requires that for each datatype 4 URI's be registered
>   datatype
>   datatype.lex
>   datatype.val
>   datatype.map
>Sergey:  Do you agree this is the case?  If not, how many URI's are 
>required to implement ALL the idioms of S and coexist in the same model.

Nit:  I'd say that 3 rather than 4 URIs are required:

It would be nice if they weren't, but I don't see this as a big problem.


Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
       /\ \
      /  \ \
     / /\ \ \
    / / /\ \ \
   / / /__\_\ \
  / / /________\
Received on Tuesday, 29 January 2002 05:11:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:54 UTC