What are the exactly query/update endpoint paths of GraphDB?

Every triplestore has different interfaces. In GraphDB the typical query-interface is http:///repositories/ where is the url of the graphdb interface which must be reachable from your drupal instance - so be careful with things like localhost and docker containers. is the name of the repository you supply when creating a new repository in the graphdb interface. So e.g. http://example.com/repositories/example-repo would be a valid query url if graphdb would be installed on example-com and somebody would have created a repo called "example-repo".

The update-interface is the same as the query-interface with /statements at the end. This is absolutely graphdb-specific!

We don't do Sparql Graph Store Protocol, we do Sparql queries (https://www.w3.org/TR/sparql11-query/) with SPARQL 1.1 update. I don't know why you would want to use the Sparql Graph Store Protocol? But perhaps you can enlighten me :)

In virtuoso it is more complicated. The typical SPARQL interface is located at your-virtuoso-server-instance:8890/sparql and /sparqlauth. However the authentication is proprietary and WissKI can't handle that yet, so you would have to enable the correct privileges for /sparql to do updates.

@knurg Thank you for your detailed explanation and sorry for replying late.
I asked this question here because I'd like to use WissKI and rdf_sync module together, the latter only supports Openlink Virtuoso and has a configuration of "Graph store path". If WissKI also supports Openlink Virtuoso, it would be great.

For me, I can disable SPARQL auth and accept anonymous writing access in Openlink Virtuoso, because I can use IP/TCP to only allow localhost access.

Thank you again!

I don't understand why you want to do that - WissKI stores all its information in the triplestore anyway and can connect to any triplestore... what do you see as a profit in using rdf_sync?

You are right. But there are other stuff besides WissKI paths in my Drupal, which are required to synchronize to triple store.

Can you give me an example, so I understand the problem better? :)

@knurg For example, the schemadotorg module can create https://schema.org -compliant RDF triples with the rdf_sync module. It's very hard to use WissKI pathbuilders to make it. I need both features and store them both in a single tirple-store server.

Then let's just create a schema.org WissKI-module. I think you have the perfect usecase for that. Fiddling around with third party modules and make them work together won't be persistent when things update... :)

Can you provide more information about your usecase?

The schemadotorg module is much easier to use and has other many advantages :-)
Of couse, the rdf_sync is applicable for all Drupal native entities, while WissKI is only applicable for ontology-based pathbuilders.

Ok, so you know where to find me if you change your mind :)

@knurg Thank you all the same for taking time to talk with me!