Order of Fuseki endpoints w.r.t Fuseki-UI Sparql endpoint

[Simon Bin <sb...@informatik.uni-leipzig.de>]

Hi,

we have defined some endpoints in Fuseki Assembler like this:

<#service> rdf:type fuseki:Service ;
    fuseki:name "ds" ;
    fuseki:endpoint [ fuseki:name "update" ; fuseki:operation fuseki:update ; ] ;
    fuseki:endpoint [ fuseki:name "update" ; fuseki:operation fuseki:query ; ] ;
    fuseki:endpoint [ fuseki:name "analytics" ; fuseki:operation fuseki:query ;
                      ja:context [ ja:cxtName "arq:queryTimeout" ;  ja:cxtValue "4320000" ] ; ] ;
    fuseki:endpoint [ fuseki:name "query" ; fuseki:operation fuseki:query ; ] ;
    fuseki:endpoint [ fuseki:operation fuseki:query ; ] ;



The issue is that due to the nature of RDF, there is no inherent order
to these endpoints. When navigating to the SPARQL Query tab in the
Fuseki UI, a random endpoint is picked (and a different one at each
restart on top)

We can contribute a solution to this issue if you want, but the
question is which one? Sort by name, add a fuseki:position property,
change fuseki:endpoint to RDF List...?

Cheers,

Re: Order of Fuseki endpoints w.r.t Fuseki-UI Sparql endpoint

[Andy Seaborne <an...@apache.org>]

Hi Simon,

On 30/06/2023 09:51, Simon Bin wrote:
> Hi,
> 
> we have defined some endpoints in Fuseki Assembler like this:
> 
> <#service> rdf:type fuseki:Service ;
>      fuseki:name "ds" ;
>      fuseki:endpoint [ fuseki:name "update" ; fuseki:operation fuseki:update ; ] ;
>      fuseki:endpoint [ fuseki:name "update" ; fuseki:operation fuseki:query ; ] ;
>      fuseki:endpoint [ fuseki:name "analytics" ; fuseki:operation fuseki:query ;
>                        ja:context [ ja:cxtName "arq:queryTimeout" ;  ja:cxtValue "4320000" ] ; ] ;
>      fuseki:endpoint [ fuseki:name "query" ; fuseki:operation fuseki:query ; ] ;
>      fuseki:endpoint [ fuseki:operation fuseki:query ; ] ;
> 
> 
> 
> The issue is that due to the nature of RDF, there is no inherent order
> to these endpoints. When navigating to the SPARQL Query tab in the
> Fuseki UI, a random endpoint is picked (and a different one at each
> restart on top)

Well, you're using blank nodes, which change each reboot :-)
The registry is ConcurrentHashMap

Quick hack: Use URIs - may work. Fragile (see below).

Tweaking the registry isn't an answer ...

> We can contribute a solution to this issue if you want, but the
> question is which one? 

> Sort by name,
Possible - probably solves your stability use case but the user has to 
know which one is which.

(+) this is a JS only solution.
(-) it's an arbitrary choice with no user meaning
(-) Couples the concepts of URI path name and use display name - see below.

> add a fuseki:position property,
(+) Stable as the code changes in the future.
(.) Still an arbitrary order
(-) Java and JS changes.

Also:

:: add a fuseki:label property,

fuseki:name is the URI path string,
fuseki:label would be for users and administrators.

Like fuseki:position except
(+) Meaningful name to the user and administrator (future)

:: Add fuseki:label and fuseki:position

fuseki:position would be optional and the UI sorts.

(+) Both changes are data items to carry end to end and in the same code 
areas so not much more work.



> change fuseki:endpoint to RDF List...?

Very fragile if it works at all.

The registry is ConcurrentHashMap, and so is the DataService set of 
endpoints. There may be other maps/sets used other places as well. The 
path assembler to UI is long and any change on it risks changing an 
implicit choice.

> 
> Cheers,
> 

     Andy