feat: ✨ Expand discussions on blockchain, coordination, and open data

+3

Blockchain.md

··· 16 16 - [Blockchains could replace networks with markets](https://twitter.com/naval/status/877467629308395521). 17 17 - One of the main downsides of blockchains is that most humans are not good at protecting their passwords, credentials or private keys. 18 18 - Blockchains can be used to ensure the best output in prisoner dilemma style interactions. Write a smart contract that does X when everyone has added the money and no one will be able to betray. 19 + - Blockchains solve distribution problems but they don't solve the problem of who will add the money to the ecosystem. That's a political one. Unless there are good incentives to move to blockchains. 20 + - Once a system moves to a blockchain, it'll get its properties (e.g: transparency and verifiability). 21 + - Open source has the failure mode of not enough incentives, cryptocurrency has the failure mode of excessive and overly concentrated incentives.

+4

Coordination.md

··· 33 33 - Cheap, accessible means of conflict resolution. 34 34 - Self-determination. 35 35 - There are many [coordination mechanisms](https://coordinationmechanisms.gitcoin.co/). Choose the appropriate one for your situation. 36 + - [There is no such thing as a structureless group](https://www.jofreeman.com/joreen/tyranny.htm). 37 + - We are individuals, with different talents, predispositions, and backgrounds. 38 + - The idea of "structurelessness" does not prevent the formation of informal structures, it becomes a way of masking power. 39 + - Make the group structure explicit, not implicit. The rules of decision-making must be open and available to everyone, and this can happen only if they are formalized. Having an established process for decision-making ensures that everyone can participate in it to some extent.

+5 -2

Open Data.md

··· 33 33 34 34 These trends are already making it's way towards movements like [DeSci](https://ethereum.org/en/desci/) or smaller projects like [Py-Code Datasets](https://py-code.org/datasets). But, we still need more tooling around data to improve interoperability as much as possible. Lots of companies have figured out how to make the most of their datasets. **We should use similar tooling and approaches companies are using to manage the open datasets that surrounds us**. A sort of [Data Operating system](https://data-operating-system.com/). 35 35 36 - Data wrangling is a perpetual maintenance commitment, taking a lot of ongoing attention and resources. [Better and modern data tooling can reduce these costs](https://github.com/catalyst-cooperative/pudl). 36 + One of the biggest problem in open data today is the fact that organizations treat data portals as graveyards where data goes to die. Keeping these datasets up to date is core concern, alongside using the data for operational purposes and showcasing it to the public. 37 + 38 + Open data is hard to work with because of the overwhelming variety of formats and the engineering cost of integrating them. Data wrangling is a perpetual maintenance commitment, taking a lot of ongoing attention and resources. [Better and modern data tooling can reduce these costs](https://github.com/catalyst-cooperative/pudl). 37 39 38 40 Organizations like [Our World in Data](https://ourworldindata.org/) or [538](https://fivethirtyeight.com/) provide useful analysis but have to deal with _dataset management_, spending most of their time building custom tools around their workflows. That works, but limits the potential of these datasets. Sadly, there is no `data get OWID/daily-covid-cases` or `data query "select * from 538/polls"` that could act as a quick and easy entry-point to explore datasets. 39 41 ··· 85 87 - As [Rufus Pollock puts it](https://datahub.io/docs/dms/notebook#go-modules-and-dependency-management-re-data-package-management-2020-05-16-rufuspollock), Keep it as simple as possible. Store the table location and schema and get me the data on the hard disk (or my browser) fast. 86 88 - [Bootstrap a package registry](https://antonz.org/writing-package-manager/). E.g: a GitHub repository with lots of known `datapackages` that acts as fallback and quick way to get started with the tool (`data list` returns a bunch of known open datasets and integrates with platforms like Huggingface). 87 89 - **Indexing**. Should be easy to list datasets matching a certain pattern or reading from a certain source. 88 - - Datasets are linked to a [[Open Data#Datafile|Datafile]]/`datapackage.yml` with metadata. 90 + - Datasets are linked to their metadata. 89 91 - One repository, one dataset or one catalog/hub. 90 92 - To avoid yet another open dataset portal, build adapters to integrate with other indexes. 91 93 - For example, integrate all [Hugging Face datasets](https://huggingface.co/docs/datasets/index) by making an scheduled job that builds a Frictionless Catalog (bunch of `datapackage.yml`s pointing to their parquet files). ··· 109 111 - Think at the dataset level and not the file level. 110 112 - Tabular data could be partitioned to make it easier for future retrieval. 111 113 - **Immutability**. Never remove historical data. Data should be append only. 114 + - Many public data sources issue restatements or revisions. The protocol should be able to handle this. 112 115 - Similar to how `git` deals with it. You _could_ force the deletion of something in case that's needed, but that's not the default behaivor. 113 116 - **Flexible**. Allow arbitrary backends. Both centralized ([S3](https://twitter.com/quiltdata/status/1569447878212591618), GCS, ...) and decentralized (IPFS, Hypercore, Torrent, ...) layers. 114 117 - As agnostic as possible, supporting many types of data; tables, geospatial, images, ...

Configure Feed

Configure Feed