This project is an offshoot of mashlib. Mashlib is a data mashup of linked data. The repositories used in Mashlib have been around for a while and have had multiple contributers. They are in need of some TLC and would benefit from applying the current best practices for software development.
There are two goals for this project.
The first is to evaluate and modify the code for current best practices.
- Strive for 100% test coverage
- Convert to typescript
- Refactor the code to be more readable
- Move inline styles to JSX
- Build examples so that others can use the libraries in other projects.
The second goal is to build an operating system that is easy for a user without a technical background to use. To make it more user-friendly for the average user so that more people can benefit from the Solid principles of true data ownership, avoidance of vendor lock in to services, and data reuse between applications.
Everyone is welcome to take part. Below are the repositories that are involved in this cleanup.
Overlying Goals to keep in mind
- The data browser should be a complete web-based operating system for any new computer or data store.
- When running as a native app, on laptop or desktop or mobile, it should allow the user to use their own local file system in very much the same way as a solid pod. (This currently works with Electron and rdflib). Users should be able to work Local first.
- The User Interface should accommodate a wide range of devices, screen sizes, bandwidth. The project was originally targeted at laptop, and reactive design is important in new work.
- The data browser, unlike a typical set of native applications, is very interconnected. You can do anything with anything - so data from different applications interlinks in a more powerful way so as to solve real life problems powerfully and naturally. You can start a chat about anything, with anyone. You can adopt anything as the target of a task you want to track later. You can like, flag, keyword, bookmark anything. So one application will use others in a recursive way to get its job done.
- You should be able to set the data browser up for any existing folders you have full of things like photos and music, and it should let you listen to them, look at them, and share them very flexibly with anyone in the world.
- When used with a Solid pod, because that is on the web, the data browser provides the public view -- the interactive interface -- that the user has with the rest of the world. Like when everyone had their own home page on the web, they have that power again to express themselves and their affiliation and their products, and to court interaction, such as collaborative work with others, or commerce. The way this public home page appears to others is very customizable, so the user, individual or business can be proud of it.
- The data browser should be modular, dynamically loading new code modules in real time as a function of a user's preferences for handling different types of data with different new data browser applets, be it finance, fitness, or fishing.
- A module providing new functionality in a new domain should be able to appear as a module in the data browser or as a stand-alone app, or both.
- The modularity of the system should allow you set yourself up with any set of apps, or indeed the user should be able to configure the data browser to replace itself with the user's own choice of alternative data browser. All data browsers should allow the user to change this selection.
- The data browser should allow people to create, bit by bit, a web of social linked data of their work and their play, and their lives.