>> ex:ExampleAndShape >> a sh:NodeShape ; >> sh:targetNode ex:ValidInstance, ex:InvalidInstance ; >> sh:and ( >> ex:SuperShape >> ex:SubShapePropertyShape >> ) .
Is the same as > ex:ExampleAndShape > a sh:NodeShape ; > sh:targetNode ex:ValidInstance, ex:InvalidInstance ; > sh:node ex:SuperShape ; > sh:node ex:SubShapePropertyShape . And the above avoids the use of sh:and that is a complex structure in RDF. Of course, you can do other things. > ex:ExampleAndShape > # a sh:NodeShape ; not needed since inherited from > ex:SuperShape It is best practice to specify types of resources - in general and when using sh: namespace. >From the spec: A shape is an IRI <https://www.w3.org/TR/shacl/#dfn-iri> or blank node <https://www.w3.org/TR/shacl/#dfn-blank-node> s that fulfills at least one of the following conditions in the shapes graph <https://www.w3.org/TR/shacl/#dfn-shapes-graph>: s is a SHACL instance <https://www.w3.org/TR/shacl/#dfn-shacl-instance> of sh:NodeShape or sh:PropertyShape. s is subject <https://www.w3.org/TR/shacl/#dfn-subject> of a triple that has sh:targetClass, sh:targetNode, sh:targetObjectsOf or sh:targetSubjectsOf as predicate <https://www.w3.org/TR/shacl/#dfn-predicate>. s is subject <https://www.w3.org/TR/shacl/#dfn-subject> of a triple that has a parameter <https://www.w3.org/TR/shacl/#dfn-parameters> as predicate <https://www.w3.org/TR/shacl/#dfn-predicate>. s is a value <https://www.w3.org/TR/shacl/#dfn-value> of a shape-expecting <https://www.w3.org/TR/shacl/#dfn-shape-expecting-constraint-parameters>, non-list-taking <https://www.w3.org/TR/shacl/#dfn-list-taking-constraint-parameters> parameter <https://www.w3.org/TR/shacl/#dfn-parameters> such as sh:node, or a member <https://www.w3.org/TR/shacl/#dfn-members> of a SHACL list <https://www.w3.org/TR/shacl/#dfn-shacl-list> that is a value <https://www.w3.org/TR/shacl/#dfn-value> of a shape-expecting <https://www.w3.org/TR/shacl/#dfn-shape-expecting-constraint-parameters> and list-taking <https://www.w3.org/TR/shacl/#dfn-list-taking-constraint-parameters> parameter such as sh:or. A node shape is a shape <https://www.w3.org/TR/shacl/#dfn-shape> in the shapes graph <https://www.w3.org/TR/shacl/#dfn-shapes-graph> that is not the subject <https://www.w3.org/TR/shacl/#dfn-subject> of a triple <https://www.w3.org/TR/shacl/#dfn-rdf-triple> with sh:path as its predicate <https://www.w3.org/TR/shacl/#dfn-predicate>. Thus, a SHACL processor must be able to determine that ex:ExampleAndShape is a shape - because of its use of sh:and which is list-taking parameter. And, since it is not a subject of sh:path statement, SHACL processor must conclude that it is a node shape. This, however, has nothing to so with “inheritance” from ex:SuperShape. The word “inherit” is not used anywhere in the spec. > On May 14, 2018, at 11:54 AM, Rebecca Younes <rebecca.you...@cornell.edu> > wrote: > > Regarding the second example below, using ex:ExampleAndShape, given the > semantics of sh:node and the different interpretations of “value node” for > NodeShapes and PropertyShapes, I understand how your version with sh:node > rather than sh:and would work. But I’m uncertain about the meaning of the > original formalization that conjoins a NodeShape and a PropertyShape with > sh:and. Since sh:and means that “each value node conforms to” each conjoined > shape, how is it that a NodeShape can conform to a PropertyShape, when > different predicates apply to these different types of shapes? I would think > this ought to be formulated as: > > ex:SuperShape > a sh:NodeShape ; > sh:property ex:SuperShapePropertyShape . > > > ex:ExampleAndShape > # a sh:NodeShape ; not needed since inherited from > ex:SuperShape > sh:and ( > ex:SuperShape > [ > sh:property ex:SubShapePropertyShape > ] > ) . > > > > Regarding the use of sh:and on PropertyShapes, it seems useful to apply > sh:and as follows: > > ex:SuperShapePropertyShape > a sh:PropertyShape ; > sh:path ex:predicate ; > sh:maxCount 2 ; > sh:class ex:SomeClass . > > ex:SubShapePropertyShape > sh:and ( > ex:SuperShapePropertyShape > [ > sh:name “My name” ; > sh:minCount 1 ; > ] > ) . > > As I understand the use of sh:and, this means that ex:SubShapePropertyShape > conforms to the constraints of both ex:SuperShapePropertyShape as well as the > specialized constraints in the conjoined blank node. (Although I generally > prefer the use of URIs for shapes to enable reuse, in this case it seems > appropriate to use a blank node rather than a URI node, because as a > specialization of ex:SuperPropertyShape it is unlikely to be re-used outside > of this shape, and further specialization also seems unlikely.) > > According to my understanding, this is equivalent to the following; if so, > what are the properties of sh:node that make it preferable to sh:and? > > ex:SubShapePropertyShape > sh:node ex:SuperShapePropertyShape , > [ > sh:name “My name” ; > sh:minCount 1 ; > ] . > > Thank you. > > Rebecca Younes > > From: <topbraid-users@googlegroups.com> on behalf of Holger Knublauch > <hol...@topquadrant.com> > Reply-To: "topbraid-users@googlegroups.com" <topbraid-users@googlegroups.com> > Date: Friday, May 11, 2018 at 9:22 PM > To: "topbraid-users@googlegroups.com" <topbraid-users@googlegroups.com> > Subject: Re: [topbraid-users] Compiling Validation and UI/Form semanatics > > > > On 11/05/2018 22:19, Steven Michael Folsom wrote: >> I realize the examples are not normative, but could the example given at >> https://www.w3.org/TR/shacl/#AndConstraintComponent be stated without the >> blank nodes? E.g. >> >> ex:SuperShape >> a sh:NodeShape ; >> sh:property ex:SuperShapePropertyShape . >> >> ex:SuperShapePropertyShape sh:path ex:property ; >> sh:minCount 1 . > > Yes this is equivalent. We often use URIs for property shapes too. In that > case I would strongly recommend adding the rdf:type sh:PropertyShape triple > too, so that viewers can still understand this resource outside of the > SuperShape context. > > >> >> ex:ExampleAndShape >> a sh:NodeShape ; >> sh:targetNode ex:ValidInstance, ex:InvalidInstance ; >> sh:and ( >> ex:SuperShape >> ex:SubShapePropertyShape >> ) . >> >> :SubShapePropertyShape sh:path ex:property ; >> sh:maxCount 1 . > > BTW sh:and is a bit redundant and arguably shouldn't even be in SHACL. You > can simply write > > ex:ExampleAndShape > a sh:NodeShape ; > sh:targetNode ex:ValidInstance, ex:InvalidInstance ; > sh:node ex:SuperShape ; > sh:node ex:SubShapePropertyShape . > > for the same semantics. > > >> >> >> >> Also confirming what I think is true, can property shapes use sh:and to a >> similar effect? E.g. >> >> :SubShapePropertyShape sh:path ex:property ; >> sh:maxCount 1 ; >> sh:and (ex:SubShapePropertyShape) . > > Yes property shapes can use sh:and too. Again, sh:node is probably be a > better syntax, esp if you only have one member in the sh:and list. > > sh:or is a very different story, as is sh:not. > > HTH > Holger > > > > >> >> >> Thanks, >> Steven >> >> From: <topbraid-users@googlegroups.com> on behalf of Holger Knublauch >> <hol...@topquadrant.com> >> Reply-To: "topbraid-users@googlegroups.com" <topbraid-users@googlegroups.com> >> Date: Saturday, April 14, 2018 at 7:16 PM >> To: "topbraid-users@googlegroups.com" <topbraid-users@googlegroups.com> >> Subject: Re: [topbraid-users] Compiling Validation and UI/Form semanatics >> >> >> >> On 14/04/2018 3:59, Irene Polikoff wrote: >>> Overrides are not supported, but inheritance is supported. >>> >>> For example, you could define minCount but not define maxCount, then add a >>> definition of maxCount in the “sub shape”. >>> >>> There are 2 ways of addressing this: >>> >>> • Classes can also be shapes. If you model that way, all you need to do >>> is to create a class of all things that your general property constraints >>> will apply to, then create subclasses and add additional constraints to >>> them. >>> • For example, you would create a class Person with property >>> shapes that say that a person must have name and age. Then you define a >>> subclass Student with property shapes that say that students age must be >>> greater than 15 and they need to have student ID. >>> • Otherwise, shapes can contain other shapes. You would define a >>> general shape with constraints you want to use in other shapes. When you >>> define more specific shapes, you would include the general shape into them >>> using sh:and. >>> • https://www.w3.org/TR/shacl/#AndConstraintComponent >>> >> >> An alternative to using sh:and is simply sh:node. In shapes, sh:node >> fulfills a similar role as rdfs:subClassOf for classes. For example state >> ex:SubShape sh:node ex:SuperShape to ensure that all constraints defined for >> SuperShape also apply to the target nodes of SubShape. (Whether tools will >> understand this form of inheritance is another question - currently not all >> places of the TopBraid forms would use sh:node although I'd like to move >> there). >> >> Holger >> >> >> >> >>> >>> >>> >>>> On Apr 13, 2018, at 1:20 PM, Rebecca Younes <rebecca.you...@gmail.com> >>>> wrote: >>>> >>>> A related question: is it possible for one shape to invoke, inherit, >>>> and/or override values from another shape? For example, I would like to >>>> create a general property shape for a title property that defines >>>> cardinality, sh:class, sh:path, etc. Then in the context of different form >>>> shapes, I would like to define specific names, descriptions, orders, etc.: >>>> "Album title," "Book title," and so on. Perhaps I would like to define a >>>> default name "Title," which could be overridden by the specific form >>>> shapes. Is any of this possible? >>>> >>>> Thanks. >>>> >>>> Rebecca Younes >>>> Semantic Application Developer and Ontology Engineer >>>> Cornell University Library Information Technology >>>> >>>> >>>> On Thursday, April 12, 2018 at 4:17:52 PM UTC-4, Steven Folsom wrote: >>>>> I would be interested to be able to look at any implementations where >>>>> Validation shapes are compiled with non-Validation shapes to build Forms, >>>>> where that the validation axioms are maintained in separate shapes from >>>>> non-validation (UI) shapes? >>>>> >>>>> Is anyone doing this? We’ve been considering it for easier maintenance of >>>>> our various shapes, but right now it’s easier to see all the axioms >>>>> needed for the app in one place… >>>>> >>>>> Thanks, >>>>> Steven >>>>> >>>>> -- >>>>> Steven Folsom >>>>> Metadata Specialist >>>>> Cornell University Library >>>>> pronouns: he/him/they/them >>>>> http://orcid.org/0000-0003-3427-5769 >>>>> http://vivo.cornell.edu/individual/sf433 >>>>> @sf433 >>>>> >>>> >>>> -- >>>> 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-users+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> 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-users+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> 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-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> 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-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > 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-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > -- > 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-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
