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
o 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?
o 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 [email protected]
<mailto:[email protected]>.
For more options, visithttps://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.
