Using the DCoSL protocol, Alice's web of trust and Bob's web of trust, though they are not identical, will very often have significant overlap. For any given list, although there is no guarantee, there is a good chance that Alice and Bob will end up delegating list curation to the same (or a similar) group of individuals and therefore will end up populating the list with the exact same (or at least almost the same) set of items. This is especially true if the contents of a list are not particularly polarizing or controversial (and many of them aren't). This is a vitally important attribute, known as loose consensus. Much of the power of DCoSL comes from its ability to generate loose consensus. You may want to think deeply about loose consensus before incorporating decentralized list curation to your app.
In some cases, a particularly controversial or politicized list may generate loose consensus that segregates by community, meaning that one community generates consensus around one set of items, while another community generates consensus around a distinct set of items for the same list.
The term crowdsource will be used to refer to curation of one or of a collection of simple lists using DCoSL protocol where a high degree of loose consensus is expected, at least within a given community. Schemas, verifiable credentials, etc can be said to be 'crowdsourced' via the DCoSL protocol, in each case through curation of a (often small) handful of simple lists.