Inconsistent handling of typed literals in sparql-update

payload 没有指出任何源文件或测试；首先针对一个空资源复现 SPARQL UPDATE PATCH 序列，并检查服务器对 SPARQL 更新和 RDF literal 的处理。完成的标准是：使用所报告的带类型 double literal 的等效 INSERT DATA 和 DELETE DATA 请求能够始终成功，并且有一个回归测试覆盖该情况。

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.