Fuseki UI: support inference options in dataset creation

[Ostrzyciel]

Version

5.1.0

Feature

This is a very loose feature idea, it's not urgent or anything.

It would be useful if when creating a new dataset in the Fuseki UI, the user would be presented with more choices than just "in-memory vs TDB2" – namely what kind of inference should be used on the dataset. This would simply include the options mentioned here: https://jena.apache.org/documentation/fuseki2/fuseki-configuration.html#datasets

The Fuseki UI is very useful especially to people starting out with knowledge graphs – you don't have to mess with config files or anything. For example, I use it to teach SPARQL to students, but to be honest, going through the hoops of setting up inference on a Fuseki server is a bit too much. Me personally, when I learned to use Fuseki for the first time a few years ago had zero idea that you could do inference at all in Jena. I thought that the only options were TDB2 and in-memory, and that's it. I wasn't good at reading docs back then 😆 but I think you get the idea. This feature would allow more people to easily access more of Jena's magic.

I also have a more general feeling that Fuseki UI could use some more functionalities... more people are getting interested in knowledge graphs/semantic web again, and for many of them the UI is the easiest thing to work with.

Of course, this is nothing urgent... maybe I will look into this when I get some spare time. For now I just wanted to drop the idea here.

Are you interested in contributing a solution yourself?

Perhaps?

[kinow]

I have no objections, and would like to see the UI getting some new features like this one.

I think it'd be good if the backend/Jena had a way to tell the UI what options are available (in-memory, tdb, inference -- which engines?), in a way that's self-describing so that if the user chooses in-memory, the UI has a place, somewhere, from where the UI gets the list of parameters that the user must provide.

That way we could provide users similar experience in web-UI as in cli/tui.

[rvesse]

One thing worth mentioning is in my $dayjob we've got one of our devs working on a YAML based configuration mechanism for Fuseki with the aim of making it easier for non-RDF savvy users to get started. This is mainly aimed at our DevOps team who aren't RDF folks and behind the scenes this basically just generates a RDF configuration file for us.

Currently this is mostly hardcoded to TDB/in-mem and for some other Jena extensions we have. However longer term I'm thinking in a similar vein to @kinow that it would be nice to make this pluggable so you can have self-describing extensions register and be handled seamlessly.

The first Alpha quality version of this is hopefully going to be open source soon-ish (sometime this month I hope) so I can add a link here as and when that's available if people think that might be interesting for them?

[Ostrzyciel]

Yeah, good idea about the pluggability... The registration mechanism for reasoners could include some human-readable labels and descriptions which could be used in the UI or any other interface, such as CLI or this YAML config. Sounds good.

[afs]

Dataset creation in Fuseki is template driven. Adding more choices is a matter of adding to the "../webapp/templates" directory of the webapp then including in the UI. Having the UI fetch a file describing the options would be good.

Any option should be required to be reloadable (see in-progress #2464) because then we can have zero-downtime restart when the server configuration changes. Reconfiguration such as altering or adding timeouts through to adding and deleting new datasets on the server side needs a reset. The fun part is that some configurations have internal state so sometimes the dataset implementation needs to be involved; for example, the RDFS Dataset is mostly backward chaining except it builds the class and property hierarchies from the schema once.

Having some options that have low configuration and restart complexity, e.g. a RDFS setup that has no pre-calculated state, would be good.

[Ostrzyciel]

Note for future implementers: it may make sense to generalize this task to assembler options in general: https://jena.apache.org/documentation/assembler/index.html

I remember that Blazegraph had a popup window when creating a dataset where you could modify the store parameters. I think that at least making such an option visible in the Fuseki UI would help a lot with making these functionalities more visible to users.

Another thing that possibly could be investigated is auto-generating a configuration interface based on the assembler schema. The assembler schema could be exposed in the same API as the aforementioned endpoint for YAML configuration. Maybe.