Thanks Martynas. For my purposes, the test would have to apply to the state of the whole DB after aplication of the UPDATE. The idea is to provide a way to guarantee that the graph never violates some (small) set of constraints, which necessarily includes preventing any changes that would cause violation of those constraints. In the case of a DAG-requiring constraint over the set of edges of a some type, it’s easy to see that addition of a single edge could violate the constraint, so examination of just the update in isolation wouldn’t suffice.
Effectively (this isn’t necessarily the only way to do it), one needs a system that filters updates by: (1) applying each update in a “tentative” transaction, (2) running the constraint against the resulting state of the DB (graph) and (3) rolling back the transaction if a violation is found (and then returning/emitting some informative complaint). It’s easy to imagine writing such filtering constraints that would slow performance unacceptably - but it’s certainly possible to avoid that in limited cases. 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 11:05 AM Martynas Jusevičius <[email protected]> wrote: > Jeff, > > re. constraint validation during update -- it's not something I've > tried, but I think it should be doable depending on whether your > constraint can solely run on the request body, or does it need to > check against the state of the whole DB. > In the first case it might be possible to implement a server filter or > a JAX-RS ContainerRequestFilter for example that executes the > constraint. > In the second case you probably need SPIN or SHACL constraint support > in the triplestore itself. I think Dydra (https://dydra.com) supports > it. > > I think it would be easier to validate if your request would contain > an RDF graph and not a SPARQL INSERT DATA command. I think the end > result would be the same? > > That was my use case -- validating RDF data incoming through the > Linked Data API. Here's a filter for JAX-RS: > > https://github.com/AtomGraph/Processor/blob/master/src/main/java/com/atomgraph/server/io/ValidatingModelProvider.java > > Hope it helps. > > On Tue, Aug 13, 2019 at 7:55 PM Jeff Lerman > <[email protected]> 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/> > > > > >> > > > > > > > > >
