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]
<mailto:[email protected]>.
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/8ded43f2-7f8a-8221-81ee-17cc00992af7%40topquadrant.com.
