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 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 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]> 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]. For more options, visit https://groups.google.com/d/optout.
