Use-case : specify query builder configuration using shapes

[tfrancart]

I am specifying which classes and properties from a model should be presented in a query builder, using shapes.

• I need to be able to associate a xxxx:searchWidget to property shapes to indicate which value selection widget should be used to assert a criteria on this property
• I need to be able to specify SearchWidgets
• I need to associate an icon to each class, (could also be to properties)
• I need to associate a tooltip to classes and properties (sh:description can be used for this, although I may need some more user-oriented message)
• nice-to-have / advanced : if I could assign property roles on properties to indicate which are used for hierarchy building (skos:broader/ narrower, dt:has_part/is_part_of, etc.) and also to indicate roots (skos:hasTopConcept), this could automatize tree selector widgets

[HolgerKnublauch]

These all make sense, but may deserve individual tickets for modularity.

[danielbeeke]

@tfrancart could you give an example of what such a shape would look? And could you maybe give an example of what he user interface looks like? And what is the output of using this? Is it outputting triples?

[tfrancart]

These all make sense, but may deserve individual tickets for modularity.

I like to keep the "story" as one, in order not to lose the full picture, but I am OK to split them in separate issues if the need arises.

@tfrancart could you give an example of what such a shape would look? And could you maybe give an example of what he user interface looks like? And what is the output of using this? Is it outputting triples?

Yes, the formal specification for this, of course done in SHACL, is documented at http://docs.sparnatural.eu/SHACL-based-configuration.html, the tool is at https://sparnatural.eu/, and it is not outputting triples, but SPARQL queries.

[bergos]

@tfrancart could you give an example of what such a shape would look? And could you maybe give an example of what he user interface looks like? And what is the output of using this? Is it outputting triples?

Yes, the formal specification for this, of course done in SHACL, is documented at http://docs.sparnatural.eu/SHACL-based-configuration.html, the tool is at https://sparnatural.eu/, and it is not outputting triples, but SPARQL queries.

@tfrancart Did you consider using a shape with SHACL Advanced Features as an intermediate format? Some use cases, like simple min/max ranges, could be covered with plain SHACL. That would remove the requirement for a full SPARQL engine for such simple use cases.

[tfrancart]

@tfrancart Did you consider using a shape with SHACL Advanced Features as an intermediate format? Some use cases, like simple min/max ranges, could be covered with plain SHACL. That would remove the requirement for a full SPARQL engine for such simple use cases.

I don't understand your comment; the tool is a SPARQL query builder to navigate a knowledge graph. Its output is SPARQL, that is its very purpose.
SHACL is used to configure its UI, but the tool itself does not output SHACL.
Maybe I misunderstood your comment.

[bergos]

SHACL-AF extends SHACL to express a SPARQL query in SHACL triples. SPARQL grammar elements like FILTER, MIN, or LIMIT can be expressed in a triple data structure. I see four main benefits of using the SHACL triples over a plain string:

• It's easier to manipulate further the query generated by the component.
• It's easier to populate the widget from a shape representing a SPARQL query than parsing a SPARQL string. It could be useful to persist a search form and load it later.
• There is no other well-documented standard for a SPARQL query data structure.
• It would be possible to use the shape directly for filtering. For example, a table component could use the generated shape to filter rows client-side.

[tpluscode]

SHACL-AF extends SHACL to express a SPARQL query in SHACL triples

I think it's only half true. The relation to SPARQL is not mandated and you may implement SHACL-AF without SPARQL and even entirely on in-memory data, as could be the case of ordering a resultset (re #15 (comment))

[tfrancart]

I see four main benefits of using the SHACL triples over a plain string:
It's easier to manipulate further the query generated by the component.

This is a pure software engineering consideration. We have our own query data structure for this. That data structure is UI-targeted (it is tied to how the UI behaves)

It's easier to populate the widget from a shape representing a SPARQL query than parsing a SPARQL string. It could be useful to persist a search form and load it later.

We do persist queries and populate the widget from the above-mentionned, UI-targeted, data-structure.

There is no other well-documented standard for a SPARQL query data structure.

From a software engineering perspective, SPARQL.js is largely sufficient. This is what we are using to serialize SPARQL strings. This is as close as you can get from a "well-documented standard for a SPARQL query data structure".

It would be possible to use the shape directly for filtering. For example, a table component could use the generated shape to filter rows client-side.

Indeed.

I don't see much benefits in using this SHACL-oriented-SPARQL-representation in our case. We certainly don't want to use it as an internal data structure. One long-term benefit, mentionned in your 4th point, could be interoperability with other compatible component, but for the moment this seems very far away. If we do anything in this direction we would probably produce the SHACL-AF from our own query representation.

[bergos]

@tfrancart can you please split this issue into smaller issues?