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 沒有指出任何原始檔案或測試；首先針對一個空資源重現 SPARQL UPDATE PATCH 序列，並檢查伺服器對 SPARQL 更新和 RDF literal 的處理。完成的標準是：使用所回報的具型別 double literal 的等效 INSERT DATA 和 DELETE DATA 請求能夠始終成功，並且有一個回歸測試涵蓋該情況。