<image.png>--
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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0Wbn%2BZjZUctPOnHCGZ2HOvYuXE1aaB3jfmW6tJxndegZ3YuA%40mail.gmail.com.
On Apr 21, 2020, at 7:13 PM, Tim Smith <smith...@gmail.com> wrote:
Hi,In the Class List Panel, is it possible to show only classes in the current graph?When I select "Return local results only", I still see a lot of entries that are coming from imports. The screenshot shows a number of entries from the ns/vcard foaf ontologies including restrictions (bnodes).
My objective is to find errors in my ontologies as I import over two dozen ontologies into EDG (and convert to SHACL). I cannot find a way to run the Problems and Suggestions report on my graph only. It always includes the imports so I get a huge number of problems in ontologies that I do not control. This makes it hard to tell what I need to fix in my ontology vs the imports so was using the Class List Panel to help identify problems.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/D88D6309-E9B9-4C20-A249-26E72550AD0E%40topquadrant.com.
On 22/04/2020 12:38, Rob Atkinson wrote:
tracking this with interest :-)
I too find it awkward when I am working with immutable OWL resources from standards but EDG requires the shapes - so end up doing complex automated loading where I generate a wrapper ontology to contain created shapes and then update imports in instance data to include these shapes instead of the original ontology so EDG works. What I really need to do of course is to have the shapes file be a profile of the original ontology that matches the things I care about and not populate the environment with a lot of irrelevant stuff - which matches the original use case - only show relevant classes.
Please help me understand the user experience that you'd like to see here. TopBraid would, if available, basically always request a SHACL-profiled version of an ontology. Even with the automated converter some ontologies require manual post-processing of the SHACL. So are you suggesting
- to have some alias mechanism that automatically substitutes one
owl:import with another owl:import so that a SHACL file gets
preferred over a pure OWL file?
- to run the OWL2SHACL algorithm if an ontology seems to contain
an OWL ontology that is not covered by SHACL? If yes, how would it
recognize that.
So for a given ontology there are actually multiple choices for what you show in the class view:1) all the classes in the ontology using the current graph with imports2) all the classes in current graph3) only the classes represented by instances in the current graph4) only the classes represented by instances in the current graph with imports5) all the potential classes defined by a shape - a profile of the closure over owl imports. - allowing you to select classes not populated and create new instances.
I assume all these cases could be expressed using SPARQL queries. So you could probably save those queries and re-run them from the SPARQL Library panel? In 6.4 we are adding the ability to parameterize those SPARQL queries, so that when you press the execute button you can fill in the values for any "pre-bound" $ variable.
Holger
The last is actually how most of the rest of EDG works by customisation of shapes to drive UI - and is most powerful and user friendly so I'd vote for making this the default behaviour for all widgets with a switch to the other modes.
On Wednesday, 22 April 2020 09:14:00 UTC+10, Tim Smith wrote:Hi,
In the Class List Panel, is it possible to show only classes in the current graph?
When I select "Return local results only", I still see a lot of entries that are coming from imports. The screenshot shows a number of entries from the ns/vcard foaf ontologies including restrictions (bnodes).
My objective is to find errors in my ontologies as I import over two dozen ontologies into EDG (and convert to SHACL). I cannot find a way to run the Problems and Suggestions report on my graph only. It always includes the imports so I get a huge number of problems in ontologies that I do not control. This makes it hard to tell what I need to fix in my ontology vs the imports so was using the Class List Panel to help identify problems.
Tim
--
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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/af51fb0a-40c3-4ffc-9e8e-bb87842631e2%40googlegroups.com.
On 23 Apr 2020, at 07:11, Holger Knublauch <hol...@topquadrant.com> wrote:On 22/04/2020 12:38, Rob Atkinson wrote:
tracking this with interest :-)
I too find it awkward when I am working with immutable OWL resources from standards but EDG requires the shapes - so end up doing complex automated loading where I generate a wrapper ontology to contain created shapes and then update imports in instance data to include these shapes instead of the original ontology so EDG works. What I really need to do of course is to have the shapes file be a profile of the original ontology that matches the things I care about and not populate the environment with a lot of irrelevant stuff - which matches the original use case - only show relevant classes.
Please help me understand the user experience that you'd like to see here. TopBraid would, if available, basically always request a SHACL-profiled version of an ontology. Even with the automated converter some ontologies require manual post-processing of the SHACL. So are you suggesting
- to have some alias mechanism that automatically substitutes one owl:import with another owl:import so that a SHACL file gets preferred over a pure OWL file?
- to run the OWL2SHACL algorithm if an ontology seems to contain an OWL ontology that is not covered by SHACL? If yes, how would it recognize that.
So for a given ontology there are actually multiple choices for what you show in the class view:1) all the classes in the ontology using the current graph with imports2) all the classes in current graph3) only the classes represented by instances in the current graph4) only the classes represented by instances in the current graph with imports5) all the potential classes defined by a shape - a profile of the closure over owl imports. - allowing you to select classes not populated and create new instances.I assume all these cases could be expressed using SPARQL queries. So you could probably save those queries and re-run them from the SPARQL Library panel? In 6.4 we are adding the ability to parameterize those SPARQL queries, so that when you press the execute button you can fill in the values for any "pre-bound" $ variable.
Holger
--
The last is actually how most of the rest of EDG works by customisation of shapes to drive UI - and is most powerful and user friendly so I'd vote for making this the default behaviour for all widgets with a switch to the other modes.
On Wednesday, 22 April 2020 09:14:00 UTC+10, Tim Smith wrote:Hi,
In the Class List Panel, is it possible to show only classes in the current graph?
When I select "Return local results only", I still see a lot of entries that are coming from imports. The screenshot shows a number of entries from the ns/vcard foaf ontologies including restrictions (bnodes).
My objective is to find errors in my ontologies as I import over two dozen ontologies into EDG (and convert to SHACL). I cannot find a way to run the Problems and Suggestions report on my graph only. It always includes the imports so I get a huge number of problems in ontologies that I do not control. This makes it hard to tell what I need to fix in my ontology vs the imports so was using the Class List Panel to help identify problems.
Tim
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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/af51fb0a-40c3-4ffc-9e8e-bb87842631e2%40googlegroups.com.
--
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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/cfebfadd-cdc4-d22c-6911-57aed194f146%40topquadrant.com.
I too find it awkward when I am working with immutable OWL resources from standards but EDG requires the shapes - so end up doing complex automated loading where I generate a wrapper ontology to contain created shapes and then update imports in instance data to include these shapes instead of the original ontology so EDG works. What I really need to do of course is to have the shapes file be a profile of the original ontology that matches the things I care about and not populate the environment with a lot of irrelevant stuff - which matches the original use case - only show relevant classes.Please help me understand the user experience that you'd like to see here. TopBraid would, if available, basically always request a SHACL-profiled version of an ontology. Even with the automated converter some ontologies require manual post-processing of the SHACL. So are you suggesting
- to have some alias mechanism that automatically substitutes one owl:import with another owl:import so that a SHACL file gets preferred over a pure OWL file?
- to run the OWL2SHACL algorithm if an ontology seems to contain an OWL ontology that is not covered by SHACL? If yes, how would it recognize that.
I run into similar situations on occasion. Right now I have a scenario that needs about 15 classes and about 80 properties that are largely taken from standards like DC and Prov-O. However, if you import everything that is required to make the graphs complete you end up with the items of interest being maybe 25% of the union of the ontologies. IMO a way to address that issue elegantly would be a far more useful feature than worrying about changing an import here or there (e.g. can workaround that by adding shapes import to the OWL and you don’t have to modify any data graphs).
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 a given ontology there are actually multiple choices for what you show in the class view:1) all the classes in the ontology using the current graph with imports2) all the classes in current graph3) only the classes represented by instances in the current graph4) only the classes represented by instances in the current graph with imports5) all the potential classes defined by a shape - a profile of the closure over owl imports. - allowing you to select classes not populated and create new instances.I assume all these cases could be expressed using SPARQL queries. So you could probably save those queries and re-run them from the SPARQL Library panel? In 6.4 we are adding the ability to parameterize those SPARQL queries, so that when you press the execute button you can fill in the values for any "pre-bound" $ variable.
> - to have some alias mechanism that automatically substitutes one owl:import with another owl:import so that a SHACL file gets preferred over a pure OWL file?
I think the need would be some way of choreographing creating a custom shape, saving it for reuse, and importing it - and either removing the other imports or providing a flag on custom shapes so that if present these are preferred over shape libraries or ontologies. This needs to be scriptable, because we would want to automate it for the general case of loading D imports O - where D and O are readonly assets - reference data and ontologies used to support an application domain.
Exploiting EDG workflows to create the new shapes in reviewable mode would be great - but if we just created the master graphs that would be fine - we could also manually intervene to review - or set up additional scripting to create all the review steps.
> - to run the OWL2SHACL algorithm if an ontology seems to contain an OWL ontology that is not covered by SHACL? If yes, how would it recognize that.
EDG doesnt seem to function without shapes, so it should be possible to set up a SHACL validation that looks for instances of classes in a data graph that do not have shapes, and instances of properties of those classes not covered by shapes.
--
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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/623393e8-3f97-44ee-a8cf-f3320b0abdeb%40googlegroups.com.
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
--
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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/623393e8-3f97-44ee-a8cf-f3320b0abdeb%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@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.
As a first step I am adding support for dash:hidden at classes to
make them disappear from the Class Hierarchy. There will be a
button/setting to also show hidden classes as a fallback, e.g. to
un-hide certain classes. This will be default for system classes
that usually nobody wants to see under owl:Thing: owl:Nothing,
owl:Restriction and owl:NamedIndividual.
There will be equivalent support for the Taxonomy Hierarchy, using dash:hidden at skos:Concepts and skos:ConceptSchemes. This had been requested before by customers.
These triples may stem from imported ontologies or may be generated into some proxy ontology - the system doesn't care where these boolean triples come from but at least the trees are able to react to those flags now.
HTH
Holger
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/2AB87BF7-0E89-4013-93BC-CA792FDBD8E5%40topquadrant.com.
There is room for a new convenience feature here - a wizard that produces "proxy ontologies" for a collection of (OWL) ontologies that have been uploaded into the workspace (or would be downloaded from a given URL). Such a feature would offer the user to select which of these uploaded graphs to pick, and then would produce one EDG Ontology for each selected graph, with a label such as XY Shapes. Each of these graphs would owl:import the graph that it wraps and include the shapes produced by OWL2SHACL. If the original graph has owl:imports then the proxy would contain owl:imports to the respective proxy ontologies.
So assuming you have TTL files
A owl:imports B
B owl:imports C
the algorithm would produce
urn:x-evn-master:A owl:imports A, urn:x-evn-master:B
urn:x-evn-master:B owl:imports B, urn:x-evn-master:C
urn:x-evn-master:C owl:imports C
Users can then manually post-process the SHACL axioms where needed and generally use the SHACL versions instead of the original ones. The labels, comments, subClassOf triples etc of the original files would "shine through" from the owl:imports closure, and there is no harm in keeping owl:Restriction triples or RDFS domain/range statements in the original files either.
I'll record this idea as a ticket, but wanted to put this out
here in case anyone has further feedback. It doesn't sound like
huge development effort.
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 topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/11eff17a-553e-4e6e-911e-ce9362184a15%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8afc4d44-9216-9d87-4888-a1087bfe17e0%40topquadrant.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8afc4d44-9216-9d87-4888-a1087bfe17e0%40topquadrant.com.
To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/11eff17a-553e-4e6e-911e-ce9362184a15%40googlegroups.com.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8afc4d44-9216-9d87-4888-a1087bfe17e0%40topquadrant.com.
Ok, I made a bit of progress today and have a new feature
candidate ready. I'll show the current state here to get possible
feedback before we release the beta. This is something that ought
to be tested hands-on though.
It begins with the Create Proxy Ontologies button here:
This opens a page that lists all user-uploaded graphs and any of their owl:imports from the TopBraid/Common folder, such as
With the shown choices it will create two Ontologies. (DatacubeX
is just owl:importing DataCube and defines one subclass):
and
And yes, each generated Ontology includes SHACL shapes
To quote Aragorn: What say you?
Holger
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/f75471b6-9cea-4762-89e9-18344ba094a1%40googlegroups.com.
Looks great...
“I seem to see ahead, in a kind of way. I know we are going to take a very long road, into darkness; but I know I can't turn back.”
Can we also have the template for achieving this programmatically in SWP script. ( I can beta test it at a script level before the UI is released, and I'd deploy using scripting anyway.)
Yes, this is already implemented as an SWP service with parameters as selected on the form.
Holger
On Tuesday, 28 April 2020 17:08:12 UTC+10, Holger Knublauch wrote:
--
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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1491609f-d5e2-4bf7-9ab5-20e292b5de08%40googlegroups.com.
On 28 Apr 2020, at 08:07, Holger Knublauch <hol...@topquadrant.com> wrote:
Ok, I made a bit of progress today and have a new feature candidate ready. I'll show the current state here to get possible feedback before we release the beta. This is something that ought to be tested hands-on though.
It begins with the Create Proxy Ontologies button here:
<bnfhnoiejjifpbca.png>
This opens a page that lists all user-uploaded graphs and any of their owl:imports from the TopBraid/Common folder, such as
<jobhkgobfalgeklj.png>
With the shown choices it will create two Ontologies. (DatacubeX is just owl:importing DataCube and defines one subclass):
<hdbocdckllpdkgag.png>
and
<pdhdjckgoikgkhbd.png>
And yes, each generated Ontology includes SHACL shapes
<iokcoeanmmkkikep.png>
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/2f256a24-bfa5-24f8-bc3b-9e4c4f61521c%40topquadrant.com.
> To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.
The public classes get defined transitively via owl:imports, so: right, once one ontology in the imports closure defines a class as public there is no way to override that in others (if that's a problem in the first place). The only way around that is to put the publicClass triples into dedicated wrapper Ontologies. But I don't really see how to automate that as it's an entirely manual and arbitrary decision from the modeler.
Holger
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/7c703c20-e63f-46ea-bef6-db84a9d815c0%40googlegroups.com.