Steven, In responding, I need to separate between:
What SHACL standard supports What SHACL extensions for UI are offered by TopBraid What you may decide to develop as your own custom code SHACL does not assign any meaning to dcterms:hasPart. Nor does TopBraid support it. You can, of course, create your own custom code that will interpret this in any way you’d like. SHACL lets you use property paths in the sh:path. With this, you could say something like: > :AuthorSubmissonForm sh:targetClass :Agent ; > sh:property [ sh:path :address/:streetAddress ; sh:group > :AddressPropertyGroup ; sh:order “0” ; sh:nodeKind sh:Literal ;] ; > sh:property [ sh:path :address/:city ; sh:class :City ; sh:group > :AddressPropertyGroup ; sh:order “1” ; sh:nodeKind sh:IRI;] ; > What you do about the property shape for the :address property is up to you and depends on your needs. You could have it separately and without any property groups because this would be for validation rather than display. Or you could keep it as part of the above node shape. In either case, you will need some custom code that would actually render this UI. If this is for editing e.g., actually entering data into a submission form, then you would normally want to use sh:class such as :City and not just a IRI - which could be anything. Same with the literals - you would typically want to say a string, a date, etc., versus just a literal. For validation as well, unless it is very light validation, one is likely to want to be more specific. In case of TopBraid, we have defined a number of extensions to SHACL, including those that support user interfaces. And we have built some code that uses these extensions. These extensions, among other things, allow users to define the view, edit and search widgets as part of a shape. This includes a pre-built nested form widget. The namespace for extensions is http://topbraid.org/tosh <http://topbraid.org/tosh> and you can find it in the TBC workspace under TopBraid/SHACL. Using this approach, there would be: A node shape for Submission Form that includes a property shape for the :address. This property shape would use the sh:class :Address constraint component and specify the nested object form widgets for view, edit and search. A node shape for :Address would include property shapes for :street and :city. TopBraid would know how to render this info as if :street and :city belonged directly to the author. And, on editing, it would let user enter city and street, automatically creating (behind the scenes) a resource of the type :Address and building all the right connections. Regards, Irene > On Nov 21, 2017, at 10:20 AM, Steven Michael Folsom <[email protected]> wrote: > > I’m wondering if anyone on the list would have advice/examples for defining > SHACL to follow best practices for embedded/nested forms. Some of the > questions I’ve come up with so far are: > > PropertyGroups and PropertyShapes can have order. Can embedded Forms take an > order position among PropertyGroups > Maybe the question is can/should a NodeShape also be a PropertyGroup within a > larger form? > Is the nesting as simple as saying one Form (represented as a :NodeShape) > isPartOf another? > Or is it enough that each embedded form would have its own targetClass > assertion, and that Class would be linked to the larger form by the > encompassing NodeShape having a PropertyShape that includes a related > sh:class assertion. > > For example, an AuthorSubmissonForm might include an AuthorNamePropertyGroup, > an embedded AuthorAddressForm, an embedded SubmittedWorkForm, etc. > > :AuthorSubmissonForm :targetClass :Agent ; > dcterms:hasPart :AuthorAddressForm , :SubmittedWorkForm ; > sh:property [ sh:path foaf:name ; sh:group :NamePropertyGroup ; sh:nodeKind > sh:Literal ;] ; > sh:property [ sh:path :address ; sh:class :Address ; sh:group > :AddressPropertyGroup ; sh:nodeKind sh:IRI;] ; > sh:property [ sh:path :submission ; sh:class :Submission ; sh:group > :SubmissionPropertyGroup ; sh:nodeKind sh:IRI ;] . > > :NamePropertyGroup rdf:type sh:PropertyGroup ; shorder 0 . > > :AuthorAddressForm a sh:NodeShape , sh:PropertyGroup ; sh:targetClass > :Address ; sh:order “1” ; > sh:property [ sh:path :streetAddress ; sh:group :AddressPropertyGroup ; > sh:order “0” ; sh:nodeKind sh:Literal ;] ; > sh:property [ sh:path :city ; sh:class :City ; sh:group > :AddressPropertyGroup ; sh:order “1” ; sh:nodeKind sh:IRI;] . > > :SubmissionForm a sh:NodeShape , sh:PropertyGroup ; sh:targetClass > :Submission ; sh:order “2” ; > sh:property [ sh:path :title ; sh:group :SubmissionPropertyGroup ; sh:order > “0” ; sh:nodeKind sh:Literal ;] ; > sh:property [ sh:path :Type ; sh:class :Format ; sh:group > :SubmissionPropertyGroup ; sh:order “1” ; sh:nodeKind sh:IRI;] . > > > Thanks in advance for any insights/examples, > Steven > > -- > Steven Folsom > Metadata Specialist > Cornell University Library > http://orcid.org/0000-0003-3427-5769 <http://orcid.org/0000-0003-3427-5769> > http://vivo.cornell.edu/individual/sf433 > <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 [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
