W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

Re: datatypes and MT

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Mon, 5 Nov 2001 18:45:29 -0600
Message-Id: <p0510102cb80ce08ea728@[]>
To: jos.deroo.jd@belgium.agfa.com
Cc: w3c-rdfcore-wg@w3.org
>Brian McBride wrote:
>>  Dan Connolly wrote:
>>  >
>>  > [...]
>>  >
>>  >  <rdf:Description rdf:about="#me">
>>  >    <shoeSize>
>>  >             <integer decimalRep="10"/>
>>  >    </shoeSize>
>>  >         </rdf:Description>
>>  >
>>  > To fill in the details... let dt:
>>  > be the namespace of XML Schema primitive datatypes,
>>  > and let rdfs:str be a new property
>>  > that relates XML Schema datatype to strings;
>>  > it's unambiguous over each of the primitive datatypes;
>>  > in the case of dt:string, it's the identity relation.
>>  >
>>  >  <rdf:Description rdf:about="#me">
>>  >    <shoeSize>
>>  >             <dt:decimal rdfs:str="10"/>
>>  >    </shoeSize>
>>  >         </rdf:Description>
>>  This isn't the same as above is it?  In your first example I could 
>>have extended
>>  it to read:
>>     <rdf:Description rdf:about="#me">
>>       <shoeSize>
>>                <integer decimalRep="10" hexadecimalrep="A"/>
>>       </shoeSize>
>>            </rdf:Description>
>>  I don't seem to be able to do that with your second example.  Are there
>>  advantages to that which you have written over:
>>     <rdf:Description rdf:about="#me">
>>       <shoeSize dt:decimal="10"/>
>>           </rdf:Description>
>>  or if you want the type property explicit, we need to invent a URI 
>>for the value
>>  space of the xsd datatype:
>>           <rdf:Description rdf:about="#me">
>>             <shoeSize>
>>               <eg:integer dt:decimal="10"/>
>>             </shoeSize>
>>           </rdf:Description>
>I really see advantages in DanC's proposal
>People often write
>   :s eg:shoeSize "10".
>   :s nav:date "2001-11-02".
>   :s nav:time "16:14".
>   :s nav:flightNum "1154".
>   :s nav:customerNumber "678".
>   :s apt:latitude "50-54N".
>   :s apt:longitude "004-32E".
>   :s apt:elevation "58M".
>or in general
>   :s :p "ooo".
>and I believe that is a shorthand for
>   :s :p [ rdfs:str "ooo" ].
>(I used to prefer rdfs:label instead of rdfs:str
>but now I think that rdfs:str is a better name for
>the property mapping a data value (that bNode)
>to it's string representation)

I have serious problems with this. For a start, why on earth would 
anyone say that latitude and longitude and elevation were *strings*? 
They clearly aren't strings, so this is just plain wrong. Second, 
suppose someone were to write an ordinary triple (all urirefs), eg

aaa bbb ccc .

then using the same reasoning, you could say that what they really 
meant was that there was a thing denoted by the uriref "ccc" which 
... etc, and so write this instead as:

aaa bbb [ rdf:uriref "ccc" ].

aaa bbb _:1 .
_:1 rdf:uriref "ccc" .

where of course rdf:uriref is the mapping that takes a thing and 
gives you the quoted string which, were you interpret it as a uriref, 
would denote that thing.

Now, that is a damn silly suggestion, obviously, but it is EXACTLY 
analogous to this suggestion for literals. And I don't see why the 
literals version is any more sensible than the damn silly version.


>So that object is actually some thing (that bNode)
>which has that particular rdfs:str representation.
>The shorthand is convenient when no additional
>description of that thing is needed.
>Now if we want to be more precise w.r.t. that thing,
>we just describe it further i.e.
>   :s eg:shoeSize [ rdfs:str "10"; rdf:type dt:decimal ].

OK, but what if we also know that read in octal, the string would be 
"12", so that

:s eg:shoeSize [rdfs:str "12"; rdf:type dt:octal ]

and now we merge?

>The real advantage I see is that
>   :s eg:shoeSize [ rdfs:str "10" ].
>can be entailed given that
>   :s eg:shoeSize [ rdfs:str "10"; rdf:type dt:decimal ].
>(and only in that direction)

But that seems to me to be rather a dangerous entailment, since if we 
then assert that, say, the range of eg:shoeSize is an octal number, 
we will  have a valid way to prove that 10=12.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Monday, 5 November 2001 19:45:29 UTC

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