OK that makes sense for this widget - sounds cleaner than hiding - might need to create a tree of dummy classes to control which subclasses are relevant I guess.
This doesnt solve the other problem of needing to define propertyShapes for all the classes you use, without changing the data or ontology graphs. I'll experiment with a load-time transformation to generate the dummy class tree and propertyshapes, stuff it in an extra graph and import it. On Friday, 24 April 2020 13:20:25 UTC+10, Irene Polikoff wrote: > > I would normally create a parent class for all classes I am interested in, > then make it a root of the classes tree. I like it more than the hiding > option. > > On Apr 23, 2020, at 10:33 PM, Rob Atkinson <robatki...@gmail.com > <javascript:>> wrote: > > I think the hidden field for classes in the tree is the minimal starting > point - without that we cant really do very much. Its still messy having to > build a complete suite of hide-me statements. > > A more general solution would be pluggability of the selection for what to > display. I can see a couple of ways of controlling this - but a SPARQL > expression to control the graph closure override would be good starting > point - at the moment it is presumably using something like > teamwork:graphWithImports - but perhaps its actually all mediated by > graphql - and the "shape i care about" and graphql schema options are also > closely aligned concepts? > > If the class hierarchy actually displayed the graphql schema available, > and multiple such schemas were available, that would in fact be awesome - > and you could use the class and property selector to help build graphql > queries :-)\ > > It would be helpful to have a sense of the current and potential extension > points for this widget - then we could minimise limited hard-coded > solutions. > > > On Friday, 24 April 2020 11:28:19 UTC+10, Holger Knublauch wrote: >> >> This thread seems to cover multiple topics now, so here is a partial >> response. >> >> On 24/04/2020 00:44, dprice wrote: >> > Note that this problem isn’t actually about SHACL or OWL2SHACL. It >> > also appears in any OWL-driven UI where the user is forced to see the >> > entire content of the ontologies in the scope of the imports, even >> > when not of interest. >> > >> > Seems like a nice way to specify “the things I care about” before >> > doing the OWL2SHACL might do the trick in EDG. At the moment, to say >> > what I care about I sometimes delete things from my local copy of the >> > “immutable” ontologies such the they contain only the subset of >> interest. >> > >> > After-the-fact you can deactivate shapes and in EDG you can use Main >> > Class to help some. However, would be nice to be able to specify “the >> > things I care about” once and have that flow thru into everywhere >> > appropriate in EDG to limit the UI to only show that subset of the >> > larger scope. >> >> So for properties we recently introduced the dash:hidden flag which will >> keep the validation in place but hide the property from the forms. We >> don't have something similar for classes yet. A relatively easy addition >> would be a dash:hidden flag for rdfs:Classes that would hide the class >> and its subclasses from the classes tree. Note this would affect the >> Class Hierarchy panel only, but then also the Classes and Instances >> layout. >> >> A process then would be to mark the irrelevant properties and classes >> hidden in an Ontology that owl:imports the underlying original >> ontologies. Even if the external ontology is updated, the flags for the >> local context would still remain in place. >> >> Another thing that might be useful is for the Class Hierarchy to have an >> option to display the number of instances in brackets? >> >> TBC also has the Find All Locally Defined Resources button that is very >> useful when exploring what's actually in a graph. This wouldn't scale >> but might be another low-hanging piece in the puzzle? >> >> Holger >> >> >> > -- > 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 topbrai...@googlegroups.com <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/623393e8-3f97-44ee-a8cf-f3320b0abdeb%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/623393e8-3f97-44ee-a8cf-f3320b0abdeb%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- 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 topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/5db23b0a-61d8-4683-846f-3be61ba21950%40googlegroups.com.
