FYI We use hundreds (and expect thousands) of graphs and have developed additional modules to deal with automation and replicability of state. Some of the UI browsing paradigms don't scale, and we provide alternative approaches to discovery based on modular governance domains and inter-graph relationships.
As Holger says, the key is in knowing what and when to include in import closures depending on what you need to do with the graphs. Rob Atkinson SURROUND Australia. On Tuesday, 15 September 2020 at 08:12:10 UTC+10 Holger Knublauch wrote: > Hi Richard, > > one thing that definitely will slow down almost all operations is if you > have large import closures, i.e. a graph that owl:imports many other graphs > (transitively). This is because all queries will need to go against the > various subgraphs individually and the results then merge (we do not > use/have a shared index across all these graphs). > > OTOH only some operations will become slower if you have hundreds or > thousands of individual graphs that are largely independent. For example > the page to browse all Data Graphs will become slower. I am aware of > customers that have hundreds of graphs. If you run into significant > problems in that area then please let us know. > > Holger > > > On 14/09/2020 22:40, richarddi...@gmail.com wrote: > > We mean the "Limit on the amount of data graph collections" (as being the > number of graphs, bad English, sorry) . We might get several hundreds data > graphs. When this will become a problem we could use Shacl for what we > want; 'perfect data governance'. > > On Monday, September 14, 2020 at 2:10:32 PM UTC+2 TopQuadrant wrote: > >> Hi Richard, can you confirm the limit you are referring to? Limit on the >> amount of data graph collections you can have or limit to the search >> results in a data graph? >> >> On Mon, Sep 14, 2020 at 4:39 AM richarddi...@gmail.com < >> richarddi...@gmail.com> wrote: >> >>> >>> Good morning, >>> >>> Do technical of practical reasons exist for limiting the amount of data >>> graphs to e.g. 1000? From a data governance (DQ, corrections etc) >>> perspective I evaluate a graph architecture with more data graphs than one >>> would expect. >>> >>> Richard D >>> >> -- >>> 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/d24f0a64-3d29-4ea0-b6b8-313f3331ff49n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/topbraid-users/d24f0a64-3d29-4ea0-b6b8-313f3331ff49n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Taryn Madey >> Development Manager >> TopQuadrant Inc. >> Raleigh, NC >> >> -- > 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/b96d782a-1c8d-4cac-a642-d263491b344en%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/b96d782a-1c8d-4cac-a642-d263491b344en%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 topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/fbb387e6-5488-421c-917f-e135cb0ca31en%40googlegroups.com.
