Q: EDG Class List Panel - How to show only classes in the current graph (no imports)

[Tim Smith]

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

[Ralph TQ [Gmail]]

Tim,

I have some input I can give on selective validations. 

One way is through an API provided as described next.

On the available API services on this page, http://localhost:8083/tbl/swp?_viewClass=servicedoc:Index, accessible from http://localhost:8083/tbl/admin there is this validation service:

Here is the SHACL validation service:

There are other ways to do selective validation and there is an SWP script that I could send that would let you automate what you are doing. 

This next image might give some idea of what the SWP script for a list of resources provided in a REST call:

I might be overlooking a new feature that we may have introduced to do a graph-specific validation in the UI. I’ll get back on that.

I would like to discuss these things with you.

Ralph

<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.

[Irene Polikoff]

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).  

Are you sure they are not in the local graph? The way to check is to click on a class and look in the Source Code panel. If you see something in the top of that panel, these are triples in the selected graph.

For me, when I click on “Return local results only” in this panel, I do not get any classes from the included graphs.

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.

You can go to http://localhost:8083/tbl/swp?_viewClass=tblshacl%3AValidationPage (if in TBC, otherwise replace localhost). You can run validation there and select whether to validate included graphs.

I think when you use a Problems and Suggestions panel, validation will focus on resources that are members (transitively) of the main entity for the current asset collection. For example, if you look at TQ samples (downloaded from https://www.topquadrant.com/topbraid-composer-install/ ) and try to run validation of Currencies reference dataset, instances of countries will not be validated although they are included in currencies . But if you have two graphs where graph A is included in graph B, A contains instances of class X and class X is a subclass of the “main entity” for graph B, then I believe these will be validated when using Problems and Suggestion to run validation for graph B. There is also a way to filter in order to validate only instances of a class you select (click on the filter icon in the panel). 

[Tim Smith]

Hi Ralph and Irene,

@Ralph - I would like to discuss the options you shared.  I also have much broader use cases where such automation would be very helpful.  I will, hopefully, be getting to those in the coming weeks after I build a great prototype in TBC/EDG.  I have time this week if you are available for a call.

Thank you for the responses.  I have found part of the problem.  I have been transforming the OWL restrictions to SHACL without including any of the imports.  I must have erroneously checked one of the imports for the example I sent.  The NodeShape was in the main graph but the rest of the Class definition was in the imported graph as it should be.  I removed all of the NodeShapes and other triples created from the transform and that has cleaned up this problem.  I think I will look for a way to create the SHACL for the imports and keep them in a separate graph.  I know I can do this in TBC using Model -> Convert OWL/RDFS to SHACL.

I shall also investigate the Validation Service to see if that will make the process faster.

I still see some Restrictions from imports appearing in the Class list that have no component in the main graph as shown in the first screenshot.  EDG also throws a GraphQL error when I first click onthe restriction in the Class List.  I will look further at those.

Thanks once again for your help!

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/D88D6309-E9B9-4C20-A249-26E72550AD0E%40topquadrant.com.

[Rob Atkinson]

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.

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 imports

2) all the classes in current graph

3) only the classes represented by instances in the current graph

4) only the classes represented by instances in the current graph with imports

5) 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.

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.

[Holger Knublauch]

On 22/04/2020 12:13, Tim Smith wrote:

> EDG also throws a GraphQL error when I first click onthe restriction
> in the Class List.  I will look further at those.

Thanks for this report. It was the Instances panel crashing when the
user selected a bnode class. I have fixed this for 6.4.

Holger

[Holger Knublauch]

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 imports

2) all the classes in current graph

3) only the classes represented by instances in the current graph

4) only the classes represented by instances in the current graph with imports

5) 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.

[dprice]

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.

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 imports

2) all the classes in current graph

3) only the classes represented by instances in the current graph

4) only the classes represented by instances in the current graph with imports

5) 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.

So perhaps these are ways to create a WHERE clause to use to automate saying “I care about this” to classes/properties so only they appear in the UI? I’m not quite sure what’s being suggested.

Cheers,

David

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.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Rob Atkinson]

 

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).

yes - thats exactly the issue

 

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. 

Shapes give us this opportunity - so the question is how to get shapes created and into play in the most elegant way possible

 

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 imports

2) all the classes in current graph

3) only the classes represented by instances in the current graph

