[jira] [Comment Edited] (JENA-2301) Allow to activate/deactivate shapes

["Andy Seaborne (Jira)" <ji...@apache.org>]

    [ 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)