Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rdf4j-dev] SHACL rule inference
We should definitely look into reusing current algebra implementations for SHACL.  Unlike current query engines that only allow you to query one sail, SHACL queries 4 (added, removed, base as seen before transaction and base as seen after transaction). That, and a lack of knowledge of how the current algebra implementation works has hindered me. 

Most of the operations run against memory stores, and the ones that run against the base sail are mostly batched. 

For simplicity and performance, the algebra implementation assumes ordered data. Unfortunately the memory store implementation is not naturally ordered, so each query needs to be sorted. 

I will start with something quick and simple with SPARQL.

Håvard

On 31 Oct 2018, at 22:29, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:

A thing that I keep hitting my head against is the fact that both the SHACL and SPIN seem to be introducing so much "roll your own" code for executing rules, rather than reusing the SPARQL algebra and evaluation strategies. I'm not sufficiently clued up on the intricacies of these languages (or indeed on how the current implementation works, exactly) to really suggest a better approach, but I'm worried that this bespoke code will be very hard to maintain (or to write optimization plans for) - especially for third party Sail backends.

Anyway, that's not really to the point of your question. I wouldn't use the CustomGraphQueryInferencer, except perhaps as inspiration on how to use the SPARQL engine to execute rules. The whole point of CustomGraphQueryInferencer was to have a cheap and simple "single rule" poor man's inference engine while we were waiting for something better to be developed. My personal view is that once the ShaclSail comes of age, the CustomGraphQueryInferencer will be deprecated.

Regarding your options 1 and 3, I don't feel qualified to give you a definite vote, but my inclination would be to go for the third option, as that is more in line with reuse of existing functionality.

Cheers,

Jeen

On Thu, Nov 1, 2018 at 5:41 AM Håvard Ottestad <hmottestad@xxxxxxxxx> wrote:
Hi,

I have a general question about what is the best approach for handling inheritance in SHACL rules.

############################
sh:targetClass ex:Person ;

sh:property [
sh:path ex:address ;
sh:or (
[
sh:datatype xsd:string ;
]
[
sh:class ex:Address ;
]
)
] .
############################


The sh:path ex:address gets inherited into each part of the sh:or. So it’s equivalent to the following:


############################
sh:targetClass ex:Person ;
sh:or (
[
sh:path ex:address ;
sh:datatype xsd:string ;

]
[
sh:path ex:address ;
sh:class ex:Address ;
]
)
 .
############################


And even though there is no example in the SHACL documentation, and this entire part of the spec is fairly poorly defined, I presume the following is equivalent too:


############################
sh:targetClass ex:Person ;

sh:property [
sh:or (
[
sh:path ex:address ;
sh:datatype xsd:string ;
]
[
sh:path ex:address ;
sh:class ex:Address ;
]
)
] .
############################
############################
############################


Question is. How should I handle this in RDF4J? 
 - Should I implement this as Java code in the SHACL engine. 
 - Should I wrap the SHACL rule sail in the CustomGraphQueryInferencer
 - Should I just run a SPARQL query myself to forward chain it?

Cheers,
Håvard


_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev

Back to the top