4) only the classes represented by instances in the current graph with imports

5) 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.

SPARQL is no problem - but its 'off to the side' in the UX  - what we are talking about is being able to quickly move from comprehensive OWL+instances  to an EDG friendly  SHAPE-I-care-about + instances view. 

There are a few challenges with using the OWL2SHACL converter (in either EDG or TBC) - you need to start with:

D = my data 

O* = the imported ontology set (with standard transitive closure of imports)

D imports O*

EDG cannot do much with D at this stage ..

So we need to end up with:

OS*  = set of possible shapes derived from O* - where each O in O* has a corresponding shape graph OS  and OS imports O

S = my SHAPEs of interest - selected from OS*

D imports S

D imports O

create T

T imports O, OWL2SHACL

run transformations

Save T

Remove imports from T

T imports O

D imports T

(this is actually more complex if you want to allow it to be guided by the data in D - unclear if EDG restrictions on instances and classes get in the way here)

and finally D is EDG ready! 

But we still have a zillion shapes derived from O*  making it unfriendly  ;-(  ....   T != S 

so if EDG supported T imports D - and only deriving shapes relevant to the data it would help - but only if you had data in advance.

Selecting specific classes would be fine - but for this to be workable it needs to allow you to choose a superclass and all sub-classes get converted.  

- one possibility is to selectively import OS from OS* - i.e. the imports of shapes needs not to be transitive - but this may not be possible without yet another dance to duplicated and remove imports - so it may just be necessary to create declarations for _all_ shapes in OS* and declare them deactivated. This feels kinda horrible - and I'm not sure its what you want anyway - what we really want is to have S, but inherited any constraints from OS* without promoting these to being first classes members of S - my shape of interest. Maybe I'm missing a mechanism here. 

If EDG only uses the direct imported shapes graph then that would keep all the imported details hidden - but it would stop you using modular design of your own shapes - a Bad Thing

But we also need to make OSx in OS* - as separate graphs because O* must be read-only! 

At the moment we need to do a complicated dance:

D imports O

create T

T imports D, OWL2SHACL

run transformations

Save T

Remove imports from T

T imports O

D imports T

and finally D is EDG ready! 

so really we want D imports S* 

Sx in S* imports OSx imports Ox

and EDG uses shapes in S*

so as Holger suggests it will need to flag this somehow to know..

> - 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. 

NB TBC has a "derive shapes for instances" - AFAICT it allows you to look at instances - so to use this you need to do a little dance to create a new file - import the instances (because you dont want to pollute that) and all all the ontologies - then you seem to need to manually select all the object types - but this is driven by the ontology - again if it just selected by default all the classes represented in the instances and allowed you to deselect the ones of no interest that would help.

So it would be good if EDG was able to resolve "no shape for data I have" cases with the derivation of shape graphs for each ontology in the import tree with data locally represented, and a custom shape graph that imports these and includes selections. 

 This is not trivial - so perhaps we could test it in phases:

1)  provide a recommended manual recipe for users to create all the shapes for transitive imports of readonly ontologies and access them in context  (perhaps there is something simpler than the mess I described above!)

2)  allowing users to have the custom shapes override the default imports in the Ux

3) provide a widget to build a custom shape

4) provide option to automate shape building for imported ontologies and set up imports

Philosophically, EDG already does import magic for users based on specific asset types, this allows us to have some control over the same set of requirements applied to generic asset types.

[Holger Knublauch]

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

[Rob Atkinson]

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.

[Irene Polikoff]

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.

--
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.

[Holger Knublauch]

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.

[Rob Atkinson]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.

[Rob Atkinson]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.

[dprice]

I’ve used Irene's suggestion, but I’m not sure an artificial superclass can solve the problem of subclasses of a used class that are not to be used. I’ve never tried it.

Also, it’s not quite as elegant to take an EDG-only approach for classes and a dash-based approach for properties. If we can design better way that makes it easy for ontologists to manage these scenarios, I think that would be a nice improvement. I’d also prefer this to be something specified entirely in the build-time ontologies/shapes rather than anything that is somehow generated while using the UI (although I’m not 100% clear if that’s being proposed or not). I’ve not run into situations where I needed runtime control over what’s used and what’s not.

Cheers,

David

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.

[Holger Knublauch]

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.

