Trying to get pyomnigraph working with Virtuoso

Virtuoso Universal Server RDF Data Management
1

Trying to get pyomnigraph working with Virtuoso

Background

I’m developing pyomnigraph, a unified Python interface for multiple graph databases. The goal is to provide a consistent API across different triple stores (Blazegraph, Jena, QLever, GraphDB, Virtuoso, etc.).

Blazegraph, Jena, and QLever are working perfectly. Now trying to get Virtuoso integrated, but running into authentication/permission issues.

grafik
grafik2742×362 41.3 KB

Setup

Docker Container:

docker run -e DBA_PASSWORD=dba -e SPARQL_UPDATE=true -d --name virtuoso-omnigraph-test \
  -p 8890:8890 -v /path/to/data:/database openlink/virtuoso-opensource-7:latest

Environment verification:

$ docker exec virtuoso-omnigraph-test env | grep SPARQL
SPARQL_UPDATE=true

DBA user verification:

$ echo "SELECT U_NAME FROM SYS_USERS WHERE U_NAME='dba';" | docker exec -i virtuoso-omnigraph-test isql 1111 dba dba
# Returns: dba user exists

Problem

When trying to execute SPARQL DELETE operations via Python/SPARQLWrapper, getting permission errors:

Virtuoso 42000 Error SR186:SECURITY: No permission to execute procedure 
DB.DBA.SPARQL_DELETE_DICT_CONTENT with user ID 107, group ID 107

Attempted operations:

  1. CLEAR ALL → “No permission to execute procedure DB.DBA.SPARUL_CLEAR”
  2. DELETE WHERE { GRAPH <urn:virtuoso:default> { ?s ?p ?o } } → Same permission error

Code

Python/SPARQLWrapper setup:

from SPARQLWrapper import SPARQLWrapper, POST
sparql = SPARQLWrapper("http://localhost:8890/sparql")
sparql.setCredentials('dba', 'dba')  # Using DBA credentials
sparql.setMethod(POST)
sparql.setQuery("CLEAR ALL")
result = sparql.query()  # Fails with user ID 107 error

SPARQLWrapper correctly sends Basic authentication headers:

Authorization: Basic ZGJhOmRiYQ==  # base64(dba:dba)

Questions

  1. Why user ID 107? Despite sending DBA credentials, Virtuoso reports user ID 107 (seems like anonymous user)

  2. SPARQL endpoint configuration? Are there additional Virtuoso.ini settings needed for SPARQL UPDATE operations?

  3. Alternative endpoints? Should I use /sparql-auth or /sparql-graph-crud instead of /sparql?

  4. Docker-specific issues? Any known problems with SPARQL_UPDATE in containerized Virtuoso?

Goal

Need Virtuoso to accept SPARQL DELETE/CLEAR operations via HTTP POST with DBA authentication, just like other triple stores in the omnigraph ecosystem.

Any guidance would be greatly appreciated!

Environment:

  • Virtuoso: 07.20.3241 (latest Docker image)
  • Python: SPARQLWrapper library
  • Platform: Docker on Linux
2

The post Virtuoso user RDF Graph Level access to RDF Quad Store details the reason.

  • SPARQL endpoint configuration? Are there additional Virtuoso.ini settings needed for SPARQL UPDATE operations?

The default ~/sparql is readonly (SPARQL_SELECT role) for security reasons. To make it read/write then the SPARQL_UPDATE role needs to be granted, provide you aware of the security implications especially if it is publicly accessible.

  • Alternative endpoints? Should I use /sparql-auth or /sparql-graph-crud instead of /sparql?

Yes, the ~/sparal-auth should be used for authenticated access to the database, as a user with the appropriate SPARQL_UPDATE role assigned to allow such operations to be performed.

  • Docker-specific issues? Any known problems with SPARQL_UPDATE in containerized Virtuoso?

No, it behaves as Virtuoso would in an on-premise standalone or cloud deployment.

3

@Wolfgang_Fahl,

I noticed the following tabulation on your repo’s home page.

Database Status Strengths
Blazegraph :green_circle: Working High performance, easy setup
Apache Jena :green_circle: Working Robust, standards compliant
QLever :green_circle: Working Extremely fast queries
GraphDB :stop_sign: Planned Enterprise features, reasoning
Virtuoso :stop_sign: In Progress Mature, SQL integration
Stardog :stop_sign: Planned Knowledge graphs, reasoning
Oxigraph :stop_sign: Planned Rust-based, embedded

Regarding Virtuoso, its differentiators are as follows (in addition to obvious maturity):

  1. High-performance and scalability for SQL & SPARQL – which extends to reasoning and inference plus fine-grained attribute-based access controls
  2. Ability to use SPARQL via SQL thereby bringing SPARQL to existing SQL apps and services