Glenn Greenwald presenting on Wikileaks and “deep” power structures at the Lannan Foundation, March 2011
The best journalist alive today IMO, speaking on Wikileaks at the Lannan Foundation on March 2011:
A fascinating series of video clips on the birth of the modern propaganda industry (rebranded as Public Relations) in the early 1920s – beginning with Sigmund Freud’s nephew Edward Bernays and the use of PR in America. Below is Part 1 of 4.
How’s this for an amazing quote from the above clip:
What the corporations realized they had to do was transform the way the majority of Americans thought about products. One leading banker, Paul Mazer of Lehman Brothers, was clear about what was necessary. “We must shift America,” he wrote, “from a needs to a desires culture. People must be trained to desire, to want new things even before the old have been entirely consumed. We must shape a new mentality in America. Man’s desires must overshadow his needs.”
Wow. Holy shit! So that’s where the whole fucked-up consumption mentality comes from in American society. For more on Bernays and the use of propaganda in media and society, please see:
Propaganda – Edward Bernays, 1928 (reprint 2004)
Manufacturing Consent – Edward S. Herman and Noam Chomsky, 2002
Taking the Risk Out of Democracy – Alex Carey, 1996
GNN Profile: John Stauber – John Stauber GNN, 2002
And for a truly scary video in the topic of propaganda as mind control, please see:
The Most Dangerous Game – GNN, 2003
Participatory Design and Co-Creation are powerful trends in Design. Here’s a video of Liz Sanders speaking on these topics from the IIT Design Research Conference in 2008:
For related material from Sanders, please see the article Co-creation and the new landscapes of design.
A very nice overview and contrasting of the four main NoSQL database categories: (i) Key-value stores, (ii) BigTable clones, (iii) Document databases, and (iv) Graph databases. One particular insight I picked up from the presentation is the pervasiveness of key-value data representations across all four categories. Quoting Eifrem:
[Document databases – e.g. CouchDB and MongoDB] are inspired by Lotus Notes. CouchDB was founded by the guy that wrote Lotus Notes at IBM, and it basically has a data model of a collection of key-value pairs that they call documents – a JSON document – and then a collection of those, sometimes hierarchically organized. …
The fourth category are Graph databases … The data model here is nodes, with relationships between nodes. And then key-value pairs that you can attached to both nodes and relationships.
The prominence of the Key-Value structure relates to two fundamental advantages to NoSQL datastores: (i) their ability to manage flexible schemas and complex data structures, and (ii) their ability to scale. Eifrem makes the case that different families of NoSQL databases make different design decisions that involve tradeoffs between ease of scaling vs. ease of representing complex data. This is illustrated by the slide below:
Again quoting Eifrem from the presentation:
If you look at [these 4 families of NoSQL databases] they’re all about scaling. But there are two aspects to scaling: data complexity … and scaling to size. If you map these models you see they’re positioned differently along [the two axes].
We have Key Value stores [at the top left] – an extremly simple data model, which means it’s poor at handling complex data. It’s just a hash table right. But the fact that it has such a simple data model means that it’s really easy to scale out …
The Big Table clones have a less simple, more capable data model that can capture [semi-structured data]. But have slightly less ability to scale to size. … It’s more difficult to get HBase to scale to get Voldermort to scale to insane size.
More over to the right we have the document databases. A more capable data model, but you can’t push to scale to the size [of the previous models.]
And finally all the way out to the right are the Graph databases. It’s the data model which is most capable of dealing with complexity. It’s easiest to model complex domains. But it’s most challenging to get it to scale to size.
The interesting thing about these data models is that they’re all isomorphic. If you have data, you can squeeze it into a graph database or into a key value store, or into [the other two models].
For example, we sometimes jokingly say about document databases that if you want a document database, just take a graph database but remove the relationships. The nodes are key-value pairs just like the documents. So from a data model perpsective, a graph database is clearly a superset of a document database.
And one document is sort of like the entire key value store in the key value store model. Now this is a pretty theoretic exercise … so when it comes down to specifics, obviously there are a bunch of things that [differentiate] a document database from a graph database, in terms of the REST API, in terms of how we handle indexes, and other things like that.
To understand more about the fundamentals of the Neo4j database, please see The Neo Database: a Technology Introduction.