You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Jeff Lerman <je...@invitae.com.INVALID> on 2019/08/13 03:09:25 UTC
Any way to enforce constraints at assertion-time?
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/>
Re: Any way to enforce constraints at assertion-time?
Posted by Jeff Lerman <je...@invitae.com.INVALID>.
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 <ma...@atomgraph.com>
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
> <je...@invitae.com.invalid> 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 <
> martynas@atomgraph.com>
> > 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 <an...@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/>
> > > > >>
> > > > >
> > >
>
Re: Any way to enforce constraints at assertion-time?
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
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
<je...@invitae.com.invalid> 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 <ma...@atomgraph.com>
> 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 <an...@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/>
> > > >>
> > > >
> >
Re: Any way to enforce constraints at assertion-time?
Posted by Holger Knublauch <ho...@topquadrant.com>.
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 <ma...@atomgraph.com>
> 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 <an...@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/>
>>>>>
Re: Any way to enforce constraints at assertion-time?
Posted by Jeff Lerman <je...@invitae.com.INVALID>.
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 <ma...@atomgraph.com>
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 <an...@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/>
> > >>
> > >
>
Re: Any way to enforce constraints at assertion-time?
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
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 <an...@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/>
> >>
> >
Re: Any way to enforce constraints at assertion-time?
Posted by Andy Seaborne <an...@apache.org>.
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/>
>>
>
Re: Any way to enforce constraints at assertion-time?
Posted by Lorenz Buehmann <bu...@informatik.uni-leipzig.de>.
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.
[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/>
>
Re: Any way to enforce constraints at assertion-time?
Posted by Dave Reynolds <da...@gmail.com>.
On 13/08/2019 04: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?
Nothing built in. The reasoners do support a validation method which is
implemented in the OWL reasoners and you can create your own validation
rules in the generic rule reasoner [1]. However, there's no automatic
checking of updates against such reasoner validation. For the OWL
reasoner such enforcement would be impractically slow.
> 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.
There's no such assumption.
> 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> .
> }
> }
That's a perfectly legal set of assertions and equivalent to asserting
<c> owl:equivalentClass <d> .
Indeed applications which limit themselves to RDFS for one reason or
another have this as their only idiom for expressing class equivalence.
Furthermore the OWL reasoners will effectively infer this pair from any
direct or indirect expression of class equivalence.
It's also always the case that:
<c> rdfs:subClassOf <c> .
Dave
[1] https://jena.apache.org/documentation/inference/#RULEnotes