To avoid misunderstandings, the TopBraid SHACL API is alive and well,
and has recently seen a new maven central release. I would encourage its
use over the SPIN API as there is nothing in SPIN that couldn't be
handled equally well in SHACL, yet SHACL is a W3C recommendation.
It is already possible to do incremental constraint validation using the
SHACL API. Basically create a ShapesGraph object and create a data graph
that "simulates" the update before it is sent to the base database. The
SHACL API bundles a class called DiffGraph [1] that can be used as a
buffer on top of your actual database. So if you have a SPARQL UPDATE,
you could apply it to the DiffGraph as a "dry run". Then run the
constraints/shapes that you want to re-validate. The challenge is to
find which focus nodes need to be triggered here. The case of
rdfs:subClassOf is tricky because any class in the rdfs:subClassOf*
neighborhood would need to be re-validated. It SHOULD however work if
you ask the DiffGraph about which resources show up as subjects and
objects or added or deleted triples, and then re-validate the applicable
shapes of those.
BTW the case of non-recursiveness is covered by a pure SHACL extension
library, see
http://datashapes.org/constraints.html#NonRecursiveConstraintComponent
so maybe you could add a shape
ex:NonRecursiveSubClasses
a sh:NodeShape ;
sh:targetSubjectsOf rdfs:subClassOf ;
sh:property [
sh:path rdfs:subClassOf ;
dash:nonRecursive true ;
] .
Holger
[1]
https://github.com/TopQuadrant/shacl/blob/master/src/main/java/org/topbraid/jenax/util/DiffGraph.java
On 14/08/2019 03:55, Jeff Lerman wrote:
Thanks all. To acknowledge some points:
1. Yes, OWL rules per se aren’t meant as constraints. Nonetheless,
constraints against a graph can be useful, and enforcement at
assertion-time for some (sub)set of those can also be useful.
2. Notwithstanding the fact that it’s valid (and even useful, to
effectively assert equivalence) under OWL to assert a non-DAG over
:subClassOf edges (the shorthand I’ll use to discuss triples with
:subClassOf as the predicate), it can certainly be useful to disallow that
for some graphs.
Martynas, thank you - https://github.com/spinrdf/spinrdf looks promising!
I’m reading the docs now. Can you comment on whether it can be set up to
automatically run a rule at the time of SPARQL UPDATE, and reject the
update if the rule would be violated by it?
Thanks!
—Jeff
[image: email_sig_logo_vert.png]
Jeff Lerman
AI Scientist
Mobile: 510-495-4621
www.invitae.com
[image: email_sig_social_linkedin.png]
<https://www.linkedin.com/in/jefflerman/>
On Tue, Aug 13, 2019 at 8:08 AM Martynas Jusevičius <[email protected]>
wrote:
You could also SPARQL as SPIN constraints:
https://www.w3.org/Submission/spin-modeling/#spin-constraints
Can be implemented using SPIN API: https://github.com/spinrdf/spinrdf
On Tue, Aug 13, 2019 at 4:07 PM Andy Seaborne <[email protected]> wrote:
On 13/08/2019 06:31, Lorenz Buehmann wrote:
The rules in Jena are not meant to be constraints. there are constraint
language for RDF like SHACL, SHEX - there is(was?) as SHACL API from
TopQuadrant [1] but even better, Andy has implemented something in that
direction quite recently [2]. I'm sure he can tell you more about the
current status and whether it is appropriate for your use case.
Yes, that's a goal. But not in the first release and the use case here
of "not a DAG" is interestingly special.
Initial, the functionality is:
1/ Command line - "shacl validate" and "shacl parse"
2/ Fuseki validation service - send shapes, get back report on a
specific graph
3/ API - for a single graph, execute constraints on a transaction and
abort on shape violation.
There are no substantive extensions to SHACL core and SPARQL. We can
build up a library of extensions if there are constraints that are
better in java, close to the data, then if they form common needs, we
can add those (contributions welcome!)
And there ought to be a documented a way to load custom ones - you can
do it with the Jena initialization jar loading but there's no
documentation.
For your example:
A/ You want a dataset as target - thoughts on that in [2] (it isn't
implemented). Feature 3 is only one graph at this stage.
B/ The validator will need to be a SPARQL one, its not in the SHACL core
set of operations.
Andy
[1] https://github.com/TopQuadrant/shacl
[2] https://afs.github.io/shacl-datasets.html
On 13.08.19 05:09, Jeff Lerman wrote:
Is there any way, with Jena (either the distributed version or via any
additional software anyone is aware of) to implement enforcement of
constraints on assertions, at the time of assertion?
In particular, it’d be very helpful to be able to protect the
graph(s) from
any assertion that breaks the assumption (in RDFS and OWL reasoners)
that
rtfs:subClassOf “edges” form a directed acyclic graph. Ideally, an
UPDATE
(or other operation adding content to the store) would fail if that
rule
(and maybe a small collection of similarly “basic” rules) would be
violated
by storing the updated data. For example, this would fail with an
error:
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX local: <http://localhost:8080/fuseki/jcl_test/data/>
INSERT DATA {
GRAPH local:notadag {
<c> rdfs:subClassOf <d> .
<d> rdfs:subClassOf <c> .
}
}
Thanks,
—Jeff
[image: email_sig_logo_vert.png]
Jeff Lerman
AI Scientist
Mobile: 510-495-4621
www.invitae.com
[image: email_sig_social_linkedin.png]
<https://www.linkedin.com/in/jefflerman/>
