DASH: Inputs for selecting viewers/editors

11 views
Skip to first unread message

Tomasz Pluskiewicz

unread,
Jul 25, 2021, 9:08:39 AMJul 25
to TopBraid Suite Users
Hello

Looking as DASH spec, scoring for viewers and editors is mostly (only?) taking into account the actual property value.

However, I'm considering an implementation (and viewer definition to match) where the scoring would actually depend on the property itself. That also would be a multi editor, which make less sense to score based on the objects.

Specifically, the case is for a `hydra:member` viewer, which would render all collection members (a table maybe), and its score assigned based on the `sh:path` of a specific Property Shape...

Are multi viewers implemented in any such way by Top Braid? 

Best,
Tom

Holger Knublauch

unread,
Jul 25, 2021, 7:15:48 PMJul 25
to topbrai...@googlegroups.com

Hi Tom,

I may misread your scenario, but couldn't you just use dash:viewer and dash:editor to explicitly link from the property shape to the preferred widget?

    http://datashapes.org/forms.html#widgets

In that case, the scoring would be bypassed because a value is already asserted.

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/fbea53b8-513f-4f28-86e8-d2f7318f1f8cn%40googlegroups.com.

Tomasz Pluskiewicz

unread,
Jul 27, 2021, 5:34:29 AMJul 27
to TopBraid Suite Users
The biggest difference will be not to use dash:viewer at all but have a rendering component be selected only based on data.

I assume that a simple shape would only declare a property like [ sh:node hydra:Collection ; sh:property [ sh:path hydra:member ; sh:node ex:OrderItem ], and when rendering this path the scoring could take factor in additional information, such as sh:path the parent shape's sh:node.

Which begs the question. Are your implementations often aware of a broader rendering context? Another such example is actually rendering the above ex:OrderItem, which could be different when rendered inside a collection's graph, as opposed to being the top resource in a graph.

Does this make sense?

Tom

Holger Knublauch

unread,
Jul 27, 2021, 6:15:51 AMJul 27
to topbrai...@googlegroups.com

I see. No, we have not yet implemented such complex requirements for widget selection. You may need to explore your own approach, e.g. through a SPARQL query.

Holger

Reply all
Reply to author
Forward
0 new messages