Re: Requirements for a possible "RDF 2.0"

On Jan 15, 2010, at 6:39 PM, Peter Ansell wrote:

> 2010/1/16 Pat Hayes <phayes@ihmc.us>:
>>
>> On Jan 15, 2010, at 4:57 AM, Danny Ayers wrote:
>>>
>>> literal subject - aside from quotations:
>>>
>>> "I can't really see how it would be useful" <x:saidBy> <#me> .
>>
>> "37"^^xsd:number rdf:type PrimeNumber .
>>
>> "42"^^xsd:number :playsRoleIn  :HitchHIkersGuide .
>>
>> "66"^^xsd:number :greaterThan _:x .
>> _:x :age :PatHayes .
>>
>> (which is why I don't get a full SS pension this year).
>>
>> I'm sure I could think of others.
>>
>> But the main point is that allowing all this makes the language  
>> *simpler*.
>> the question should be, why the hell did we not allow it in the  
>> first place?
>
> If you are willing to store information like the entire set of Primes
> or the entire number line (including real and complex numbers??) in
> your database to make your computation simpler

? Who suggested that? I certainly did not.

> then you can afford to
> have the database bloat by a factor of two and do it the current way
> every other RDF application does it or you could use query time
> computation rather then declaration.
>
> In my view, RDF is based on the paradigm that the only things that can
> have properties assigned to them are universal and have a clear and
> distinct meaning.

Im not even sure what this means. but it sure sounds badly wrong. RDF  
is used for large amounts of instance data, none of which is  
'universal' (?)

>
> "66"^^xsd:number isn't actually that clear a meaning

Well, its one of the clearest available. Check out the XML Schema specs.

> , as it is the
> same as "66"^^xsd:integer, but it does not have the same implications
> as "66.0000"xsd:float in all circumstances. In scientific applications
> the number of decimal places will have a material effect on the error
> statistics and the overall conclusions that you can make, although in
> logic terms there may be no distinction if numbers are considered
> universals. It may also be the same as "65.99...."^^xsd:float in most
> circumstances, not that RDF has a proper notation for repeating
> numbers as far as I know.

All this is why we use datatypes. It would be quite possible to define  
a recurring decimal datatype format, by the way.

>
> If you just accept that a URI is conclusive then the use of the URI
> anywhere else has a distinct meaning. If you do something like allow
> literals which are imprecise as things that you can give properties to
> then the whole paradigm will fall down, even if the N3 file format
> will support what is left of the paradigm.

Really, I think you are quite badly wrong here. Its the URIs which are  
the most ambiguous. What *exactly* does
http://dbpedia.org/resource/Mount_Everest
mean? I know its a mountain, but what exactly is a mountain? Where are  
its edges? How much does it weigh? Perfectly simple questions like  
this have no answer because the referent is not pinned down  
sufficiently exactly. The denotation of a typed literal like  
"34"^^xsd:number is comparatively exactly specified. But this is fine:  
the whole edifice does not fall down when the URIs are ambiguous. And  
N3 has absolutely nothing to do with it.
BTW, numbers and strings and dates DO have properties, whether RDF  
allows them to be said or not. In fact, we can even say them, but only  
indirectly, using bnodes:

_:x  rdf:type PrimeNumber .
_:x owl:sameAs "37"^^xsd:number .

Since we can say this, why not be able to say it directly?

Pat


>
> The following is not ambiguous, in that someone could use
> <http://mydomain.org/precisionfloat:66.0000> somewhere else and not
> have any implication that it is exactly equivalent to
> <http://mydomain.org/integers:66> in all cases.
>
> <http://mydomain.org/integers:66> ex:integerValue "66"^^xsd:integer .
> <http://mydomain.org/precisionfloat:66.0000> ex:floatValue
> "66.0000"^^xsd:float .
>
> <http://mydomain.org/integers:66> :greaterThan  _:x .
> :PatHayes :hasAge  _:x .
> :myexperiment :hasOutcome <http://mydomain.org/precisionfloat: 
> 66.0000> .
> :myexperiment :doesNotHaveOutcome <http://mydomain.org/integers:66> .
>
> There is value in not making everything simpler just for the sake of  
> it.
>
> Cheers,
>
> Peter
>
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Saturday, 16 January 2010 06:11:25 UTC