Dear Holger, Thanks. Yes, I think that explains sh:equals effect. But SPARQL is a mystery to have some that are correctly compared mathematically such as 1.123456 ; 1.123456 ; same 1.1234560 ; 1.1234561 ; different
and some that are totally wrong such as 100123456.1 ; 100123459 ; same 100123456.1 ; 100123459.0 ; same 100123456.0 ; 100123456.1 ; same Best regards Chavdar В 0:59:00 UTC+2на вторник, 18 август 2020 г. Holger Knublauch написа: > Since sh:equals is based on RDF node equality, values such as > "1.0"^^xsd:float and "1"^^xsd:float count as distinct. Maybe that's the > issue you are running into? > > SPARQL does comparison by (mathematical) values, so 1.0 = 1 there. > > Holger > > > On 17/08/2020 14:36, Chavdar Ivanov wrote: > > Dear Holger, > > > > Thanks. I will approach the other forum. > > Just to clarify – yes all literals were typed literals with datatype > float. So sh:equals was comparing float to float > > Did you mean that I should use xsd:decimal in the SPARQL query although in > data graph it is coming as float? > > Something like this > > ?var1 which is float in data graph > > ?var2 which is float in data graph > > xsd:decimal(?var1)!=xsd:decimal(?var2) > > > > Best regards > > Chavdar > > В 2:13:30 UTC+2на понеделник, 17 август 2020 г. Holger Knublauch написа: > >> >> On 11/08/2020 06:17, Chavdar Ivanov wrote: >> >> Dear all, >> >> I have a very basic question... >> I need to compare literals that are floats and tried to use two ways. 1) >> using sh:equals to compare 2 properties and 2) using SPARQL where I filter >> != different values >> >> For the filter I tried using >> FILTER (xsd:float(?value1)!=xsd:float(?value1)). >> or >> FILTER (?value1!=?value1). >> Both give the same outcome. >> >> Below I listed a summary of the tests I did >> >> I think sh:equals treats the literals as strings even though they are >> floats. It also gives 2 results. I thing this looks like according to the >> SHACL spec although I didn't if the sh:equals ignores the datatype. >> >> sh:equals will compare the RDF nodes, so the datatype will make a big >> difference and "1"^^xsd:float will be different from "1"^^xsd:string or >> integer. >> >> >> However In some cases the result form the SPARQL is kind of strange. It >> looks like the precision is 10-6, but for the big numbers and when >> scientific form on float number is used we have something different. >> >> What is followed to define the difference? >> If I use google calculator >> 100123456.1-100.123459E+06=-2.90000000596 >> >> Normally it should be OK to compare different forms of float. >> >> >> 1) using sh:equals in the property shape >> Value1 ; value 2 ; comparisson result >> 1.123456 ; 1.123456 ; same >> 1.1234560 ; 1.1234561 ; different (sh:equals reports it twice) >> 31.1234560 ; 31.1234561 ;different (sh:equals reports it twice) >> 30 ; 30.0000001 ; different (sh:equals reports it twice) >> 30 ; 30.000001 ; different (sh:equals reports it twice) >> 100123456.0 ; 100123456.1 ; different (sh:equals reports it twice) >> 100123456.0 ; 100123456.0 ; same >> 100123456 ; 100.123456E6 ; different (sh:equals reports it twice) >> 100123456 ; 100.123456E+06 ; different (sh:equals reports it twice) >> -0.123456789 ; -123.456789E-3 ; different (sh:equals reports it twice) >> -0.123456789 ; -123.456789E-03 ; different (sh:equals reports it twice) >> 100123456.1 ; 100.123456E+06 ; different (sh:equals reports it twice) >> 100123456.1 ; 100.123459E+06 ; different (sh:equals reports it >> twice) >> 100123456.1 ; 100123459 ; different (sh:equals reports it twice) >> 100123456.1 ; 100123459.0 ; different (sh:equals reports it twice) >> >> 2) using SPARQL (in the property shape) >> 1.123456 ; 1.123456 ; same >> 1.1234560 ; 1.1234561 ; different >> 31.1234560 ; 31.1234561 ;different >> 30 ; 30.0000001 ; same >> 30 ; 30.000001 ; different >> 100123456.0 ; 100123456.1 ; same >> 100123456.0 ; 100123456.0 ; same >> 100123456 ; 100.123456E6 ; same >> 100123456 ; 100.123456E+06 ; same >> -0.123456789 ; -123.456789E-3 ; same >> -0.123456789 ; -123.456789E-03 ; same >> 100123456.1 ; 100.123456E+06 ; same >> 100123456.1 ; 100.123459E+06 ; same >> 100123456.1 ; 100123459 ; same >> 100123456.1 ; 100123459.0 ; same >> >> In SPARQL you may be better off with xsd:decimal than xsd:float, as >> xsd:decimal has more precision. But this is more of a SPARQL/ARQ question >> for which you may get more qualified help elsewhere, e.g. on jena-users. >> >> Holger >> >> >> >> Best regards >> Chavdar >> -- >> You received this message because you are subscribed to the Google Groups >> "TopBraid Suite Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to topbraid-user...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/63a7e8ba-468e-4803-a1c4-31afca5d55e9n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/topbraid-users/63a7e8ba-468e-4803-a1c4-31afca5d55e9n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to topbraid-user...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/3c8ac02a-8d85-4657-b3b1-33c603447b2fn%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/3c8ac02a-8d85-4657-b3b1-33c603447b2fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1be2bd46-2d3b-46d8-8d68-2f1b3a0ac91an%40googlegroups.com.
