> On Sep 27, 2021, at 5:31 PM, Simon Opper <[email protected]> > wrote: > > Thanks for the info Holger and Irene > > Yes, Irene, I am referring to hiding asset collections. > > It seems to me that "view ( read) data access" should be able to be managed > differently from "visibility" in asset collection menus and lists and indeed > in a datagraphs "settings" menu import lists.
Perhaps, but this is not a requirement we have heard nor implemented. You can submit it through the support desk for future consideration. The more you could tell us about the overall use case and its context, the better. Such feature would need to be carefully considered and designed to work for different customers. > Could they be "hidden imports" for certain roles and governance models 1? > > Our use case is that we have upwards of 10 or so ontologies and shapes > ontologies that support downstream graphs in use by users, but they don't > need to see them in menus or know that they are there at all. One option available today is to implement such ontologies as files. Starting with 7.0, you can edit files with EDG. The downsides of this approach: 1. Only Administrators are able to edit Files. 2. It is one person editing at the time 3. There is no persistent audit trail across the edit sessions. Once the change is saved, the audit trail is gone. However, Git integration coming in 7.1 may help address this limitation. I have not looked at it deeply enough though. This approach would be best for “system” ontologies that only a small group of pretty technical users would ever be changing. > For a general subject matter expert user who may only need to look at and > work in around 2 or 3 graphs, there is a growing set of data graphs and > tagsets used by other layers of users that import into these, and so the > import closure spreads across many collections. Even after using role-based > and subject area asset collection permission use the import net becomes very > wide. Now you seem to be talking about hiding data graphs and tag sets. Or am I confused? > > We have talked about using rules (sparql) to insert data into other graphs > instead of using imports, to try and deal with this, but it takes that extra > amount of work to achieve this, especially for every graph and so we've not > committed to this. > > Cheers > > Simon > > On Thursday, September 23, 2021 at 11:37:05 PM UTC+10 Irene Polikoff wrote: > It sounds like you are wanting to hide Asset Collections, not assets. > > If a user has view privileges for an asset collection, it will appear in the > list of collections, quick navigation/hamburger menu, etc. > >> On Sep 22, 2021, at 11:38 PM, Holger Knublauch <[email protected] >> <applewebdata://AB47D6E1-DA04-45CC-BA8B-D28A53C1DE0D>> wrote: >> >> > >> I am afraid the short answer is no, we don't have such features. Other >> colleagues may have additional input. >> >> There is dash:hidden which you can theoretically use to hide skos:Concepts >> from the Taxonomy tree, but that's about it. >> >> Holger >> >> >> On 2021-09-23 1:13 pm, Simon Opper wrote: >>> Hi TQ crew >>> >>> Is there a way to hide assets from the edg UI which are required imports, >>> but maintain required view permissions so that any top level graph e.g. the >>> top level taxonomy is shown in menus but not (some or all of ) its imports? >>> >>> e.g. give view permissions for users (via roles and governance singleton) >>> to imported graphs such as ontologies and shapes or customisations >>> ontologies, (as far as I'm aware required to allow a user to view the top >>> level asset) but hide these assets from: >>> 1. the the main EDG home screen; >>> 2. the "quick navigation to your collections" >>> 3. the table view of asset collections >>> >>> We are working on governance models for user and role permissions but >>> haven't come across a method to hide assets. >>> >>> Many thanks in advance >>> >>> Simon >>> -- >>> 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] >>> <applewebdata://AB47D6E1-DA04-45CC-BA8B-D28A53C1DE0D>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/topbraid-users/86fe6c0c-eca9-4620-96ca-f78d01761861n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/topbraid-users/86fe6c0c-eca9-4620-96ca-f78d01761861n%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] >> <applewebdata://AB47D6E1-DA04-45CC-BA8B-D28A53C1DE0D>. > >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/652215e6-4fc1-d546-2b52-c92f1ffef803%40topquadrant.com >> >> <https://groups.google.com/d/msgid/topbraid-users/652215e6-4fc1-d546-2b52-c92f1ffef803%40topquadrant.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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/5683efeb-5f8e-4d4e-ae7e-82689ce456b6n%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/5683efeb-5f8e-4d4e-ae7e-82689ce456b6n%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/B0A5EE59-8561-4505-A4C7-DFD2FEBD6A42%40topquadrant.com.
