[
https://issues.apache.org/jira/browse/JENA-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17501949#comment-17501949
]
Andy Seaborne edited comment on JENA-2301 at 3/6/22, 12:41 PM:
---------------------------------------------------------------
Thanks for the background; the principle that a collection of shapes are many
multiple purposes is not unreasonable. Splitting by shape-imports would work
but assumes the shapes were designed for that in the first place.
Are we talking about target shapes or node/property shapes that are no targets
but are part of a target shape?
I do prefer a solution that is a long term basis for the system (lessons
learned from the past!). There may be usages for other varying the shapes maybe
closed, maybe changing the severity or message, or things I can't imagine. As
above, setters/mutable shapes bring quite a few assumptions.
A variation of (1) is to add a parameter to validation that is a
{{java.util.Predicate}} - a test of whether to evaluate a shape (target or
non-target). Maybe that's more than a boolean test, more a function with a
"yes, no-and-don't-recurse, no-but-do-recurse" result (recurse is follow
property shapes and sh:node). It would enable deactivating a property shape
transversed by one part of the validation that is also accessible by other
routes
Any solution that isn't modify the shapes graph is Jena-specific so add (4):
A graph that is the view of another graph with modifications (also called a
"buffered graph"). The base graph isn't changed, the layer over the top records
adds and deletes and makes {{Graph.find}} give the right answers and the base
graph is not modified.
was (Author: andy.seaborne):
Thanks for the background; the principle that a collection of shapes are many
multiple purposes is not unreasonable. Splitting by shape-imports would work
but assumes the shapes were designed for that in the first place.
Are we talking about target shapes or node/property shapes that are no targets
but are part of a target shape?
I do prefer a solution that is a long term basis for the system (lessons
learned from the past!). There may be usages for other varying the shapes maybe
closed, maybe changing the severity or message, or things I can't imagine. As
above, setters/mutable shapes bring quite a few assumptions.
A variation of (1) is to add a parameter to validation that is a
{{java.util.Predicate}} - a test of whether to evaluate a shape (target or
non-target). Maybe that's more than a boolean test, more a function with a
"yes, no-and-don't-recurse, no-but-do-recurse" result (recurse is follow
property shapes and sh:node).
Any solution that isn't modify the shapes graph is Jena-specific so add (4):
A graph that is the view of another graph with modifications (also called a
"buffered graph"). The base graph isn't changed, the layer over the top records
adds and deletes and makes {{Graph.find}} give the right answers and the base
graph is not modified.
> Allow to activate/deactivate shapes
> -----------------------------------
>
> Key: JENA-2301
> URL: https://issues.apache.org/jira/browse/JENA-2301
> Project: Apache Jena
> Issue Type: Improvement
> Components: SHACL
> Reporter: Florian Kleedorfer
> Priority: Trivial
>
> I have a use case in which I need to toggle a shape's 'deactivated` flag
> programatically.
> The current workaround I'm using is to extract the shape's subgraph, set the
> flag in the extracted graph, and then parse it again. If there is a simpler
> workaround, I'll be happy to use that.
> Otherwise, here are my suggestions (for Shape.java):
> * Make the `deactivated` flag non-final and add a setter.
> * Provide a way to clone a shape and change the flag underway.
> Cheers!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
