Also, it is not often cut and dry as to what is a UI and what is not. Clearly, sh:group and groups themselves are UI. Sh:order is UI. Any special widgets you declare for new and edit are UI.
sh:name is not only a UI because it is used in GraphQL API calls. MVC is about keeping application views separate from the underlying model. A view may be about APIs and not only a UI in EDG. Such view includes inferred properties you may want to define using sh:values and sh:defaultValue. It may include alternative Node Shapes that you will want to declare as preferred (default) views for some stakeholders (by associating them with a governance role). The decision what to keep separate and whether to keep anything separate becomes, as David is saying, a matter of desired architecture. Separation gives more modularity, but it also brings some additional complexity because you can’t simply add everything into one ontology and need to establish and follow a practice is to what to add in the ontologies with classes and their associated shapes and what to add into the models containing view-oriented shapes. There are clearly tradeoffs either way. > On Apr 30, 2019, at 11:33 AM, dprice <[email protected]> wrote: > > Hi Eva, > > As Irene said, we don’t have a strong recommendation about what you should do > since we don’t understand your environment. That said, there are some > patterns, principles and practices that you might consider in making your own > decision. They may or may not be important in your environment. > > Keeping an EDG UI graph separate from the data structure/validation graph is > not too far away from the MVC pattern. See > https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller > <https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller> > > There’s also the much more general notion of separation of concerns you can > apply to graphs a bit differently than to program code, but the general idea > holds. > > See https://en.wikipedia.org/wiki/Separation_of_content_and_presentation > <https://en.wikipedia.org/wiki/Separation_of_content_and_presentation> > > See https://en.wikipedia.org/wiki/Separation_of_concerns > <https://en.wikipedia.org/wiki/Separation_of_concerns> > > The rate of change is usually different for various artefacts. For example, > user requirements often drive regular change to property group assignments > but the underlying ontology seldom changes once there’s a lot of data to > manage. > > Following these ideas often leads to adopting a graph (or ontology) > architecture. For some customer projects, an ontology architecture document > is an early formal deliverable so that everyone can follow the agreed > approach consistently. > > Due to the need to change graphs over time, I nearly always keep the graph > that controls the EDG UI (e.g. property groups) separate from the data > structure/validation graph. That’s true even for my own sandbox development. > A really nice side benefit is that it’s also much harder to accidentally > break an ontology when only meaning to change a bit of the EDG UI if you’re > not editing the ontology graph. > > Cheers, > David > >> On 30 Apr 2019, at 15:03, Irene Polikoff <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Eva, >> >> We do not a strong recommendation either way. It is up to you and what you >> are planning to do with these ontologies. >> >> If you will be exporting them for use in some other tool that does not >> understand SHACL, you may be more inclined to maintain separation. However, >> SHACL is just RDF and if a tool does not understand it, these would simply >> be extra RDF statements. If the ontology is primarily for use in EDG, you >> may even consider, as part of conversion, to remove OWL restrictions.. >> >> In general, if you have OWL ontology that you need to convert to SHACL, the >> steps would be: >> >> 1. Convert from OWL to SHACL. This can be done in TBC (Model menu) or in EDG >> (Transform menu). You will get an option of whether you want to keep OWL >> axioms or remove them. TBC will offer an option of creating a separate >> shapes file. In EDG, generated shapes will be rewritten directly into the >> ontology you are converting, but if you want to keep the separation, you can >> create a new ontology, include ontology with RDFS/OWL in it and then run the >> transformation. >> 2. Add shapes for any inverses or other property paths that you want to >> appear on forms, be accessed through APIS, etc. Also add shapes for any OWL >> axioms that were not converted automatically >> 3. Enrich generated shapes with information about form sections (sh:group), >> display order (sh:order), special view/edit widgets, if any, sh:name if the >> display name is different from the property name. >> 4. Add sh:values and sh:defaultValue rules, if necessary >> >> >>> On Apr 30, 2019, at 9:09 AM, Eva Ibarra Sicilia >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Hello all, >>> As a general recommendation, should SHACL forms be created and maintained >>> in a separate graph, and be included in the ontology via imports? Or should >>> they be directly defined in the class resource in the ontology? >>> Thank you! >>> Eva Ibarra >>> >>> -- >>> 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] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > UK +44 (0) 7788 561308 > US +1 (336) 283-0808 > > > -- > 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.
