Demo app - RC flight logger

Build a Solid App Solid App Development FAQs
1

Being an enthusiastic radio controlled aircraft modeller in addition to being a software developer, I decided to try out Solid by creating flight-log app that stores my models, flying locations and flight-log on my personal POD.

Example screen dump(*):

Logbook%20-%20Solid-RC%20%E2%80%93%20Google%20Chrome%2030-11-2018%20235852
Logbook%20-%20Solid-RC%20%E2%80%93%20Google%20Chrome%2030-11-2018%20235852681Ă—548 38.7 KB

You can try the app directly at https://solidrc.azurewebsites.net/. The project is located on GitHub - JornWildt/SolidRC: A journey into building Solid applications - feel free to add isues or fork it and play around with it.

It has been an interesting journey where I have dived into Solid, Linked Data, JavaScript frameworks and Dotnet Core websites on Azure.

My apologies to the Solid team for all the questions I have disturbed them with - and thanks for your patient replies.

(*) And, yes, I did unfortunately crash that beautiful model in the example picture as stated in the comment field.

7 Likes
2

A few comments about the app itself:

  • The data model may very well change, meaning your data gets lost … or rather, the app won’t be able to see the data again while it still exists on your POD.

  • I have tried hard to use existing linked data types for the data.

  • If you want to know why data is located where is it then take a look at this discussion: https://github.com/solid/solid-spec/issues/127

  • Hosting is on a free Azure plan. Don’t expect too much from it.

  • Solid has no concept of paging and sorting data server side, so once the flight-log grows big you will see a degradation of performance as the browser must load all entries, sort them in-memory, grab the X entries on each page - and throw the rest away. See https://github.com/solid/node-solid-server/issues/956

  • There are issues with the local RDFLIB cache of statements. You will often see funny things happening when adding or deleting items. I still don’t know if this is a RDFLIB bug or me misusing it. See https://github.com/linkeddata/rdflib.js/issues/279

3

I have one question for the linked data experts - does the data model represent a “good” linked data model or is there a better way to represent it?

Click on the user-icon to see where Solid-RC store your data.

4

Solid-RC stores the data at root of my POD
IMO It’s too much a high level.
I do not have even the possibility either to :

  • delete it with the actual UI on Solid 4.4
  • or change permissions

To delete it I’m using Solside app.

5

In logbook : image do not display
message : ressource not available https://rootofwebid/-models/mymodel

6

For /places/hobby I think they should be in a folder /rc-app/rc-hobby
because they are really personal and not reusable locations and not really defined as such

For images you have a point. For your actual exemple use I would have used /rc-app/rc-models

Where to locate /rc-app. I don’t know but not at /root. in the actual state of Solid I would put it in /public/apps/

/public do not mean accessible by everyone without control it can even be nobody except owner

7

Thank you for your feedback - I have been through the same considerations you have about the location of data. There’s a rather lengthy discussion of it here: Provide guidelines for application data storage configuration · Issue #127 · solid/solid-spec · GitHub

The reasons for the selected locations are:

  • The data is your data - not any specific app’s. For that reason the app-name is not part of the URL. This is a rather crucial point where Solid is different from your classic operating system.

  • Your data is the focus point - not your apps. The data for Solid-RC is open and uses almost exclusively existing vocabularies.

  • The app, your “user agent”, works on your behalf. It does not own your data. This is very different from Facebook, Twitter and almost every other online application I can think of. It is also different from standard desktop application that has a closed data model you should neither tinker with or let other apps access.

  • In the future somebody else might implement a better user agent for this set of data. Lets call it “Random-RC”. It would be odd if “Random-RC” worked with data explicitly marked as Solid-RC’s data through the URL name.

  • All this means that the app name should be removed from the URL.

Now there is application state data, such like preferences, current sort-order and selected model - and then there is the “business” application data (the models, locations and flights). I believe state data belongs to the app and should be located in something like /apps/solid-rc whereas the application data should be, as argued above, in a more central generic location.

Public folder
Yes, /public can be anything you want - also completely private - which is why i think /public is a bad choice for almost anything in Solid. See Is /public really such a good idea? · Issue #129 · solid/solid-spec · GitHub

I also think /apps is a bad idea since it, again, indicates that the data belongs to the apps and not to you.

