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 <a...@apache.org> 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/> > >> > >
