Question: Is it possible to add new dash Viewers and Editors to EDG?

46 views
Skip to first unread message

Tim Smith

unread,
Jun 17, 2022, 1:22:20 PM6/17/22
to TopBraid Suite Users

Hi,

 

I would like to add additional viewers and editors like those found in the dash namespace.  Is it possible to add to EDG in this way?  Can I add capability to an existing viewer?  In particular, I would like a more robust Value Table Viewer that supports colors, fonts, and editing for certain use cases.    If so, is there a guide available?

Thanks,

 

Tim

Holger Knublauch

unread,
Jun 19, 2022, 7:59:39 PM6/19/22
to topbrai...@googlegroups.com

Hi Tim,

*declaring* a viewer (or editor) so that it shows up in the dash:viewer selection is, of course, easy and done through RDF triples. However, the implementations of almost all viewers is in JavaScript/React. The process for those is described in the PDF linked from

    https://www.topquadrant.com/doc/7.2/ext/points.html#adding-a-new-panel-to-the-editor-applications

One way of declaring simple viewer widgets without any programming is to infer rdf:HTML literals using a sh:values rule. So in theory, depending on your requirements, you could declare a new property with a sh:values rule that uses ADS, e.g.

graph.html(`
    <table>
        <tr>
            <td>${focusNode.value(rdfs.label)}</td>
        </tr>
    </table>
`)

This mechanism would however require a new property with a different sh:path, and also it can only produce normal HTML, and not the more powerful React-based tables that we use as foundation of our own viewers.

But maybe there is a middle ground here: using the built-in dash:ValueTableViewer as in

    https://datashapes.org/forms.html#ValueTableViewer

and then use sh:values inferences to produce rdf:HTML? This could control colors and fonts, but supporting editing is a completely different beast altogether, because it would blur the lines of view and edit modes (and the complexity of permissions).

Using TQ Professional Services or Premium Support is another option. We could look at your requirements together and come up with a plan to either do custom development or generalize what we have to also support your use cases.

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/dbeccbc0-25d3-4952-93b2-cec0a5170557n%40googlegroups.com.

Tim Smith

unread,
Jun 20, 2022, 12:18:10 AM6/20/22
to topbrai...@googlegroups.com
Hi Holger,

I will do some testing.  I have tried rendering a string of type rdf:html in the value table viewer and it appeared as the HTML source code (complete with tags) in the cell.  If it appeared as the HTML definition, that would give me complete control for the initial use case.

For the full use case, I will need professional services to enhance the functionality of the existing value table viewer. 

Over many years of experience,  I have found that a spreadsheet-like way to create instance data in a complex graph significantly lowers the barrier of entry to a knowledge graph solution. 

Thank you for your solutions, 

Tim

Holger Knublauch

unread,
Jun 20, 2022, 12:30:47 AM6/20/22
to topbrai...@googlegroups.com

On 2022-06-20 2:17 pm, Tim Smith wrote:

Hi Holger,

I will do some testing.  I have tried rendering a string of type rdf:html in the value table viewer and it appeared as the HTML source code (complete with tags) in the cell.  If it appeared as the HTML definition, that would give me complete control for the initial use case.
Right, I looked at the source code and believe the tables should render rdf:HTML inline, so I have recorded a ticket to  get this changed (after confirming there is no problem with that).


For the full use case, I will need professional services to enhance the functionality of the existing value table viewer. 

Over many years of experience,  I have found that a spreadsheet-like way to create instance data in a complex graph significantly lowers the barrier of entry to a knowledge graph solution.

In older iterations, the Search Panel had editable cells, and that made inline editing quite easy. Would that help or would edits need to be on the Form itself?

Holger


Tim Smith

unread,
Jun 20, 2022, 12:51:51 AM6/20/22
to topbrai...@googlegroups.com


On Mon, Jun 20, 2022, 12:30 AM Holger Knublauch <hol...@topquadrant.com> wrote:

On 2022-06-20 2:17 pm, Tim Smith wrote:

Hi Holger,

I will do some testing.  I have tried rendering a string of type rdf:html in the value table viewer and it appeared as the HTML source code (complete with tags) in the cell.  If it appeared as the HTML definition, that would give me complete control for the initial use case.
Right, I looked at the source code and believe the tables should render rdf:HTML inline, so I have recorded a ticket to  get this changed (after confirming there is no problem with that).

I will also double check what I found last week.  I used SPARQL to force a change from rdf:HTML to xsd:string so the text would not display with tags.  This worked.  I am trying to somewhat visually duplicate an existing Excel layout to prove to my Stakeholders that my knowledge graph actually has the same information.  (the true base use case is being able to first define the shape of the graph and second being able to render the shape in a way that they expect to see , thus my need to control formatting for viewing)

If value table viewer will render HTML, then I can achieve my first use case, and hopefully gain acceptance.  I'm happy to share more details off-list.



For the full use case, I will need professional services to enhance the functionality of the existing value table viewer. 

Over many years of experience,  I have found that a spreadsheet-like way to create instance data in a complex graph significantly lowers the barrier of entry to a knowledge graph solution.

In older iterations, the Search Panel had editable cells, and that made inline editing quite easy. Would that help or would edits need to be on the Form itself?

I need to review the previous functionality to know if that would work.

What I was envisioning now was writing a constructor using ADS, and expressing that constructor as a row in a Value Table Editor.  It may not be a generilizable solution but it would work for graph shapes that needed to create a lot of intermediate instances to fully populate the shape.

Thanks for the input!

Tim


Holger Knublauch

unread,
Jun 20, 2022, 2:53:32 AM6/20/22
to topbrai...@googlegroups.com


On 2022-06-20 2:51 pm, Tim Smith wrote:


On Mon, Jun 20, 2022, 12:30 AM Holger Knublauch <hol...@topquadrant.com> wrote:

On 2022-06-20 2:17 pm, Tim Smith wrote:

Hi Holger,

I will do some testing.  I have tried rendering a string of type rdf:html in the value table viewer and it appeared as the HTML source code (complete with tags) in the cell.  If it appeared as the HTML definition, that would give me complete control for the initial use case.
Right, I looked at the source code and believe the tables should render rdf:HTML inline, so I have recorded a ticket to  get this changed (after confirming there is no problem with that).

I will also double check what I found last week.  I used SPARQL to force a change from rdf:HTML to xsd:string so the text would not display with tags.  This worked.  I am trying to somewhat visually duplicate an existing Excel layout to prove to my Stakeholders that my knowledge graph actually has the same information.  (the true base use case is being able to first define the shape of the graph and second being able to render the shape in a way that they expect to see , thus my need to control formatting for viewing)

If value table viewer will render HTML, then I can achieve my first use case, and hopefully gain acceptance.  I'm happy to share more details off-list.

Coming up

I'll see if I can still get this into 7.3 for you.

Holger


Tim Smith

unread,
Jun 26, 2022, 10:24:35 PM6/26/22
to topbrai...@googlegroups.com
Thanks Holger!  (I've been on vacation, thus the slow response).


Reply all
Reply to author
Forward
0 new messages