Revisiting this topic- I continue to run into situations where it would be useful for data to specify shapes it should conform to using domain terminology. I've been playing around with how this would work and have made a prototype implementation in python (just because I happen to be more familiar with that library) that corresponds to the second option mentioned above. It behaves basically like sh:node, except instead of specifying a node shape that all value nodes conform to, it specifies a SHACL path for which to find node shapes the value node must conform to from each value node (if any resources at that path are node shapes).
Using this prototype and the following graph: @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix sh: <http://www.w3.org/ns/shacl#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix ex: <http://example.org/> . ex:Person a rdfs:Class ; a sh:NodeShape ; sh:nodesPath [ sh:oneOrMorePath ex:also ; ] ; sh:property [ a sh:PropertyShape ; sh:path ex:name ; sh:datatype xsd:string ; sh:minCount 1 ; ] ; . ex:OtherShape a sh:NodeShape ; sh:property [ a sh:PropertyShape ; sh:path ex:age ; sh:datatype xsd:integer ; sh:minCount 1 ; ] ; . ex:Person1 a ex:Person ; . ex:Person2 a ex:Person ; ex:also ex:OtherShape ; . ex:Person3 a ex:Person ; ex:also ex:NotAShape ; . ex:NotAShape ex:also ex:OtherShape ; . I get the following report: @prefix ex: <http://example.org/> . @prefix sh: <http://www.w3.org/ns/shacl#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . [] a sh:ValidationReport ; sh:conforms false ; sh:result [ a sh:ValidationResult ; sh:focusNode ex:Person1 ; sh:resultMessage "Less than 1 values on ex:Person1->ex:name" ; sh:resultPath ex:name ; sh:resultSeverity sh:Violation ; sh:sourceConstraintComponent sh:MinCountConstraintComponent ; sh:sourceShape _:ne487b6e44cab4037932893f8ef36eaabb2 ], [ a sh:ValidationResult ; sh:focusNode ex:Person3 ; sh:resultMessage "Less than 1 values on ex:Person3->ex:age" ; sh:resultPath ex:age ; sh:resultSeverity sh:Violation ; sh:sourceConstraintComponent sh:MinCountConstraintComponent ; sh:sourceShape _:ne487b6e44cab4037932893f8ef36eaabb3 ], [ a sh:ValidationResult ; sh:focusNode ex:Person3 ; sh:resultMessage "Less than 1 values on ex:Person3->ex:name" ; sh:resultPath ex:name ; sh:resultSeverity sh:Violation ; sh:sourceConstraintComponent sh:MinCountConstraintComponent ; sh:sourceShape _:ne487b6e44cab4037932893f8ef36eaabb2 ], [ a sh:ValidationResult ; sh:focusNode ex:Person2 ; sh:resultMessage "Less than 1 values on ex:Person2->ex:age" ; sh:resultPath ex:age ; sh:resultSeverity sh:Violation ; sh:sourceConstraintComponent sh:MinCountConstraintComponent ; sh:sourceShape _:ne487b6e44cab4037932893f8ef36eaabb3 ], [ a sh:ValidationResult ; sh:focusNode ex:Person2 ; sh:resultMessage "Less than 1 values on ex:Person2->ex:name" ; sh:resultPath ex:name ; sh:resultSeverity sh:Violation ; sh:sourceConstraintComponent sh:MinCountConstraintComponent ; sh:sourceShape _:ne487b6e44cab4037932893f8ef36eaabb2 ] . _:ne487b6e44cab4037932893f8ef36eaabb3 a sh:PropertyShape ; sh:datatype xsd:integer ; sh:minCount 1 ; sh:path ex:age . _:ne487b6e44cab4037932893f8ef36eaabb2 a sh:PropertyShape ; sh:datatype xsd:string ; sh:minCount 1 ; sh:path ex:name . Note that Person2 and Person3 don't conform to ex:OtherShape since they are connected to ex:OtherShape via the specified sh:nodesPath. Had they been connected to other shapes via the same path, then they would have been validated against those too. I did open a ticket about this <https://github.com/w3c/data-shapes/issues/139> as you suggested, but there doesn't seem to be much activity there- is there another place that is more up to date/active? Thanks, Matt Goldberg On Wednesday, August 4, 2021 at 1:25:24 AM UTC-4 Holger Knublauch wrote: > 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]> > 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]. >> 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. >> To unsubscribe from this group and all its topics, 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 >> >> <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]. > > 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> > . > > -- The topics of this mailing list include TopBraid EDG and related technologies such as SHACL. To post to this group, send email to [email protected] --- 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/e884ded2-59cd-4997-bc74-e3a8e21bc758n%40googlegroups.com.
