Inserts in n3patch may contain Blanknodes : Forbidden by CSS from N3PATCH spec

[bourgeoa]

@timbl @michielbdejong @angelo-v
The solidcommunity.net migration tests from NSS to CSS an issue with N3PATCH returning error 422 appeared
N3PATCH spec do not allow BlankNodes to the contrary of SPARQL and RdfLiB allows BlankNodes when anonymize is not possible

RdfLib update manager can create PATCH with SPARQL or N3PATCH depending on Accept-Patch header
and seems to priorise N3PATCH

For both PATCH the algorithm takes [delete, inserts] array statements

• try to anonymize the blankNodes.
• to do that it creates a bnodes_context, and creates a Where clause with ?conditions and then replaces related Blanknodes by ?conditions in inserts/deletes

This do not cover the cases where no Where clause is possible.
This is an example of just inserts in a turtle list :

@prefix solid: <http://www.w3.org/ns/solid/terms#>.
@prefix ex: <http://www.example.org/terms#>.

_:patch

      solid:inserts {
        <https://solidos.solidcommunity.net:8443/Contacts/Person/f3360ff9-98dc-43ab-8f40-4d7202805dc3/index.ttl#this> <http://www.w3.org/2006/vcard/ns#url> _:n821 .
        _:n821 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2006/vcard/ns#WebID> .
        _:n821 <http://www.w3.org/2006/vcard/ns#value> "https://bourgeoa1.solidcommunity.net/profile/card#me" .
      };   a solid:InsertDeletePatch .

Here there is no way to create a bnodes_context for a Where clause.

There seems to be different solutions :

1. in RDFLib revert to SPARQL if N3PATCH solid:inserts is created with BlankNodes
2. modify the mashlib apps with inserts containing BlankNodes (contacts-pane, trusted app creation, ..) with statistical NamedNodes (_:821 --> :1234567 there is a PR for Avoid BlankNodes inside PATCHes SolidOS/solid-panes#390 related to Trusted Apps
3. modify RdfLib to replace remaining blankNodes in inserts with statistical Named nodes

ref 1. is not really Solid compliant because SPARQL is not a Solid spec but will work in NSS and CSS. This could be a mi-term solution
The advantage is that it makes turtle more friendly human readable. Lists are easier to read.

ref 2. imply to modify any mashlib apps to not use BlankNodes with lists when PATCH is involved at a latter stage

ref 3. Do not imply any app modification and could be easier to follow in future spec evolution

solutions 1. and 3. are at RdfLib level
solution 2. is at any apps level using RdfLib update manager

[timbl]

The ability to be able to patch a graph with blank nodes by putting variables in for blank nodes and including a where clause to indirectly identify them in context is important.

Is the issue here

1. This works with SPARQL but not with N3 Patch?

or

2. That there is a graph where the indirect identification process (nailig) is not possible?

Please give the (relevant pits of) initial graph in this case.

[timbl]

If (2) then we could in the short term we should in short term only use SPARQL patch for the case with a where clause, and in the medium term add the where functionality to N3 patch

If (1) then I am surprised, as in practice there tends to be a way of doing this.

[bourgeoa]

@timbl thanks for your comments

I suppose my issue was badly written.

• RdfLib creates SPARQL an N3PATCH following the same algorithm. This can be seen in the tests
• in both cases Where clause is created when possible
• in Inserts there is no anonymize in both case (This is our issue with CSS)
  • SPARQL

    rdflib.js/tests/unit/update-manager-sparql-insert-test.ts

    Lines 63 to 73 in 82f693d

    	it('does not anonymize triples in INSERT DATA query', async () => {
    	updater.anonymize = sinon.spy();
    	const bNode = new BlankNode('subj');
    	const st1 = st(bNode, predicate, subject, subject.doc())
    	await updater.update([], [st1])
    	expect(updater.anonymize).to.not.have.been.called;
    	expect(getPatchCall().lastArg.body).to.equal(`INSERT DATA { _:subj <https://pod.example/test/foo#predicate> <https://pod.example/test/foo#subject> .
    	}
    	`)
    	});

  • N3PATCH

    rdflib.js/tests/unit/update-manager-n3patch-insert-test.ts

    Lines 84 to 99 in 82f693d

    	it('does not anonymize triples in INSERT DATA query', async () => {
    	const bNode = new BlankNode('subj');
    	const st1 = st(bNode, predicate, subject, subject.doc())
    	await updater.update([], [st1])
    	// expect(updater.anonymize).to.not.have.been.called;
    	expect(getPatchCall().lastArg.body).to.equal(`
    	@prefix solid: <http://www.w3.org/ns/solid/terms#>.
    	@prefix ex: <http://www.example.org/terms#>.
    	_:patch
    	solid:inserts {
    	_:subj <https://pod.example/test/foo#predicate> <https://pod.example/test/foo#subject> .
    	}; a solid:InsertDeletePatch .
    	`)
    	});

The issue is that CSS following the N3PATCH spec forbid BlankNodes in Inserts returning a 422 error

• spec line https://solidproject.org/ED/protocol#server-patch-n3-blank-nodes
• this spec issue was also raised in N3 Patch contradiction about blank nodes: can they be part of ?insertions? solid/specification#704

[timbl]

So is the issue that we just need to get N3Patch to allow blank nodes in inserted statements?

And continue to allow variables in deleted statements and inserted statements with a where.

[bourgeoa]

So is the issue that we just need to get N3Patch to allow blank nodes in inserted statements?

And continue to allow variables in deleted statements and inserted statements with a where.

Yes.

[michielbdejong]

Of the 3 options, I would vote for:

2. modify the mashlib apps with inserts containing BlankNodes (contacts-pane, trusted app creation, ..) with statistical NamedNodes (_:821 --> :1234567 there is a PR for Avoid BlankNodes inside PATCHes SolidOS/solid-panes#390 related to Trusted Apps

If mashlib is adding in the forbidden BlankNodes then that is where the bug is. Rdflib could throw an error when mashlib does this. But mashlib should still stop doing it. :)

I changed it in one place, you can see in how simple the change is. Should not be a lot of effort to do the same thing in the remaining places?

[bourgeoa]

In SolidOS/Rdflib the actual workflow is the following :

• SolidOS apps calls update-manager with inserts and deletes
• update in Rdflib creates an SPARQL-update or N3-patch query
  • create a WHERE clause by querying bnodes from inserts and deletes,
    • if matches replace with ?conditions
    • else keep bnodes
  • return a SPARQL-update or N3-patch document to the server
• server apply PATCH to the document
  Patch implementation depend on the server
  • NSS and PIVOT use Rdflib
  • CSS uses communica and n3.js and reject bnodes in insertions