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

Re: Draft datatypes message

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Wed, 26 Jun 2002 18:00:18 +0100
Message-Id: <>
To: Aaron Swartz <me@aaronsw.com>
Cc: RDF Core <w3c-rdfcore-wg@w3.org>

At 09:43 21/06/2002 -0500, Aaron Swartz wrote:
>I will admit up front I have done a poor job of following the datatypes 
>discussion, but perhaps that will allow me to point out places where 
>things are not clear.

Yup - thanks

>On Friday, June 21, 2002, at 09:12  AM, Brian McBride wrote:
>>It is not possible to have the answers to Test B, Test C and Test D all 
>>be yes.  Either B and C can be yes or D can be yes.  We have to decide 
>>which of these is the most important to have; (B and C) or D.
>It seems to me that we would not want B and C to be yes. We would want B 
>alone to be yes. It would be helpful to explicitly state that this is not 


>A nit is that QNames in N-Triples should not have <>s around them, because 
>then they look like new URI schemes. I think it would be clearer to say:
>    <ageInYears> rdfs:range xsd:decimal .


>Another question that comes to mind is whether we can have:
>Test D2:
>   <Jenny>      <ageInYearsDecimalNumeral> "10" .
>   <ageInYearsDecimalNumeral > rdfs:range xsd:decimal .
>   <ageInYearsDecimalNumeral>  rdfd:abstract <ageInYears> .
>   xsd:decimal rdfd:concrete xsdr:decimal .
>   <John>  <ageInYears>      _:a .
>   _:a     <xsdr:decimal>   "10" .
>Which seems to avoid the overloading of the previous. Then I could use 
>simple inference rules to transform the former into the latter. This is 
>how I approach the similar problem in something like authorName vs. author.

Yes we could do that.  I'm making some judgements about how complex to make 
this question.

>N3 Rule:
>{?thing ?prop ?num . ?prop rdfs:range ?range . ?prop rdfd:abstact ?abs . 
>?range rdfd:concrete ?valprop } => { ?thing ?abs _:a . _:a ?valprop ?num } .
>Otherwise this seems to be a good summary.

Thank you.

Received on Wednesday, 26 June 2002 13:01:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:13 UTC