[Holger Knublauch]

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.

[Rob Atkinson]

+1 

Ideally you can run this wizard with different target names and create and import additional versions of these shapes easily - and then disable elements you dont want, so as to have different NodeShape driven views of objects readily available in the UI and GraphQL interfaces.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8afc4d44-9216-9d87-4888-a1087bfe17e0%40topquadrant.com.

[dprice]

Yes please and please support this scenario: we’ve had different business units in the same customer using different subsets of things like the W3C Prov-O ontology. So, there’s not necessarily only one “profile” of A, B or C.

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8afc4d44-9216-9d87-4888-a1087bfe17e0%40topquadrant.com.

[Rob Atkinson]

And ideally this issue (making selected classes public so they are visible via GraphQL) should be dealt with elegantly in the same process:

https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLXqGW5%2BsVEtCVScXo7YH%3DJuFxvySjEgEQ68iOntthsrw%40mail.gmail.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.

[Holger Knublauch]

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.

[Rob Atkinson]

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.) 

On Tuesday, 28 April 2020 17:08:12 UTC+10, Holger Knublauch wrote:

google.com/d/msgid/topbraid-users/f75471b6-9cea-4762-89e9-18344ba094a1%40googlegroups.com.

[Holger Knublauch]

On 28/04/2020 17:34, Rob Atkinson wrote:

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:

google.com/d/msgid/topbraid-users/f75471b6-9cea-4762-89e9-18344ba094a1%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/1491609f-d5e2-4bf7-9ab5-20e292b5de08%40googlegroups.com.

[dprice]

1) Looks really good. Note that  TQ has used the term “proxy ontology” to mean an OWL/RDFS representation of an XSD in many presentations and customers.

What about “profile ontology”? That’s what OMG calls UML subsets/extensions of the language basics and is what OWL 2 uses to mean specific subsets of the language. I think DCAT standard also has the same “profile” idea.

3) Can I also use this if starting from a SHACL shapes graph and subset it for specific scenarios? If not, can that be added? I’ve had two customer situations where there was a mix of OWL and SHACL that needed to be subsetted.

Cheers,

David

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.

[Holger Knublauch]

On 28/04/2020 20:27, dprice wrote:

> 1) Looks really good. Note that  TQ has used the term “proxy ontology”
> to mean an OWL/RDFS representation of an XSD in many presentations and
> customers.
>
> What about “profile ontology”? That’s what OMG calls UML
> subsets/extensions of the language basics and is what OWL 2 uses to
> mean specific subsets of the language. I think DCAT standard also has
> the same “profile” idea.

I picked "proxy" because these ontologies are really just empty shells
around existing Turtle graphs. They merely add triples but the
definitions of classes and their labels etc remain in the original
imported graphs.

I didn't know Proxy ontology was already used. Profile ontology doesn't
work much better for me though unless we prefix it with something like
"Shape Profile ontology". Maybe I just call this feature "Create EDG
Ontologies for existing files"?

Where is 2) ? :)

>
> 3) Can I also use this if starting from a SHACL shapes graph and
> subset it for specific scenarios? If not, can that be added? I’ve had
> two customer situations where there was a mix of OWL and SHACL that
> needed to be subsetted.

This wizard does not have the ability to batch-deactivate certain
shapes. That could be a separate dialog from the Ontology editor. Feel
free to create a Jira ticket if you have input.

Holger

[Ralph Hodgson]

Facade is maybe a good name

Sent from my iPhone

> On Apr 28, 2020, at 8:03 PM, Holger Knublauch <hol...@topquadrant.com> 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/46c98ea4-4ac9-f718-4280-2883534998cf%40topquadrant.com.

[Rob Atkinson]

A corollary of this issue is the GraphQL public schema 

We need to make a statement about the ontology in order to enable things in a data graph based on that ontology.  We are interested in this for the data graph.  Is it logical to push   graphql:publicShape my:lovelyClass statements into the proxy/facade shapes and make them available for all data graphs that use it, or replicate it in each data graph - in which case how best to automate this important step?

should it be possible to override an imported statement with a local preference?  In general, is this the same problem - we have autogenerated shapes for all ontologies available, but we can import one or more profiles based on these to control display options?  If so, automation of   population of graphql:publicShape should be considered since things dont work well without them

> To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.

[Holger Knublauch]

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.