Inconsistent handling of typed literals in sparql-update

TL;DR

Subsequent INSERT DATA and DELETE DATA of the same triple with object "1234.56789e0"^^<http://www.w3.org/2001/XMLSchema#double> leads to response status 409 Conflict.

edit: The first request actually contained "1234.56789"^^<http://www.w3.org/2001/XMLSchema#double>, and the second one contained "1234.56789e0"^^<http://www.w3.org/2001/XMLSchema#double>. Please notice the e0 difference.

actual behavior

I send a patch request on an empty or non-existent resource (newlines added for easier readability):

curl 'https://testuser.solidcommunity.net/path/to/resource' \
-X PATCH \
[...]
-H 'content-type: application/sparql-update' \
-H 'authorization: DPoP [...]' \
-H 'dpop: [...]' \
[...]
--data-raw $'INSERT DATA {
    <https://testuser.solidcommunity.net/path/to/resource#location>
        <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
            <http://www.w3.org/2003/01/geo/wgs84_pos#Point> .

    <https://testuser.solidcommunity.net/path/to/resource#location>
        <http://www.w3.org/2003/01/geo/wgs84_pos#lat>
            "60.235039190740146"^^<http://www.w3.org/2001/XMLSchema#double> .

    <https://testuser.solidcommunity.net/path/to/resource#location>
        <http://www.w3.org/2003/01/geo/wgs84_pos#long>
            "24.941368103027344"^^<http://www.w3.org/2001/XMLSchema#double> .
}'

And a resource with the following content is produced:

@prefix : <#>.
@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>.

:location
a geo:Point; geo:lat 60.235039190740146e0; geo:long 24.941368103027344e0 .

Please note that typed literals were replaced with numbers.

Then i send another request (INSERT DATA changed to DELETE DATA):

edit: actually, there is additional small difference, the numbers also end with e0. when the e0 is removed, the request passes with 200 and data get deleted correctly. So NSS may behave consistently after all.

curl 'https://testuser.solidcommunity.net/path/to/resource' \
-X PATCH \
[...]
-H 'content-type: application/sparql-update' \
-H 'authorization: DPoP [...]' \
-H 'dpop: [...]' \
[...]
--data-raw $'DELETE DATA {
    <https://testuser.solidcommunity.net/path/to/resource#location>
        <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
            <http://www.w3.org/2003/01/geo/wgs84_pos#Point> .

    <https://testuser.solidcommunity.net/path/to/resource#location>
        <http://www.w3.org/2003/01/geo/wgs84_pos#lat>
            "60.235039190740146e0"^^<http://www.w3.org/2001/XMLSchema#double> .

    <https://testuser.solidcommunity.net/path/to/resource#location>
        <http://www.w3.org/2003/01/geo/wgs84_pos#long>
            "24.941368103027344e0"^^<http://www.w3.org/2001/XMLSchema#double> .
}'

and the request fails with status code 409 Conflict and body

The patch could not be applied. Could not find to delete: <https://testuser.solidcommunity.net/path/to/resource#location> <http://www.w3.org/2003/01/geo/wgs84_pos#lat> "60.235039190740146e0"^^<http://www.w3.org/2001/XMLSchema#double> .
 or <https://testuser.solidcommunity.net/path/to/resource#location> <http://www.w3.org/2003/01/geo/wgs84_pos#long> "24.941368103027344e0"^^<http://www.w3.org/2001/XMLSchema#double> .

When typed literals are changed to numbers, response is 200.

expected behavior

Sending subsequent INSERT DATA {} and DELETE DATA {} with identical body should succeed.

Either the server should save the typed literal as typed literal, or it should treat typed literal "double" and number as identical for the purposes of DELETE DATA. Intuitively, the former feels more correct.

NSS version

Account on https://solidcommunity.net (2023-03-17)

Name
    solidcommunity.net
Description
    An experimental solid server run by the community
Details
    Running on [Node Solid Server 5.7.6](https://github.com/solid/node-solid-server/releases/tag/v5.7.6)

further note

Both requests were produced by Comunica. If we want to keep using the library, we have little control over the queries produced.

This may also be an issue with Comunica itself, since it might be creating incorrect DELETE DATA query - with typed literals, not numbers.

All depends on whether "1234.56789e0"^^http://www.w3.org/2001/XMLSchema#double and 1234.56789e0 are equivalent in RDF. idk whether they are.

Regardless, this is an issue with NSS.

The payload names no source files or tests; start by reproducing the SPARQL UPDATE PATCH sequence against an empty resource and inspect the server's SPARQL update and RDF literal handling. Done means equivalent INSERT DATA and DELETE DATA requests using the reported typed double literals succeed consistently, with a regression test covering the case.