Agree it needs UI logic extension point that we can generate static data (a shapes graph) to control - certainly dont want to be looking at the data at run-time. SHACL shapes like OWL2SHACL that build such shapes graphs seem like a reasonable compromise.
On Friday, 24 April 2020 13:40:24 UTC+10, Holger Knublauch wrote: > > It's a nice vision. My concern is that doing any transformations or > filtering at query time will likely be very expensive. We need to make sure > that our architecture also works for customers with millions of triples, > not just for ontology editors. A one-off SPARQL query is unlikely to > refresh well after changes/edits. A naive implementation of a SHACL-based > filtering would require to iterate over all (target) nodes and filter them > one by one. So there are some really challenging algorithms to do here > before such a stack can be delivered. Having said this, our working copies > are implemented as filtered graphs that dynamically add or delete triples > at query time. These however are rather static and follow a > straight-forward recipe. > > A more direct and incremental approach to supporting > filtering/transformations in the UI is to put the logic into the UI code > itself, even if this makes it less "clean" from a model-driven POV. > > Holger > > > On 24/04/2020 12:33, Rob Atkinson 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 [email protected] <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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/4277756e-bc0c-4724-8a3e-8cc6077aa19e%40googlegroups.com.
