Hi Matt,
without understanding all consequences and requirements, some comments
below.
On 2021-08-02 2:58 am, Matt Goldberg wrote:
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.
This approach would stretch the current use of target types quite a bit.
For example, sh:parameter values cannot easily be "deep" blank node
structures, but only individual nodes. Property shape validators use
$PATH as a special, hard-coded parameter to avoid such complications.
Before such a pseudo-generic mechanism is added only to cover this
particular use case, I think it would be cleaner to introduce a proper
target type for a SHACL 1.1 Core, as below.
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 <https://shacl.org/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).
The property sh:detail was introduced to capture those nested
violations. The SHACL API has a flag to activate those nested
violations, yet the SHACL Playground is just that - a simple playground.
Don't expect it to be the ultimate truth.
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
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free. www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
On Wed, Jul 21, 2021 at 11:38 PM Holger Knublauch
<[email protected] <mailto:[email protected]>> wrote:
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
On 2021-07-22 1:11 am, Matt Goldberg wrote:
Hello-
I'm continuing this thread to propose a potential feature to add
to some future version of SHACL related to this discussion. This
feature would be a special type of target that would enable
additional focus nodes for a shape to be specified by a property
in a domain ontology that connects the focus node to the shape.
This could be configured such that the subject would be a focus
node and the object would be the shape, or such that the subject
is the shape and the object is a focus node, or perhaps using a
SHACL path which would enable more complex behavior than just a
single predicate. I realize that the second case is like
sh:targetNode, except the idea is to enable an existing domain
property to have similar functionality to sh:targetNode. This
would be useful for domains in which data may contain the
specification of data requirements. As discussed earlier, there
is currently no easy way to do this.
For example, consider this function ontology
<https://fno.io/spec/#ontology-abstract>. If you look at the
descriptions for fno:Parameter
<https://fno.io/spec/#fn-parameter> and fno:Output they look very
similar to sh:PropertyShape (or perhaps sh:Parameter) in spirit,
and the class fno:Function is therefore like sh:NodeShape (or
perhaps sh:Function). If these classes were additionally modeled
as subclasses of the corresponding SHACL class, then the focus
nodes of an instance of fno:Function (and sh:NodeShape) would be
the instances of fno:Execution connected to it via fno:executes.
Therefore, it would be convenient to be able to create a target
that effectively says "for all triples with fno:executes as
predicate, the subject is a focus node of the object".
I realize that this is targeting behavior is different than the
other targets; shapes effectively say what the focus nodes for
that shape are with existing targets while this is a target that
could apply to multiple shapes. However, I think it could enable
SHACL to be a lot more flexible, help enable simpler integration
with existing ontologies (especially those in which data
requirements are part of the domain), and help reduce the amount
of metamodeling required to get extra SHACL functionality added
to existing models.
Matt Goldberg
On Tuesday, November 3, 2020 at 2:06:55 AM UTC-5 Holger Knublauch
wrote:
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
On 11/3/2020 2:01 PM, Matt Goldberg wrote:
Hello-
Thanks for the reply. I have considered doing exactly this,
and may end up trying this further. My reservations with
this method are that this requires Advanced Features which
may not be supported by all SHACL engines, and with every
usage of this Target Type the shape must specify itself as a
parameter and I was hoping there would be a way to make it a
bit smarter to avoid doing that. However, if that's the best
option, I'll experiment with it.
On Monday, November 2, 2020 at 10:44:27 PM UTC-5 Irene
Polikoff wrote:
Hi Matt,
There are pre-defined target types in SHACL. You can not
change their behavior.
There is also a way to create SPARQL based targets using
a SPARQL query. If a query is a pattern that may be
re-used in different contexts, you could declare a
custom type by parametrizing the query as described here
_https://w3c.github.io/shacl/shacl-af/#SPARQLTargetType
<https://w3c.github.io/shacl/shacl-af/#SPARQLTargetType>_
This would be your own type of target, using your
namespace, not sh:.
The query, for example, could have predicate and object
as parameters:
ex:MyTarget
a sh:SPARQLTargetType ;
rdfs:subClassOf sh:Target ;
sh:parameter [
sh:path ex:predicate ;
sh:nodeKind sh:IRI ;
] ;
sh:parameter [
sh:path ex:object ;
sh:nodeKind sh:IRI ;
] ;
sh:prefixes ex: ;
sh:select """
SELECT ?this
WHERE {
?this $predicate $object .
}
""" .
Then, when you assign this custom target type, you would
provide values for the predicate and object. I have
assumed above that objects are resources.
This is just a quickly sketched example. I have not
tried it. Read the spec for more details.
On Nov 2, 2020, at 8:20 PM, Matt Goldberg
<[email protected]> wrote:
Left out a detail- an ideal solution would also avoid
sh:node such that errors in validation reports would be
informative instead of sh:node's uninformative "does
not conform to shape" message.
Thanks for any help!
On Monday, November 2, 2020 at 8:07:44 PM UTC-5 Matt
Goldberg wrote:
Hello-
I've experimented with the Custom Targets and
Custom Target Types and I can't seem to find a
reasonable way to define targets in a particular
way. What I'd like to do is have the focus nodes
specified by resources themselves via a property
that points to the shape to use, effectively how
rdf:type does for implicit shapes, but by using a
specified term in the domain ontology instead of
rdf:type. In other words, I'd like to specify that
the focus nodes for some node shape S are the
subjects of triples with predicate P and object S,
where P is specified and is not necessarily rdf:type.
sh:targetSubjectsOf and sh:targetObjectsOf do not
provide this functionality, as they only look at
the predicate. I don't think $currentShape is
pre-bound for custom target types like for
constraint components (at least my experiments
didn't seem to work), but even if it is, it would
likely be an optional feature as is stated in the
specification. An ideal solution would be something
that would not use any TopBraid specific features,
as we are using SHACL in other systems as well.
Thanks for any help!
--
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
[email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/4cc9fc07-6309-4c53-aaee-7073dd62ac2cn%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/4cc9fc07-6309-4c53-aaee-7073dd62ac2cn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/6f1d4307-437a-404c-8628-b304a12efb61n%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/6f1d4307-437a-404c-8628-b304a12efb61n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/641f35ef-99f2-4057-9e56-4ea7419ad516n%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/641f35ef-99f2-4057-9e56-4ea7419ad516n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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
<https://groups.google.com/d/topic/topbraid-users/JS6jfJikuBk/unsubscribe>.
To unsubscribe from this group and all its topics, send an email
to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/a879b561-4cf5-2104-3dee-b763b6e6ce49%40topquadrant.com
<https://groups.google.com/d/msgid/topbraid-users/a879b561-4cf5-2104-3dee-b763b6e6ce49%40topquadrant.com?utm_medium=email&utm_source=footer>.
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free. www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/CAGyojU2iQFRvaPpxQ%3DX%2BGWdxpdQzg%3Dhpf64aswyVb8Aps7C1GQ%40mail.gmail.com
<https://groups.google.com/d/msgid/topbraid-users/CAGyojU2iQFRvaPpxQ%3DX%2BGWdxpdQzg%3Dhpf64aswyVb8Aps7C1GQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/7214f881-2194-df60-5514-a56454ef05db%40topquadrant.com.
