Library for managing App configuration stored in Pod?

Build a Solid App Solid App Development FAQs
1

I’m developing a Solid App. This is not my first App (though all previous ones are experimental), but is the first time I would like to save App configurations into my Pod.

Yeah, it’s just an application configuration: the user may want to change some behaviours of the App (e.g. its appearance, where is looks for data), and it’s best to have these persisted into user’s Pod, so they don’t have to repeat it every time they open this App, nor will the App need its server to store this information.

Surely I can just write to an arbitrary location and use it all the time. But this seems a bit hacky, and will be messy when all Apps do so. I would hope there is a standard / de facto location or library for this purpose. Something like the XDG_CONFIG_HOME for Linux or the Registry on Window would suffice.

But I did not find a library for this purpose. It could also be a function in some libraries that I missed, but I just did not see it.
Does anyone have any suggestions?

I’m aware there is the profile and prefs documents, and prefs is expected to be the “private profile”. It sounds very much related, but I did not find a confirmation.

2

I think the thing missing here is mostly someone with the time & energy to build such, and picking out which schema to use (i.e., what’s generic enough but useful for all applications)

1 Like
3

Hi Em. This sounds fair enough for a library aiming to be general enough (for storing configuration).

But there can still be some less complicated ones. For most apps, key-value pairs would suffice. Therefore, for example, the App developer provides a configuration (key-value pairs), and the library simply stores this under the App’s “name(space)” at a specific location, e.g.:

@prefix c: <https://url-to/configuration/ontology#>

</profile/card#me> c:hasAppConfiguration </profile/card#app-identifier>.

</profile/card#app-identifier> a c:Configuration;
    c:configItem [c:key KEY1, c:value VALUE1];
    c:configItem [c:key KEY2, c:value VALUE2].

Surely this is not flexible enough, but would work and should be acceptable for many apps.

A better way is to let the App provide its own configuration ontology, and use that to set the predicate and object for each configuration item. Work on developing a general-enough ontology can be then started, but doesn’t have to be on the library’s developer. The library can support both ways without knowing the exact details of the configuration schema.

For a more complicated situation, where nested information is needed, this could be tricky, and needs better solution (e.g. the App provides a RDF directly as its configuration, and SPARQL as the way to retrieve configuration). But the library can also provide the resolution of the location (IRI) of the configuration.

4

I’m aware there is the profile and prefs documents, and prefs is expected to be the “private profile”. It sounds very much related, but I did not find a confirmation.

Indeed are discussions around having a preferencesFile as a well defined specification document (though admittedly I haven’t been following those discussions to closely) which you can get an overview of using this search. Based on this roadmap a preferences editor based on this seems to be underway. Someone like @jeffz or @Timea might have better insight on this; and https://gitter.im/solid/solidos might be a good place to ask about the current state of this work; and whether there is an agreed-upon preferences ontology to use in Solid.

Surely this is not flexible enough, but would work and should be acceptable for many apps.

I would err away from the key/value approach as this is going to quickly become an interoperability nightmare and instead go straight for the create-your-own ontology approach by extending existing preferences vocabularies (which you can find in search engines like Linked Open Vocabularies, Ontology Lookup Service (OLS)) to meet your application specific needs. Which means that your preferences data file would look more like:

@prefix c: <https://url-to/configuration/ontology#> .
@prefix pref: <http://example.org/preferences#> .
@prefix ex: <http://example.org/#> .

</profile/card#me> c:hasAppConfiguration </profile/card#app-identifier>.

</profile/card#app-identifier> a c:Configuration;
    # Key1        Value1
    pref:theme ex:nightmode ;
    # Key2         Value2
    pref:difficulty ex:hard .

In particular this makes it easier to do things like automated alignment between your custom vocabulary, and a more general vocabulary via reasoning.

1 Like
5

Hi Jesse. Thanks for the information. It’s good to know something related is on the roadmap.

I totally agree with you that simply a key-value pair will cause interoperability problems. The example you gave is exactly what I consider as the second way. I personally prefer that, or the 3rd way, as well.

But still, the major problem (or any other people maybe fluent with RDF and ontology but not Solid internals) is to find the right/best location to write the configuration, in one function call. That is regardless of the exact representation of the configuration. Hope this can be addressed soon if the preferences editor is the thing.

Speaking of the representation, I believe the learning curve should also be a consideration. I came from a background of working with ontologies, so developing/extending an ontology is fine for me. But most people don’t, and it’s quite a strong burden based on my experience (when discussing with others).

A simplified way (for the developer) is to make the ontology and conversion transparent by the (configuration) library. When the developer sends key-value pairs to the library, it automatically creates the ontology, and convert the string-like key-value pairs to properties and individuals (or data) in the ontology. The ontology is stored inside the pod, in a specific location.
Of course, this will create a lot of work to the library developer…

1 Like
6

There’s going to be a discussion on preferences in webid-profile’s meeting on Tuesday (5pm CET), you might be interested in joining. Check GitHub - solid/webid-profile: Discovery based on Solid Social Agent WebID for more info :slight_smile:

1 Like