What should be in your Solid Pod? Anything, of course. Any data in your life, across the data spectrum from public to private and everything shared with communities in between. The activities in your life you currently do on your phone, on on a web app, on or on any device at all. And activities which currently you can't really do online but you will be able to in future. This data will vary hugely in size and shape, and immutability, and it's needs for speed, and it's needs for security, may be very different. But still it must be organized in clear way, extensible way, and a way which allows interoperability between different application. To be extensible across these dimensions, we must give applications the power to configure this data in the users pod in a way which meets these requirements, and also works well for that particular app. We expect different apps to often shared common design patterns for similar types of data. We do this by principally initially keying data by its RDFS Class, not by the particular app which wrote it. But then different apps need to be able to create very specific structures including many different types. We expect the classes of data used by different apps to overlap a lot. We track and use its provenance carefully and carefully control is access, to be able to model the way we really trust data, people and bots in this very rich, varied, and valuable system. Keeping stuff related to the same activity together in a pod, even though it is of many different types, is valuable, because the same access and trust conditions apply and it is much simpler to get those right.
When we think in general about the structures for organizing data in a pod, we need to think about the huge variety of data which there will be. It should be able to include any data in your life, across the data spectrum from public to private and everything shared with communities in between. The activities in your life you currently do on your phone, on on a web app, or on a laptop, on or on any device at all. Gaming systems, pubic kiosks, Automatic Teller Machines. This will include activities which currently you can't really do online but you will be able to in future. Maybe sing in a choir together, say, or share yourself in real-time ultrasound scan form. This data will vary hugely in a number of dimensions we already see to a limited extent
Despite this range of vastly different types of data, it must still be organized in clear way, extensible way, and a way which allows interoperability between different application. In the Solid project, we use Linked Data, ie RDF as links, and we have decided to base the dispatch of functions to handle things based on the RDF Class. But it more complex than just lining up an app for each Class, the the Solid world where a mantra is that you can do anything with anything. Whatever you put on your pod, I can bookmark it or like it on my pod, using my favorite app. People -- developers and in fact users -- will be thinking up new sorts of social action, new form of organization, and so on, all the time.
So classes and apps are related but not 1:1, as we are reminded by the old Semantic Web Metro diagram.
So all those apps should use the same shape for contact information.
We expect the classes of data used by different apps to overlap a lot. So those designing new shapes in their app should be conscious of that.
To be extensible across these dimensions, we must give applications the power to configure this data in the users pod in a way which meets these requirements, and also works well for that particular app.
For example, take an app for running a meeting. A meeting typically involves, say a poll among the group as to when thy can meet, them a time and place; an agenda, groups of people invited and attending, a video call and/or chat during the meeting, the minutes recorded, action items taken by people. It is often part of a series of similar meetings.
An extensible way to do the is to have the functionality of the poll be a generic one usable for other surveys, and to share the UX for dealing with groups with Contacts apps and anything else on the yellow metro line.
Because the Solid Pod has a folder structure (strictly, LDP containers), the meeting can be managed in a main folder for the meeting, and then subfolders can be made within that for the poll, for groups (if they are new groups not just existing groups in the user's contacts), for the video call link, the agenda, the minutes, the action items.
Systems like this typically uses concepts of role, such as say Owner, Administrator, Invitee, Participant, and Observer. look at Github organizations, repos and gitter rooms, for example. The app may just define, or the owner configure, which roles can do what. Who can edit the minutes? Who can read the minutes? Who can add someone to the invitees? In the action item tracker, who can comment on the task? If a little chat is started about the task of fulfilling an action item, then who can read, who can write that chat? Who can deem the item done? It is the job of the app in this model
These things may be recursive, -- starting a new issue tracker around a chat, or starting a new chat around n issue, and so on.
The the app, then, lays out a folder for the meeting series and for each meeting, and the parts of the meeting. It then splits the data into resources where specific roles get specific access to specific resources. The owner can edit the config, and participants can read it. This makes it possible for the app to deliver the role-based functionality by mapping it only acyal Solid Groups and intividuals in the access control systems.
When things are created within things, like to-do list within a chat, then typically roles are handed down .. though a chat about as task within a meeting could be further restricted by only allowing people interested in the task to comment, for example. Maybe a meeting allows the spinning off of 1:1 coffee sessions, say, for thee sake of an example. It is obviously crucial that the user interface make it very clear who is in fact involved and has access. Keeping the systems simple makes things easier. By deviating from how things work in real life, or in existing systems, is a risk.Library | Index by eg | Item |
---|---|---|
Address Book | name, email | Contact Card |
Calendar | time | Event |
Photo Library | time, author, subject, location | Photo |
Media Library | artist, composer, album, genre | Song |
Medical Records Library | date, source, type | Observation, Test, Scan, etc |
Fitness Library | date, sport | Run/Ride, etc |
and so on.
This is important, partly because the top level index scales better when filled with a few large things than filled with a lot of small things. But also it in important because within library type, things are internally more richly than just name and type: Music tracks are indexed typically by artist, album, and genre. While the index lookup in future may all be done by SPARQL (etc) queries on the pod, for now apps have make their own indexes and organize stuff in a logical way for the domain.
The structure of data of different data in different nested folders above is independent of things like the type indexes (My Stuff), bookmarks, and so on, where anyone can bookmark anything. So a user can decide that some activity deep inside in fact deserves to be listed on their public profile. So there can be incoming links into things in the structures.
Data about different things will have a different shape, shapes using typically properties in different ontologies. However those shapes might things in common, which might merit looking out for patters like summary indexes, inboxes, time series days in dated folders, local cache of remote pod data such as the names of remote things, and so on.
We should track and use the provenance of data carefully and carefully control is access, to be able to model the way we really trust data, people and bots in this very rich, varied, and valuable system. A sophisticated way of tracking provenance is to have the data digitally signed by keys of agents deemed to be trusted. A more lightweight way if to know they wrote that data because they are the only ones that have write acccess to a resource.
Using the folder structure of Solid pods to arrange different resources involved in collaborative applications, combined with the folder-oriented features of the access control system, and a mapping of app-level role based permissions to different things within an activity, allows a user's pod to be used for all kinds of different activities that we can imagine now, and hopefully those we cannot currently imagine, though others will, in the future. In summary, we find keeping stuff related to the same activity together in a pod -- even though it is of many different types -- is valuable, because the same access and trust conditions apply and it is much simpler to get those right.