`BigDecimal` literals with no fractional part format as `xsd:integer`, not `xsd:decimal`

[tlaundal]

First of all: thanks for creating this great library!

I've run into a problem which I think comes down to flint incorrectly handling BigDecimal literals with no fractional part.

Take this example query:

(flint/format-query
 {:select '[?s]
  :where [['?s '?p (bigdec 1)]]}

This currently (flint 0.3.0) produces SELECT ?s WHERE { ?s ?p 1 . }.
I think it should produce SELECT ?s WHERE { ?s ?p "1"^^xsd:decimal . }.

The reason is that 1 is interpreted as "1"^^xsd:integer, which is a different literal from "1"^^xsd::decimal. This means a pattern like ['?s '?p (bigdec 1)] in flint generates SPARQL which doesn't match triples with the object literal "1"^^xsd::decimal. Flint does emit 1.0 for (bigdec 1.0) which is interpreted as "1.0"^^xsd:decimal, but that is still considered a different literal from "1"^^xsd:decimal, so it doesn't fix the query.

[milt]

Hi @tlaundal thanks for the issue. We owe this library to the talented @kelvinqian00 but we try to maintain it as best we can. In the short term I'd suggest using the :force-iris? true argument to append IRIs to all string, numeric, and boolean literals. In the longer term we'll probably want to treat these like we do date/time literals and always force iris on them.

[tlaundal]

What I've done as a workaround is to extend the flint Literal protocol for BigDecimal and set :force-iris? if there is no decimal part. I think that's nice, because it still gives "minimal" SPARQL where the IRIs don't need to be explicit.

(extend-type java.math.BigDecimal
  p/Literal
  (-valid-literal? [_] true)
  (-format-literal
    ([n] (p/-format-literal n {}))
    ([^java.math.BigDecimal n opts]
     (flint-format/format-literal n (assoc opts :force-iri? (<= (.scale n) 0)))))
  (-format-literal-strval [n] (str n))
  (-format-literal-lang-tag [_] nil)
  (-format-literal-url
    ([n] (p/-format-literal-url n {}))
    ([_ opts] (flint-format/format-xsd-iri "decimal" opts))))

[milt]

I think this is probably the approach we will adopt for the library, thanks. I'll keep this open til we have a pull worked up.