change: allow blank nodes to be inserted in N3 Patches

[jeswr]

In todays CG and SolidOS calls we discussed this change, to allow blank node insertions in N3 patches.

In both cases, all present members saw no reason why blank node insertions should be forbidden. @bourgeoa indicated that it was likely a mistake, rather than an intentional decision to forbid blank node insertions in the spec.

If you have any objections to this change, please raise them in this PR. If no objections are raised, this PR will be merged 10 days from now.

Context:

• Inserts in n3patch may contain Blanknodes : Forbidden by CSS from N3PATCH spec linkeddata/rdflib.js#659 (comment)
• N3 Patch contradiction about blank nodes: can they be part of ?insertions? #704

cc @csarven @bourgeoa @CxRes @timbl @lecoqlibre

[csarven]

Some comments and a question before I can proceed with a technical review:

In https://lists.w3.org/Archives/Public/public-solid/2025Jan/0028.html , I asked:

Has the Solid CG recently decided to continue working on (some or all) items that are also part of the LWS WG charter deliverables?

The position of the Solid CG was stated in https://lists.w3.org/Archives/Public/public-solid/2025Jan/0044.html :

The general understanding is that only the core Solid Protocol report is currently an input of the WG.

My understanding of this is that the Solid Protocol is not something the Solid CG will continue to work on. However, this PR, along with the decision made during the Solid CG meeting on 2025-02-05 (minutes under review), appears to conflict with that understanding as per the Solid CG charter's Out of Scope section:

Community Group’s Work Items that have transitioned to a deliverable of an active Working Group.

This is further complicated by an unnecessary/redundant "decision" - since the charter had already ruled it out of scope - made in the 2024-09-11 meeting, literally:

PROPOSAL: CG stops working on the Solid Protocol draft

• MdJ: +1
• eP: +1
• PAC: +1

RESOLUTION: CG stops working on the Solid Protocol draft

This sends mixed signals. I ask once again: Is the Solid CG working on reports like the Solid Protocol or not?

• If yes, the CG's "final" decision should also be reflected in the CG charter and communicated to LWS WG. I'm happy to review if that understanding is made clear, with prior consent to review and edit.
• If not, then this PR can remain open but unmerged (while still collecting data, additional implementation reports, reviews etc.)

Please also note that as per Solid CG Contribution Guidelines, I believe this PR qualifies as a Class 3 change. If you believe it falls under a different category, please indicate that in the PR comments. Assuming it is a Class 3 change, it would be best to follow the guidelines to processing PRs - in this case, allowing "within 10 days or 2 meetings" to provide sufficient time for review.

[jeswr]

"within 10 days or 2 meetings" to provide sufficient time for review.

Good shout - I've updated the timeline in the original message.

Is the Solid CG working on reports like the Solid Protocol or not?

My interpretation (including the 2024-09-11 resolution) is that the CG should focus energy on deliverables outside of LWS scope; and thus not be actively working on the CG spec - however, this does not mean that the CG spec is locked.

This change would fix an active blocker in the solidcommunity.net migration of NSS -> CSS, and land before the LWS starts to actively use the input documents such as the CG spec - since LWS is still in use-case and requirements stages; so pragmatically I think it is a good idea for the change to be made now if there are no objections on technical grounds.

[elf-pavlik]

I would propose to keep the issue focused on technical conversation and move all the process-related chat to mailing list thread https://lists.w3.org/Archives/Public/public-solid/2025Feb/0019.html

[csarven]

Jesse, I find your interpretation of the charter's out of scope section and the resolution "CG stops working on the Solid Protocol draft" as meaning the spec isn't locked rather unusual. If the intent was simply to indicate that the spec isn't locked so to speak, there could've been many other, clearer ways to express that. See also this bit leading to that proposal/resolution:

• MdJ: We always said we just keep going until WG gets formed. Would the CG stop working on the core spec? I think that would make sense.
• PAC: Formally there is specific version of the Solid Protocol that is mentioned in the charter. It makes sense not to update that report. Some nit-picky people might object taking a more recent version. We don't need this kind of discussion. I think this is only one that should be frozen. The rest is mentioned as tentative and WG will decide as they go.

But, who exactly shouldn't be actively working on it? https://github.com/solid/specification/commits/main/ED/protocol.html

And if that's the case, isn't it strange that only three people in the entire CG voted "CG stops working on the Solid Protocol draft" on the spot, without consulting the actual primary contributors to the specification? I'm not asking you to justify it. If the intent wasn't to lock, what did the resolution even achieve given CG charter's out of scope?

This seems part of a broader pattern, particularly with the reluctance to move things forward in the Solid CG before the LWS WG charter was approved. For instance, see the concerns as mentioned here:
#227 (comment)

---

Pavlik, there's no reason why process-related comments can't be made here especially in this case when I'm raising concerns about mixed signals regarding the process for handling updates to certain specs. And when merge dates are being mentioned, it's better to err on the side of caution.

In any case, I've proposed a simple approach for mutual understanding between the LWS WG and Solid CG here: https://lists.w3.org/Archives/Public/public-lws-wg/2025Feb/0000.html

That'd be all I have to say on process here and happy to follow up once the mutual understanding is accepted/rejected.

[csarven]

Leaning on SPARQL Update and SPARQL Query for some guidance pertaining to INSERT and blank nodes, SPARQL Update doesn't prohibit INSERT's with blank nodes, but there are some expectations on how they are applied, e.g.:

https://www.w3.org/TR/2013/REC-sparql11-update-20130321/#insertData states:

Blank nodes in QuadDatas are assumed to be disjoint from the blank nodes in the Graph Store, i.e., will be inserted with "fresh" blank nodes.

Only blank nodes seem to be disallowed in DELETE, https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#sparqlGrammar :

8. Blank node syntax is not allowed in DELETE WHERE, the DeleteClause for DELETE, nor in DELETE DATA.
9. Rules for limiting the use of blank node labels are given in section 19.6.

https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#grammarBNodes :

The same blank node label can not be used in:
two INSERT DATA operations within a single SPARQL Update request

https://www.w3.org/TR/2013/REC-sparql11-update-20130321/#deleteInsert :

Blank nodes that appear in an INSERT clause operate similarly to blank nodes in the template of a CONSTRUCT query, i.e., they are re-instantiated for any solution of the WHERE clause;

So, as far as I can tell (and my hunch), removing ?insertions would at least better align with SPARQL Update.

---

As I see it, this is a class 3 change:

makes conforming data, processors, or other conforming agents become non-conforming according to the new version
makes non-conforming data, processors, or other agents become conforming

So, it is not a conformance issue for conforming client implementations that were not using blank nodes in INSERT. They can continue to work as they currently do but now have the option to include blank nodes in their INSERT queries.

As for previously non-conforming servers, i.e., the ones that were processing INSERT queries with blank nodes, with this change, they become conforming.

As for previously conforming servers, i.e., the ones that were not processing INSERT queries with blank nodes, with this change, they would become non-conforming. They have two general options: either implement to allow blank nodes in INSERT (successful response) or continue to run with reduced capability but make sure to reject payloads including INSERT and blank nodes with 405 or 415.

---

It is useful to be able to insert statements with blank nodes. Approving the PR based on the above. If there is information that's being overlooked as to why this change shouldn't be made, it'd be good to review that as well.

---

If not already, perhaps the N3 Patch tests can take the following into account from SPARQL Update's INSERT DATA ( https://www.w3.org/TR/2013/REC-sparql11-update-20130321/#insertData ).

Blank nodes in QuadDatas are assumed to be disjoint from the blank nodes in the Graph Store, i.e., will be inserted with "fresh" blank nodes.