--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/4cc9fc07-6309-4c53-aaee-7073dd62ac2cn%40googlegroups.com.
Just to add I don't see a solution to your specific issue either. Custom target types can only access their own parameters, not the context shape or the properties of that.
Holger
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6f1d4307-437a-404c-8628-b304a12efb61n%40googlegroups.com.
Hi Matt,
sounds interesting. Do you have a draft spec for this someplace, or a worked out example?
One problem or design constraint with SHACL targets is that they should be executable in two modes:
1) for a given shape, find all target nodes
2) for a given node, find all shapes that target it
If a constraint types makes computing 2) hard then tools will not be efficiently able to validate a given instance, e.g. after a user has made changes on a form.
I am not saying this applies here but wanted to put this out as a
thought to consider.
Holger
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/641f35ef-99f2-4057-9e56-4ea7419ad516n%40googlegroups.com.
I've finally had some time to think about this. Another potential use case for this would be some future state of the W3C Data Cube ontology. Data Structure Definitions could be changed to be represented as Node Shapes, and the focus nodes of one of these would be the Observations that are part of the DataSet(s) that have that Data Structure Definition. This would require the use of a path instead of a single predicate.
I've thought of two possible implementations. The first is the creation of a new Target Type. Here's a (non-functional) prototype:
sh:PathFromShapeTarget
a sh:TargetType ;
rdfs:subClassOf sh:Target ;
sh:parameter [
sh:path sh:path ;
sh:description "The path connecting one or more shapes to their focus nodes" ;
] ;
sh:select """
SELECT ?this ?currentShape
WHERE {
?shape $PATH ?this
FILTER EXISTS {?shape a/rdfs:subClassOf sh:NodeShape} # This may or may not be necessary
}
""" ;
.
Targets then take a SHACL path to identify the path desired and injects it in the SPARQL query like the path in a sh:SPARQLSelectValidator
(if implemented in SPARQL). So for the example function ontology:
fno:FunctionTarget
a sh:PathFromShapeTarget ;
sh:path [
sh:inversePath fno:executes ;
] ;
.
Or for the Data Cube example:
qb:DataStructureDefinitionTarget
a sh:PathFromShapeTarget ;
sh:path [
sh:inversePath (
qb:dataSet
qb:structure
) ;
] ;
.
Now, I realize that following the current behavior of Node Shapes and Targets, each and every fno:Function
or qb:DataStructureDefinition
would require an extra triple connecting it to the above example Target via sh:target
. While that could work, it feels like that the Target itself really captures the meaning that the specified path connects shapes to focus nodes independently of the specific shape and that requiring that extra triple to exist every time feels redundant.
Therefore, it would be nice if it were possible to enable that functionality, which is why I added the ?currentShape
variable in the query; either a shape could be bound to ?currentShape
get focus nodes, or a (potential) focus node could be bound to ?this
to obtain the shapes that apply to that node via the path.
A second possible implementation would be to create a new Constraint Component that functions like sh:node
, using a property perhaps called sh:nodePath
. However, instead of specifying the URI of a Node Shape that focus nodes must also conform to, it specifies a SHACL path pointing to Node Shape(s) that focus nodes must also conform to.
This would enable the following additions for the function ontology:
fno:Execution
sh:nodePath fno:executes ;
.
Or these additions for the Data Cube ontology:
qb:Observation
sh:nodePath (
qb:dataSet
qb:structure
) ;
.
This approach seems a bit cleaner, more practical, and it has the benefit of applying to all instances of qb:Observation
regardless of the specific Data Structure Definition relevant to a given Observation. Note that this doesn't apply a targeting rule based on a path independently; if there were multiple classes/shapes that would also conform to a shape at the same path, that would have to be expressed multiple times unlike the first approach (potentially). That's not a dealbreaker though, just a comment.
My main reservation with this approach is that I'm not a huge fan of how if sh:node
fails validation, the error message states just that validation failed and not why it failed (like how the original SHACL Playground example says "Value does not have shape schema:AddressShape"
instead of the actual error message "Value is not >= 10000"
). The sh:node
error messaging is not super helpful, and I would hope that the error messaging for this feature would show the expected helpful messages (and that in the future the error messages from sh:node
could be propagated through to the final report as well).
I haven't had the time to dig into SHACL validator implementation details yet, so I'm not sure how feasible either of these options are to actually implement in a current SHACL validator. I'm curious to see what you think.
You received this message because you are subscribed to a topic in the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/topbraid-users/JS6jfJikuBk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/a879b561-4cf5-2104-3dee-b763b6e6ce49%40topquadrant.com.
Hi Matt,
without understanding all consequences and requirements, some
comments below.
A second possible implementation would be to create a new Constraint Component that functions like
sh:node
, using a property perhaps calledsh:nodePath
. However, instead of specifying the URI of a Node Shape that focus nodes must also conform to, it specifies a SHACL path pointing to Node Shape(s) that focus nodes must also conform to.This would enable the following additions for the function ontology:
fno:Execution sh:nodePath fno:executes ; .Or these additions for the Data Cube ontology:
qb:Observation sh:nodePath ( qb:dataSet qb:structure ) ; .This approach seems a bit cleaner, more practical, and it has the benefit of applying to all instances of
qb:Observation
regardless of the specific Data Structure Definition relevant to a given Observation. Note that this doesn't apply a targeting rule based on a path independently; if there were multiple classes/shapes that would also conform to a shape at the same path, that would have to be expressed multiple times unlike the first approach (potentially). That's not a dealbreaker though, just a comment.My main reservation with this approach is that I'm not a huge fan of how if
sh:node
fails validation, the error message states just that validation failed and not why it failed (like how the original SHACL Playground example says"Value does not have shape schema:AddressShape"
instead of the actual error message"Value is not >= 10000"
). Thesh:node
error messaging is not super helpful, and I would hope that the error messaging for this feature would show the expected helpful messages (and that in the future the error messages fromsh:node
could be propagated through to the final report as well).
I haven't had the time to dig into SHACL validator implementation details yet, so I'm not sure how feasible either of these options are to actually implement in a current SHACL validator. I'm curious to see what you think.
Moving forward, you may elect to open a ticket similar to
https://github.com/w3c/data-shapes/issues/137 with a proposal on
what is missing. This is the place to talk about future versions
of SHACL where such requirements could be addressed better.
Without at least some basic acknowledgement by people outside of
TopQuadrant (so that other implementations would understand such
extensions), or show-stopping use cases by paying customers, it
would be hard for me to spend much time on such extensions on my
own.
Holger
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGyojU2iQFRvaPpxQ%3DX%2BGWdxpdQzg%3Dhpf64aswyVb8Aps7C1GQ%40mail.gmail.com.
--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/e884ded2-59cd-4997-bc74-e3a8e21bc758n%40googlegroups.com.