search

TopQuadrant / shacl

SHACL API in Java based on Apache Jena
Apache License 2.0
217 stars 61 forks source link

[Question] Integration with Fuseki #141

Closed lolgab closed 2 years ago

lolgab commented 2 years ago

Since this tool is based on Jena, would it be possible for it to implement a Jena Reasoner to be used in Fuseki? I'm trying to learn Jena Rules but having a new standard like SHACL Rules would be really great.

HolgerKnublauch commented 2 years ago

I have never really looked into the details of the Jena Reasoning interface, but if it's (only) based on the Jena rules syntax then it wouldn't work well with SHACL-AF rules. Also it would be hard to do rule chaining this way, i.e. the only realistic implementation strategy would be to compute all inferences at once and then add them to a sub-graph (of a MultiUnion) just like the command line tool does.

lolgab commented 2 years ago

Sorry, I'm not familiar with how the shacl command line works. Do you think it's possible some kind of integration between this project's shacl rules and Fuseki? Anyway, it seemed too nice to be true :-) Thank you for your answer

HolgerKnublauch commented 2 years ago

I cannot comment on Fuseki as I have never used it. Unless @afs has input here, you may want to move this topic to the Jena-users mailing list and we close the ticket here?

lolgab commented 2 years ago

Yes, it's reasonable. Thank you!

afs commented 2 years ago

The runtime data-access interface to Jena inference is the Graph.find. There is no special access API to the inferred data; just the inf graph.

The jena inference engine is (roughly speaking) a datalog engine. SHALC-AF rules can't be written as datalog (no shapes as rule body).

So this is not really a Jena question.

Is the question is really "How do I have a graph with SHALC-AF rules in Fuseki?" That's a question for this project.

Answer: "yes" - if someone writes some code, not much but some.

It needs an assembler to provide the implementation best delivered as a Fuseki module.

Answer: "... but".

The only choice is apply all the AF rules each time. A read-only graph, running SHACL rules at start-up, for example.

Updates could be "rerun everything" because TQ-SHACL does not do incremental execution but only goes so far.

There are lots of special cases for update (probably most of the real world cases) that can be supported incrementally, but as a shape can be "SPARQL anything" or arbitrary depth away from the target, some shapes can not be assessed for incremental triggers.

lolgab commented 2 years ago

Thank you very much for your answers. In the end, I changed my application to use Jena directly instead of forwarding requests to Fuseki. I already wrote a working SHACL Rule which is a great success for me. 🙂 I'm still at the prototype stage so I'm using only read-only data, so I didn't face the problem of re-applying the rules once the data changes. Since my application is small and I don't have much data, and either high-performance goal, I could rerun RuleUtils.executeRules on every update even if it's not incremental.