Validating unintrusively a TripleStore

[Eugen Costezki]

Hi guys, 

 I wrote a wrapper around SHACL API, which works like charm, to validate a set of flies from a folder. 

The folder is expected to contain the target data-sets, the import ontologies and the shape-file(s).

This scenario is fairly easy to implement and it event works for "slightly larger" data-sets (but not too large).

To overcome that problem and eventually the next challenge in writing the validator would be to move towards a different architecture/validation scenario:  (*) first, use a triple store as the source of the data-sets and ontologies; (*) second, still use a file containing the SHACL shapes; (*) third still run a command line validator which takes as parameters the shape file and the sparql endpoint (or any other means to connect to the triple store) and produce the validation results. 

Would such scenario would be feasible, at least in theory, and if so what would be the approach to implementing it? 

Sincerely,

 Eugeniu 

[Holger Knublauch]

Hi Eugen,

the TopBraid SHACL validator assumes that the data graph is a (Jena) Graph in a dataset. There is no built-in facility to talk to a SPARQL endpoint instead. This would primarily require redirecting the places where the SPARQL SELECT queries are executed, so that they are either wrapped with a SERVICE keyword or otherwise use a remote query execution. This is likely causing complications with the pre-binding of variables. And then there are issues such as making sure that the SPARQL end point has the same set of built-in SPARQL functions than the local machinery, e.g. the sh:hasShape function.

So I don't see a straight-forward solution with the current code base. Future versions may support this out of the box, but I have no plans to work on this in the foreseeable future.

Technically, it is possible to wrap any SPARQL end point with a Jena Graph so that all findSPO queries are redirected to matching SELECT ?s ?p ?o queries. This would theoretically allow you to reuse the current engine, albeit with very slow performance, and without support for blank nodes (which are a general limitation of the SPARQL end point protocol).

HTH
Holger

--
You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include the TopBraid Suite family of products and its base technologies such as SPARQLMotion, SPARQL Web Pages and SPIN.
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.
For more options, visit https://groups.google.com/d/optout.