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 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/a879b561-4cf5-2104-3dee-b763b6e6ce49%40topquadrant.com.
