Sorry Walter, I inadvertently stepped on your great introduction, just trying to link to a thread outside of the introductions thread.
Just my $0.02:
A shopping list app might be the simplest (famous last words ) but also could be really useful, if its easier than just texting. There is a suggestion for one here Shopping list app
But when I think about what I might really use, and I donāt already know how to do more easily in other ways, a friends/family mapping app would be pretty great, to be able to see where people are or have been in a way that respects privacy. I think there is one in the sample apps or in the github repositories, but if you could show how to make one that would be really cool.
Yes great ideas, we could definitively do this.
It could be good then to write the use cases so that it can lead the developments.
Also : I am wondering if it makes sense to build hybride applications (ie : application with personnal data in SOLID Pod and other data in database. That would be possible with GO. Or is it better to have data in SOLID ??
For instance, with the friends and familly mapping app, there is the concept of āplacesā. Where do we store all the places ? so that we donāt just use text but actual places database. Then when we navigate the places, we can see who of our friends and family went to a specific place.
What we could do as an application with GO would be :
database of places in classical database
information about places visited by friend or family inside the person SOLID POD (with ref to place ID + maybe name of place for having directly readable data from POD)
the information about place visited could include date, comments, pictures etc. and I could add comments to my friend visits.
Alternatively, and better ! instead of storing places directory in classical database, could be exposed through a RDF document.
Is there such a RDF vocabulary that already exists for locations ? and existing RDF document ? and if existing RDF document : is it read only or read/write ?
Any existing RDF vocabulary to use for āplaces where I have beenā information ?
Also : if no existing RDF document for location, we could then initiate one.
For the design, I would want to confirm what would be a good SOLID app design, as this is my first one ! What do you think of this :
the users who want to use the friends/family mapping app, will connect to the app and give authorization to the app to access their private POD.
from the app, a user A can tell what places he/she visited. By doing so, the app accesses the user pop to store in the pod of user A, the visited places.
whenever some other user B connects to the app, the following happens : user B can say which places he/she visited. User B can also see all his friends who are using the friend/family mapping app. And if User B is friend of user A, user B can see all the places user A visited, and potentially comment on it, comments made buy user B are store in user Bās POD.
It is the App, through the authorization given by the users, who is going to fetch places visited by user A from user Aās POD, to show them to user B. user B never has direct access to user Aās POD
Does it feel like the proper design ?
Other question : should we model the notion of āfriendā in the friends/familly mapping app ? or use the friends list stored in the POD ? in other terms : does the fact that user A is friend of user B, specific to an application ? (thus if I am connecting for the first time to the friend/family mapping app, then I will be proposed to invite my PODās friends to the App and make them become friends of mine in the context of this application (if they say yes of course!) ?). This seems to me the proper to do.
All data specific to the application itself, not personnal to a user, are store in the application database.
@walter.almeida Solid friends are global to the users Pod, but you can create a āFamilyā group. Iāve never done but seems to be the way I would do such thing.
You could also use a pod for hosting your HTML/Js app, and store appās data on it and not in external database ( a pod is limited with a quota of 25Mo on solid.community)
My principle is 'the one that generate the data is the owner and choose where to store it ā so by default, data generated by a user is stored on his Pod, where he can choose to who ( other webid, appā¦) he share it. An app can have a pod too where it store its data.
Iām not sure how others have done it, you might want to check with others who have written similar Solid apps, for example I think @SharonStrats and @labra.
Also, if thereās a conflict between making a great app and proving the usefulness of Generative Objects for Solid, you should probably go with the latter, but thats just my opinion.
so fwiw anyway hereās my thinkingā¦
The app saves location info and time every so often in the userās (Iāll call it the travellerās) pod automatically, and during those times when the location is changing fast then maybe that data is saved more often. The user can choose to pause or stop the location tracking anytime. The user can also cause that data to be saved on command for important points of interest. Saving it at a point of interest might leave the pause/continue toggle the same or not, depending on user configuration. The user can link any point on their route to any resource on their pod (i.e. pictures, etc).
I agree that all that data should be stored in the travellerās own pod. Others authorized by the traveller can only read it. I also agree that anyone elseās artifacts about a point of interest (pictures, video, audio, text) should be stored on their pod and they and the traveller (or others) would have to agree for those things to be visible.
I also agree that separate lists of friends/family/others would be needed, separate from the friends list in the pod, because the list for this app would change a lot and may sometimes include some who are only temporary friends who want to coordinate routes. Inviting the travellerās pod friends may be too many invitations or sometimes not appropriate. A configurable list of lists may be necessary, say one for work friends meeting for lunch, one for family members on a shopping trip, another for coordinating a sales meeting with customers.
Hope this helps. Iām looking forward to seeing the app!
Oh Ok I understand more now what you were thinking of ! I had the idea of a simple āpoint of interestā application, where the traveller could share places he went to. I did not think of the tracking app. Thatās a cool great idea. I will start with the simple āpoints of interestā app, as a demontration. It can further evolve later.
Ok letās get the ball rolling ! I plan on being in a position to present the results of this experimentation in the SOLID world may
) but also could be really useful, if its easier than just texting. There is a suggestion for one here Shopping list app
