Transitive path (e.g. "skos:broader+") toggle

[ch-sander]

Would it maybe be a good idea to add a visual toggle like for OPTIONAL or NOT EXISTS to render a PROPERTY PATH elt+ for the property selected? It's of course possible to do that with a static sparqlstring already but a dynamic solution might be a benefit, especially for a owl:TransitiveProperty reasoning, such as skos:broaderTransitive (being an inference, not an assertion).

[ch-sander]

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX :     <http://example/>
SELECT ?person
{ 
  :x foaf:knows+ ?person
}

https://www.w3.org/TR/sparql11-query/#propertypaths

[tfrancart]

We can keep this issue open as the discussion already popped up several times.
I am not sure simple users would be familiar enough with SPARQL to understand the option.
Right now whenever we have the need (and we have quite it often), we create 2 properties with different labels, e.g. "child of (direct)" vs. "descendant of (transitive)" which is mapped to a property path. From the user perspective, it is the choice between the 2 properties that is actually the choice between using direct or transitive graph traversal.

[ch-sander]

Two different properties hard-coded are the better design decision. However, they have to be created by the designer.

Maybe a ∞ symbol next to the property to set the + and a tooltip Extend this property path to include all related nodes, traversing as many links as necessary. (or similar). When a property path is extended (+ is applied), visually differentiate these paths using color coding or dashed/solid line styles to indicate that the path is non-standard or extended. Maybe the availability of this feature hat to be set in the global config as not every endpoint supports it.

This would be dynamic, user-friendly, non-aggressive, and (maybe) not difficult to implement.

[tfrancart]

Two different properties hard-coded are the better design decision. However, they have to be created by the designer.

This is exactly the point : the work for creating these should be (and currently is) on the designer side, not the user side. Adding an option in the UI is nice, but pushes the work of query design to the user, who would need to understand the structure of the graph, find this option in the UI, understand what it does, and know when he needs to apply it.

We are not aiming at being a 100%-compatible SPARQL editor. We are aiming at providing a user-friendly graph semantic graph explorer.

Let's keep the issue open anyway.