On May 19, 2020, at 10:38 PM, Rob Atkinson <robatki...@gmail.com> wrote:Use Case:I have a large data graph I wish to navigate and allow users to annotate so I expose in an EDG editor.
Its not really "reference data" - but its generated by scripting so the body should only be changed by external processes - and the idea of annotation is to provide feedback on the content, manage additional information we need to attach etc.If I include the data, the class tree works but it shows no instance - obviously only working on the current graph, not with imports.
How can we control the query scope to allow a-box import heirarchies to be handled - effectively i want to distinguish between a-box and t-box imports I think.
No problem adding a property to the graph the widget could look at to use in an import closure.Obviously GraphQL in general needs to be able to access the a-box graph closure.I can workaround with data load in the short term - but it means I'd have to handle annotations in working copies and never commit them - or perhaps have an export for the working copies I can save before committing them.
--
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/b2f26203-7dd7-4f86-a803-ae8f9aa31c5e%40googlegroups.com.
Please see belowOn May 19, 2020, at 10:38 PM, Rob Atkinson <robatki...@gmail.com> wrote:Use Case:I have a large data graph I wish to navigate and allow users to annotate so I expose in an EDG editor.What asset collection type are you using for this? Data graph?
Its not really "reference data" - but its generated by scripting so the body should only be changed by external processes - and the idea of annotation is to provide feedback on the content, manage additional information we need to attach etc.If I include the data, the class tree works but it shows no instance - obviously only working on the current graph, not with imports.Include where?
If you are not working with classes and properties, why are you using the class tree?
Why are you expecting a class tree to show instances?
It only displays classes You could bring in Instances panel, it would then show instances for a selected class, but it is not the most convenient view for working with instances.
Typically, the Search table panel works better and you can use Asset Navigator to select a class of instances you want to focus on.
A screenshot would help.How can we control the query scope to allow a-box import heirarchies to be handled - effectively i want to distinguish between a-box and t-box imports I think.I am having hard time understanding what you are talking about. Editors work over the entire graph closure. All information is shown - whether it is in the currently opened asset collection or in any of the imported graphs.
No problem adding a property to the graph the widget could look at to use in an import closure.Obviously GraphQL in general needs to be able to access the a-box graph closure.I can workaround with data load in the short term - but it means I'd have to handle annotations in working copies and never commit them - or perhaps have an export for the working copies I can save before committing them.What do you mean by “annotations”? You don’t have to commit a working copy. All exports work for a working copy exactly the same as production copy.
--
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.
On 20 May 2020, at 06:20, Rob Atkinson <robatki...@gmail.com> wrote:
the classes and instances layout is a reasonable way to navigate the instances by selecting classes of interest
It only displays classes You could bring in Instances panel, it would then show instances for a selected class, but it is not the most convenient view for working with instances.
it is the default that shows up
Does the search perhaps rely on generating shapes for every class and property?
I am having hard time understanding what you are talking about. Editors work over the entire graph closure. All information is shown - whether it is in the currently opened asset collection or in any of the imported graphs.nope - it may be the design but if so its a bug -if i copy the same data into the graph it shows, if i owl:import the data it doesnt show.
there are good reasons not to munge everything into a single graph.
--
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/46E4D21C-F3B4-44AB-96C6-EF161E0C5237%40topquadrant.com.
On 20 May 2020, at 09:25, Rob Atkinson <robatki...@gmail.com> wrote:OK search is _nearly_ working using the shapes once I save them and force them to be imported.I had to set the graphql:publicClass and force-refresh the editor to pick up changes.If I put in no search term it finds everything - but anything in the free text box gets zero results. Is there some other step required to make individual fields searchable ( this is the field! in the graphql schema ?)
Also i can find any indicator showing if search is local. At any rate I will want to set a flag to force it to allow search on imported graphs - is there such a property that sets that as default? and/or one that forces it (disables option)
On May 20, 2020, at 4:50 AM, Richard Cyganiak <ric...@topquadrant.com> wrote:On 20 May 2020, at 09:25, Rob Atkinson <robatki...@gmail.com> wrote:OK search is _nearly_ working using the shapes once I save them and force them to be imported.I had to set the graphql:publicClass and force-refresh the editor to pick up changes.If I put in no search term it finds everything - but anything in the free text box gets zero results. Is there some other step required to make individual fields searchable ( this is the field! in the graphql schema ?)I'm not sure. I know that rdfs:label is indexed, and I believe (but not sure) that *all* literals are indexed.
Sometimes, Server Administration > Text Indices > Rebuild can resolve problems with the search. In theory that shouldn't be necessary.
Also i can find any indicator showing if search is local. At any rate I will want to set a flag to force it to allow search on imported graphs - is there such a property that sets that as default? and/or one that forces it (disables option)Like in the Instances panel, results from included graphs are shown by default, but that can be turned off via “Return local results only” in the search panel's “gear” menu (here for a Glossary but should be the same for Data Graphs):
<local-results-only.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/6B57C884-5773-4897-A85C-A74CDDA2E19A%40topquadrant.com.
To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.
> On 21 May 2020, at 07:00, Rob Atkinson <robatki...@gmail.com> wrote:
>
> tested this on a colleagues machine using the exact same version and build of TBC, and the search works fine out of the box. I created a fresh repo and reran the same configuration script and it still fails.
Sounds like the search problem is related to the configuration script then?
> The UI is different too - i have a gear icon and a broken CSS and he has a series of icons in the tab. (both using chrome).
In the page header there is a button with three vertical dots. It opens a menu that has a checkbox for “Display Edit Actions as Icons”. Sounds like your colleague has that checked and you have it unchecked.
I've looked through the EDG stylesheets for 6.3.2 and didn't find anything that looked like the style rule you reported. That means it could be a rule generated dynamically by some JS code. I'll ask colleagues about that possibility.
It could be a local customisation in your workspace. Does your workspace include any .ui.ttlx files that do anything with ui:Script, ui:Style or ui:override, ui:headIncudes? Sorry for making such allegations. It's difficult to investigate these things.
Richard
On 26 May 2020, at 04:43, Rob Atkinson <robatki...@gmail.com> wrote:OK - solved the style issue - I wasnt looking wide enough and a colleagues code had polluted the styles in a mod to the main menu - so at leas the checkboxes are back and I've learned how to force scope for CSS - another layer of contract UI mods have to adhere to.
So I still need to work out why in some cases we can search included content, and other we cant.
On the same machine, same initialisation script, same version of EDG we have workspaces where it works and where it doesnt - an we cant work out what we did to the working cases or repeat it - they were ones where experimentation with Lucene was happening though.
We have checked and they definitely include (not hold copies of) the data, and if we import the data instead of including then all searches work as expected - so perhaps there is something influencing Lucene's indexing of content in the included graph for local search. It seems reasonable we might need to trigger something on data setup, but cant see what it is.
Our Lucene index will not be informed if imported graphs change - it will only incrementally update after changes to editable teamwork graphs from asset collections. Did you try out manual rebuilds of the Lucene-text index at the server admin page?
Holger
On Tuesday, 26 May 2020 15:32:09 UTC+10, Richard Cyganiak wrote:
On 26 May 2020, at 04:43, Rob Atkinson <robatki...@gmail.com> wrote:
OK - solved the style issue - I wasnt looking wide enough and a colleagues code had polluted the styles in a mod to the main menu - so at leas the checkboxes are back and I've learned how to force scope for CSS - another layer of contract UI mods have to adhere to.
Ok, thanks for letting us know.
Richard
--
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/8d94380c-2ef9-4e91-9798-95542fd07a96%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6df3c821-6f87-c054-89e6-ec5823e1f252%40topquadrant.com.
See
\server.topbraidlive.org\system-applications\tbladmin\tbladmin.ui.ttlx:
tbladmin:TextIndicesPage:
<textindex:rebuild arg:id="teamwork"/>
There is no way to only rebuild individual graphs.
Holger
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CACfF9LwZdL-Di41_msnQPsP8QRvW1%3DoZcF%3DdYKi5NgO999x1sQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/da4355e6-e837-a6b6-88f5-faf13303a72d%40topquadrant.com.
Thanks Holger
so does that mean that if you make a single edit to content of a graph it triggers a re-index of the whole deployment? Or you need to manually intervene regularly to update indices?
If not, is there a roundabout way to trigger a single graph by inserting some content temporarily?
No, if you did that then it would only apply the delta of what you have inserted.
Holger
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CACfF9Lwb%3D%3D7rKPzCrn70enx1jqfv%2Be5vCA4y1vPdDFjLqGWhHw%40mail.gmail.com.