W3C home > Mailing lists > Public > www-rdf-logic@w3.org > July 2002

Re: Dataypes, literals, syntax

From: pat hayes <phayes@ai.uwf.edu>
Date: Wed, 31 Jul 2002 18:40:10 -0400
Message-Id: <p05111b21b96e15f6405b@[]>
To: "Jonathan Borden" <jonathan@openhealth.org>
Cc: www-rdf-logic@w3.org

>pat hayes wrote:
>>  ... We can get the same effect by
>>  using a bnode and an extra triple, in effect writing the typed
>>  literal as a triple:
>>  Jenny age _:x .
>>  _:x xsd:integer "10" .
>>  >  > As an example of a problematic inference, consider whether
>>  >>
>>  >>  <foo://bar> ex:property xsd:integer"10" .
>>  >>  <foo://baz> ex:property xsd:octal"12" .
>>  >>
>>  >>  should or should not entail
>>  >>
>>  >>  <foo://bar> ex:property _:xxx .
>>  >>  <foo://baz> ex:property _:xxx .
>>  >>
>>  >>  and how this could be detected by a reasoner.
>>  >
>I am not sure that
>Jenny age xsd:integer"10" .
>is effectively different than:
>Jenny age _:x
>_:x xsd:integer "10" .

It sounds like we are in violent agreement. OK, lets say they are not 
effectively different. The second one, however, is legal RDF, and the 
first one isn't. So why not use the one that is, since they are 
effectively the same? (Guha tells me that in his opinion, they are 
not effectively the same, and that the first has computational 
advantages over the second for writing APIs. OK, maybe: but that is a 
different point.)

>1) RDF would have to have special knowledge of builtin datatypes to enable
>the inference:
><foo://bar> ex:property _:x1
>_:x1 xsd:integer "10" .
><foo://baz> ex:property _:x2
>_:x2 xsd:octal "12" .
>>  >>  should or should not entail
><foo://bar> ex:property _:xxx .
><foo://baz> ex:property _:xxx .
>so aside from making Ntriples have a more compact syntax -- at the expense
>of a whole bunch of otherwise unrequired triples -- it seems that solutions
>resulting in a combinatorial triple explosion are popular among so called
>triple minimalists :-)

Adding a fractional linear extra number of extra triples is not a 
combinatorial explosion.

>aside from that, what is the difference?

See above.

>In order to get the obvious
>entailment, RDF would need to "know about" datatypes, but isn't that the
>point about datatypes that knowing the datatype allows you to _do something_
>with that knowledge?

Er....yes, but what is your point here? This applies to any style of 
datatyping in RDF.

>otherwise do you suggest that we try to derive all of mathematics, well all
>of natural number theory, from RDF triples, and this might be the RDF
>datatypes solution? --- you know where that argument is going :-)) --
>otherwise how do we represent the notion of "equality"? Am I missing

Not sure, but I certainly am missing something at this point. All we 
were arguing about was the best way to write something in RDF. One 
way uses current RDF syntax, the other requires a change to it. Other 
than that, they seem pretty much equivalent. Which to use? The answer 
seems kind of obvious.

>>  I guess I disagree. I see no clear upsides, and several downsides.
>>  Chiefly, I see extra syntactic complexity in the basic spec, for no
>>  real advantage in expressiveness or efficiency. Basically, small
>>  constant factors in numbers of triples are not worth bothering with.
>Well Ok, but where is the knowledge of how to compare datatype values to
>reside? In the intrinsic characteristics of triples?
>How will:
>foo bar _:x1 .
>_:x1 baz "10" .
>be different from:
>foo2 bar _:x2 .
>_:x2 xsd:decimal "10" .
>unless RDF has magic knowledge of the URIreference which "xsd:decimal"
>Is teaching RDF about numbers really this complicated?

If it were only numbers there would be no problem. Unfortunately we 
cannot assume that all numerals refer to numbers. Datatyping takes 
that decision away from the language and delivers it to the datatype

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Wednesday, 31 July 2002 18:40:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:38 UTC