Protecting a taxonomy from SPARQL updates

[Jessica Cleary-Kemp]

Hi Holger. I'm full of questions lately! We jus accidentally discovered that you can do CRUD operations via SPARQL outside of a workflow (i.e., directly in the production copy) even though we have our collections protected from UI changes. 

Is there a setting to disallow SPARQL updates directly to the production copy?

[Holger Knublauch]

Hi Jessica,

there is the global system configuration parameter to disable any UPDATEs.

But other than that, the SPARQL endpoint does honor the same graph permissions as the rest of the system. So if a user cannot modify the master graph (e.g. because she only has access to workflows) then SPARQL UPDATEs on those graphs will be rejected too. Do you have a counter example where updates are possible that bypass the graph-level security?

Holger

On Nov 8, 2025, at 05:47, Jessica Cleary-Kemp <jessica...@bold.com> wrote:

Hi Holger. I'm full of questions lately! We jus accidentally discovered that you can do CRUD operations via SPARQL outside of a workflow (i.e., directly in the production copy) even though we have our collections protected from UI changes. 

Is there a setting to disallow SPARQL updates directly to the production copy?

This email may contain material that is confidential, privileged, or for the sole use of the intended recipient.  Any review, disclosure, reliance, or distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended recipient, please contact the sender and delete all copies, including attachments.

--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/topbraid-users/6aff3115-bcf2-48ce-bf94-e472d9dbc40fn%40googlegroups.com.

[Jessica Cleary-Kemp]

Thanks for the explanation.

No I don't have a counter-example to that. Our expectation was that no one, regardless of their permission level, could make any changes to the production graph outside of a workflow when we selected "Protected". That's why we were surprised by the behavior.

You received this message because you are subscribed to a topic in the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/topbraid-users/vZlJ0GXHOUo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to topbraid-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/topbraid-users/BB323C95-FA13-435F-9870-44688F2F63D8%40topquadrant.com.

[Holger Knublauch]

Ah thanks, this explains it! The *protected* mode is only enabled for the user interface (as the description indicates) but programmatic access remains possible. One might argue whether that should expand to the SPARQL endpoint, or any other web services, but it is not a full protection. For that, you would need to use governance roles etc.

Holger

On Nov 11, 2025, at 03:52, Jessica Cleary-Kemp <jessica...@bold.com> wrote:

Thanks for the explanation.

No I don't have a counter-example to that. Our expectation was that no one, regardless of their permission level, could make any changes to the production graph outside of a workflow when we selected "Protected". That's why we were surprised by the behavior.

To view this discussion visit https://groups.google.com/d/msgid/topbraid-users/CA%2BqYWyX-yaLc7bT1mFKzEuyJ3diNM3Kg_Lk9agCZN_KmKmm0qw%40mail.gmail.com.