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.

Payload không nêu tệp mã nguồn hay các bài kiểm thử nào; hãy bắt đầu bằng cách tái hiện chuỗi SPARQL UPDATE PATCH trên một tài nguyên rỗng và kiểm tra cách máy chủ xử lý cập nhật SPARQL và literal RDF. Được xem là hoàn tất khi các yêu cầu INSERT DATA và DELETE DATA tương đương sử dụng các literal double có kiểu được báo cáo đều thành công một cách nhất quán, với một bài kiểm thử hồi quy bao quát trường hợp này.