Root folder
You are absolutely right - the default data browser does not allow you to browse the root folder. But, as @RubenVerborgh states it “That latter thing is a UI bug we should fix.” (see Provide guidelines for application data storage configuration · Issue #127 · solid/solid-spec · GitHub).

Other folders
I do although share the idea that the root folder might not be such a good idea - maybe /user or /data is a better top folder.

Let the user select
As you have stated, you would rather see the data in /rc-app or maybe /public/rc-app or /user/rc-app which might just be the perfect choice for your POD … it is after all your data, right :slight_smile:

So in the end we should probably just let the user choose the preferred location … although the app should still suggest something useful to get going.

Vocabularies and linked data

For /places/hobby I think they should be in a folder /rc-app/rc-hobby
because they are really personal and not reusable locations and not really defined as such

“Locations” are actually reusable locations - at least on the data level since they are defined as schema.org “Place”.

But it opens up for an interesting discussion - does it make sense to use linked data here? The selected location for a flight is in the end nothing but a URL pointing to something that represents a location - in this case a location you have defined first. But the location could as well refer to DB-pedia or some other “geo” resource.

I can also easily imagine wanting to reference models and locations from friends - “Hey, look, I flew at Mathew’s airfield” or “Cool, Mathew was the pilot of my model and registered a link to it from his logbook”.

Unfortunately I think linked data leaves more questions than answers when you go down this road. At least it is a very different way of thinking as opposed to the current family of web- and desktop-applications. … when is a piece of data kind’a private and not designed for reuse - and when should I, as a designer, craft an open well defined vocabulary that covers the area I currently work with and make it possible for others to link their data with mine?

I also leaves an open question about the whole user experience of using Solid apps, how to let users select from other users data, how to share and how grant access in an easy and intuitive way.

And that is exactly why I created a simple little app like Solid-RC - to trigger these discussions about the whole Solid experience and have something very concrete to illustrate issues and thoughts.

8

Would you mind opening an issue on Issues · JornWildt/SolidRC · GitHub? Let me know if you can open the same URL in the data-browser.Thanks.

9

When I made my remarks I was aware of your discussion and I missed the basic reason why I reacted.

I thought of having a few ten’s of apps and imagined what the filesystem would look like. Is it manageable with your choice and I don’t think so.

All your files are data files and I should have stated /public/..../rc-appdata/

In an other situation you could also have a separate /public/..../rc-app/

May be for sake of clarity /public could be either replaced by 2 or more folders at root level for apps and for data’s.

Just a few thoughts.

10

That’s a good point. If I have N apps, each of which working on M different data types, I would end up with NxM folders in the root. So some sort of tree structure would be better.

i would rather strip the “app” from /public/..../rc-appdata/ and make it .../rc-data/ (disregarding the discussion of the root folder name) since “rc-data” is a suitable abstraction of the kind of data the app is working with while still not including the app-name itself.

Now, what if the RC-app happens to depend on your contacts to send out “Watch this!” notifications to your friends? Should you also store your RC-contacts in your .../rc-data folder or use a (yet to be defined) common place for your contacts? I would assume a common contacts folder.

But who defines when a type is common enough to be a well-known thing alongside contacts? Maybe, in my world of over-enthusiastic RC model JavaScript devs, an aircraft model is worthy of being such a common “high level” commodity that everybody would find it absolutely natural to place it in /rc-models …

Seems like this whole discussion ends up trying to agree on a hierarchical categorization of the world … which is probably a less productive discussion. Which indicates that a common guideline for Solid apps should be to let users decide where to store their data instead of imposing a random unfit-for-all choice (like Solid-RC does right now).

11

I seem to remember someone writing that you could create a typeIndex in /public/settings

like for example https://github.com/melvincarvalho/solid-bookmark/wiki

There you could set the files/folders used specifically by your app using solid:instance and solid:instanceContainer
That way everybody can change to it’s likely the data location and your app will know where is needed datas are.

12

Your turtle files do not have a .ttl extension.
I seem to remember that best practice is to use extentions.

13

That’s right and that would probably be the right place to register your preferences. It doesn’t help the first time though, when no setting has been set yet - in that case the app needs to propose a reasonable “best practice” default.

14

Yep. Will fix that.

15

Yes
you the app should create your reasonable best practice and I can change them immediately after creation
or later.

16

The app now looks for it’s location in the type registry. Like this:

@prefix solid: <http://www.w3.org/ns/solid/terms#>.
@prefix solidrc: <http://solid-rc.net/ns/solidrc#>.
<>
    a solid:TypeIndex ;
    a solid:ListedDocument.

<#reg1>
    solid:forClass solidrc:data;
    solid:instanceContainer </rc-data/>.

Online on https://solidrc.azurewebsites.net

17

I did not find location of your type registry
Why not use /user/rc-data/ in lieu of /rc-data/ ?
Have you tried the concept of having a schema defining a kind of app filesystem as local ontology ? Just an idea

18

Ah, sorry, I thought you were aware of it since your refered to Home · melvincarvalho/solid-bookmark Wiki · GitHub that describes it. It’s your personal type registry which is located at <your-pod>/settings/privateTypeIndex.ttl (and you cannot see mine as it is, well, private). There is a public version too at /settings/publicTypeIndex.ttl - see https://github.com/solid/solid/blob/master/proposals/data-discovery.md.

Why not use /user/rc-data/ in lieu of /rc-data/ ?

That is just a personal preference - the app will actually suggest /user/rc-data/ as a default.

Have you tried the concept of having a schema defining a kind of app filesystem as local ontology?

No. Actually I’m not fluent enough in RDF to understand what you are asking - sorry :roll_eyes: But I am trying to conform to the mentioned spec.

Haing said all that doesn’t mean I think it is a good idea to edit the registry yourself - quite the opposite - we don’t ask WIndows users to “regedit” their settings either, right?

So the current development version makes it possible to edit the location right in the UI, so there won’t be any need to do any manual registry tinkering. I just need to weed out a few bugs before uploading it.

19

I understand your point and to generalize we could have the type registry point’s to …/rc-app.ttl.
The file will include all parameters that describes the app filesystem and any other parameters that are user dependant. You are fully free as user with your organisation and the app as all what is needed in each Pod
They could be managed by the app or directly by any editor.
The pb then is that you can lose or not the data you already have.
The data are yours and you should be able to do what you want

20

Got it :+1: