Inconsistent handling of typed literals in sparql-update

El payload no menciona archivos fuente ni pruebas; empieza reproduciendo la secuencia SPARQL UPDATE PATCH contra un recurso vacío e inspecciona el manejo de actualizaciones SPARQL y literales RDF del servidor. Se considera terminado cuando solicitudes equivalentes INSERT DATA y DELETE DATA con los literales double tipados indicados se ejecuten correctamente de forma consistente, con una prueba de regresión que cubra el caso.

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.