One last question (hopefully) about Nested Forms. Is nesting a form within a Nested Form as simple as following this pattern?
:AuthorSubmissonForm :targetClass :Agent ; sh:property [ sh:path foaf:name ;] ; sh:property [ sh:path :address ; sh:class :Address ; tosh:editWidget swa:NestedObjectEditor ; tosh:viewWidget swa:NestedObjectViewer ;] ; sh:property [ sh:path :submission ; sh:class :Submission] . :AddressForm :targetClass :Address ; sh:property [ sh:path :street ;] ; sh:property [ sh:path :city ; sh:class :City ; tosh:editWidget swa:NestedObjectEditor ; tosh:viewWidget swa:NestedObjectViewer ;] . :CityForm :targetClass :City ; sh:property [ sh:path :name ;] ; sh:property [ sh:path :zip ;] ; . From: <[email protected]> on behalf of Irene Polikoff <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Tuesday, November 21, 2017 at 7:33 PM To: "[email protected]" <[email protected]> Subject: Re: [topbraid-users] Are There Best Practices for Nested Forms? See responses below On Nov 21, 2017, at 6:32 PM, Steven Folsom <[email protected]<mailto:[email protected]>> wrote: Thanks, Irene. Your responses are always very helpful. A couple questions below. On Tuesday, November 21, 2017 at 12:35:12 PM UTC-5, Irene Polikoff wrote: 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;] ; Would this assume one :Address? How would you pair one :streetAddress and :City on a first :Address and second :streetAddress and :City on a second :Address using the longer property path? Good question. This would definitely be a problem if address cardinality was greater than 1. For this reason, we typically do not use this approach and, instead, support nested form widgets. Having said this, I wanted to point out that this design pattern was a possibility. Its application is limited to cardinality not greater than 1 or to situations where you only need a single property from a resource that is in the “multiple hops" distance. 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. Thanks for the reminder; we're hoping to be usefully specific about our classes and datatypes. :) 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 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. I took a look at the tosh extension both in and outside of TopBraid Composer FE, but I'm having trouble imagining how to specify the nested object form widgets correctly. Are you saying there is an ObjectEditorClass in tosh that is specifically for a nested object form widget? If so, I don't see one. Either way, could you provide an example in .ttl? Yes, exactly. Something like: :Author rdf:type sh:NodeShape ; sh:property :Author-address ; sh:property :Author-name ; . Since this is simply an example, I am skipping using any targets here. You already know how to do it. There are two options: * You add sh:property statements directly to the class foaf:Agent - implicit target. With this, you would not have :Author resource. You simply use foaf:Agent as the subject of the above triples. * Or you separate classes from shapes, use different resources and connect them using the target statement. Some wonder if the second option is better for re-use. For example, you may want to have two different shapes for Authors and chose when to use them. I do not believe explicit targeting offers superior support for re-use or for controlling scope of applicability of a shape. The moment you set your target to a class e.g., foaf:Agent, this is for all instances of the class you are dealing with. If you have two different shapes, then both will apply. The only way to control what shape to use is by including only one of the shapes into your shapes graph. So, this is about separating triples, partitioning graphs, etc. How you separate your triples, however, is not related to how you define targets. You can implement such strategies with implicit targets as well as with explicit ones. I am using URIs for property shapes instead of blank nodes. We recommend this as a better practice. :Author-address rdf:type sh:PropertyShape ; sh:path :address ; tosh:editWidget swa:NestedObjectEditor ; tosh:viewWidget swa:NestedObjectViewer ; sh:class :Address ; sh:group :AddressGroup ; . Then the shape for addresses would say that there are 2 properties: street address (datatype xdd:string) and city (sh:class City). There are many different widgets defined. * 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]<http://cornell.edu/>> 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://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]<http://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 [email protected]<mailto:[email protected]>. 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 [email protected]<mailto:[email protected]>. 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
