- From: Peter Ansell <ansell.peter@gmail.com>
- Date: Sat, 16 Jan 2010 18:52:42 +1000
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Danny Ayers <danny.ayers@gmail.com>, jeremy@topquadrant.com, tai@g5n.co.uk, "semantic-web@w3.org" <semantic-web@w3.org>
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