Re: Requirements for a possible "RDF 2.0"

2010/1/16 Pat Hayes <phayes@ihmc.us>:
>
> 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?

Sorry, I hadn't read through the definition for blank node properly.
If I had realised that Blank Nodes could actually represent anything,
instead of my naive, incorrect, view that they were just placeholders
for URI's. I do understand why Blank Nodes can't be put in the
predicate position currently though.

Cheers,

Peter

Received on Saturday, 16 January 2010 08:53:14 UTC