Skip to content

Add Note about use of IRIs and Blank Nodes and update example#138

Open
csarven wants to merge 1 commit into
mainfrom
note-iri-blank-node
Open

Add Note about use of IRIs and Blank Nodes and update example#138
csarven wants to merge 1 commit into
mainfrom
note-iri-blank-node

Conversation

@csarven

@csarven csarven commented Jun 3, 2026

Copy link
Copy Markdown
Member

This is a correction class 2 change adding a Note about IRI and Blank Node use ( #iri-blank-node ). It encourages use of IRIs over Blank Nodes as some systems may not be able to perform operations over blank nodes, e.g., deleting a blank node. The PR also updates the conditions example ( #match-accessto-agent-mode-conditions )

Preview

@csarven csarven force-pushed the note-iri-blank-node branch from b3ddd34 to 62af97f Compare June 3, 2026 13:52
@uvdsl

uvdsl commented Jun 3, 2026

Copy link
Copy Markdown
Member

Out of curiosity:
Do you have an example for systems that have problems with e.g. deleting a blank node?
Is there a particular reason why those systems are unable to execute this operation?

@csarven

csarven commented Jun 3, 2026

Copy link
Copy Markdown
Member Author

Deleting is necessary to update an Authorization or to remove an Authorization altogether. Right now that could happen in two places that may be using blank nodes: [ a acl:Authorization ] and acl:condition [ ... ].

AFAICT, in the context of some patching mechanisms like SPARQL Update and Solid Protocol's N3 Patch, neither supports deleting statements including a blank node.

Since WAC is not tied to a resource protocol, it is best to discourage this scenario altogether I think with a Note.

As for alternative ways of modifying statements, e.g., PUT, this Note wouldn't be a concern.

A stronger constraint for WAC may be to always require use of IRIs... but that may be a bit more nuclear than necessary at this time =)

@uvdsl

uvdsl commented Jun 3, 2026

Copy link
Copy Markdown
Member

I thought that N3 patch (and I am fairly sure SPARQL update behaves similar) only disallows using blank nodes in the query/patch (i.e. in the syntax of the query/patch) but it is absolutely possible to match a variable in the query/patch to blank nodes in the RDF dataset, e.g. authorizations or conditions (i.e. in the data itself).

@csarven

csarven commented Jun 3, 2026

Copy link
Copy Markdown
Member Author

Perhaps I'm mistaken but I had this in mind:

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

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

https://solidproject.org/ED/protocol#server-patch-n3-blank-nodes :

The ?deletions formula MUST NOT contain blank nodes.

@uvdsl

uvdsl commented Jun 3, 2026

Copy link
Copy Markdown
Member

Yes, that is for the query/patch itself - but this does not mean that blank nodes (in the RDF graph being updated/queried, e.g. from _:n0 q acl:Authorization ) are not matched by variables in the query/patch...

I don't think you need to discourage the use of blank nodes in WAC based on whether or not blank nodes are allowed to occur in a query/patch. Or do you have a particular example maybe?

@csarven

csarven commented Jun 3, 2026

Copy link
Copy Markdown
Member Author

I generally agree about the distinction you're making but I worry that if some clients insert bnodes, it won't be possible to delete them via some mechanisms. Am I missing something else that you're saying or is it primarily about model vs. protocol?

For now, I've noted the scenario in dokieli's implementation at https://github.com/dokieli/dokieli/blob/main/src/dialog.js#L1261, i.e., dokieli will only delete a condition with a IRI value. If dokieli encounters a blank node, it will not attempt to delete it. The other parts of an Authorization rule is deleted so the Authorization will no longer conform.

@uvdsl

uvdsl commented Jun 4, 2026

Copy link
Copy Markdown
Member

Okay, thank you. Yes, my distinction is between (a) the syntax of the query/patch and (b) the evaluation semantics of that query/patch.

I worry that if some clients insert bnodes, it won't be possible to delete them via some mechanisms.

I believe your concern to target the evaluation rather than the syntax of the query/patch. Do I read that right?

In that case:
https://solidproject.org/TR/protocol#server-patch-n3-semantics outlines that first the WHERE clause is evaluated against the RDF dataset to produce variable-mappings (without limiting generality re blank nodes being mapped to variables). If then only one solution mapping exists, that solution mapping is used to replace variables with their mapped value in INSERTS and DELETES. Then:

  1. The triples resulting from ?deletions are to be removed from the RDF dataset.

Which to my reading does not make a statement about whether or not blank nodes were mapped to variables in the WHERE clause.

Hardcoding blank nodes into the DELETES (or INSERTS) is forbidden for an N3 patch, and for SPARQL update iirc the sets of blank nodes from the query and from the graph store are disjoint, meaning that you cannot "directly" target a blank node in a query/patch. "direct" as in writing it down. But mapping it to a variable as described above should be possible in my mind.

See also https://www.w3.org/TR/sparql11-update/ Section 4.2.4
DELETE { ?S ?P ?O . } WHERE { ?S ?P ?O . FILTER ( isBlank(?S)) }


EDIT PS: Just tried patching (with blank nodes mapped to variables from where in inserts and deletes ) on solidcommunity.net and that worked fine. The older versions of CSS might be buggy... Have not tested with other servers but CSS/Pivot seems to behave as I would expect it to behave.

@uvdsl

uvdsl commented Jun 4, 2026

Copy link
Copy Markdown
Member

Maybe to give a reason not to discourage blank nodes is that blank nodes are server-managed (when patching at least). If you encourage clients to use IRIs, then there is a chance of IRI collision (potentially unlikely maybe, but still):

If client 1 sets a rule <#123> for agent A with write mode and client 2 happens to set a rule for agent B with only append mode but then happens to also choose <#123> for their rule, then agent B will have write access instead of only append.

Personally, I do use IRIs with freshly minted (clientside) UUIDs on the for my authorizations - which I thought to be good enough. But I guess to be sure, I should also check for collisions there...

I think you CAN encourage use of IRIs over use of blank nodes, but then maybe this additional consideration re collision might be worth adding?

@bourgeoa

bourgeoa commented Jun 4, 2026

Copy link
Copy Markdown
Member

I find strange to see this note that again raises blank nodes being an issue in RDF. PATCH.
I think that server are or not compliant.
If they cannot treat the PATCH they should reject it.
NSS and PIVOT use Rdflib for PATCH and can treat SPARQL Update with blank node mapped to variables.

All Solid servers allow owner to repair broken ACL.

From a user readability point of view blank nodes are a big + for manual editing in turtle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants