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]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/641f35ef-99f2-4057-9e56-4ea7419ad516n%40googlegroups.com.
