Back in April, when Adriana and I visited the Bay area, we did a lunchtime talk about the Mine! project at Google. Here is the second part; apologies for the delay in posting it, there were more slides to sync audio against, in my half.
Back in April, when Alec and I visited the Bay area, we did a lunch time talk about the Mine! project at Google. Here is the first part:
Hi All,
If you want to know more about The Mine Project and are on the west coast of the USA, you may be interested in the first West-Coast Mine Developer Meeting:
West Coast Mine Developer Meeting
Sunday 19th April
5:30pm for a 6:00pm start
Mountain View CA
Location details are currently secret – numbers and space are limited – but if you want to know more please mail alec.muffett@gmail.com and I’ll get back to you ASAP.
If it proves very popular, we may shift the location, hence not wanting to commit to it in ASCII.
Thanks!
UPDATE: ps: we’re planning on doing dinner somewhere on Castro St shortly afterwards.
Hi All,
There will be a meeting of the Mine Developer community in London, at a secret location, at 7pm on Tuesday the 10th of March.
What I would like to do is show off the current state of the Mine code:
…plus get attendees’ input regarding “gaps” – stuff that needs to be done or written in order to enable a community of developers to come aboard.
If you are interested in attending, please mail alec dot muffett at gmail dot com before sunday; pizza will be on the menu. 
My weekend feed reading yielded Rob Knight’s post on Data Egalitarianism. It looks at impact of customer data might have on certain type or size of vendor. Here is my comment on the post:
This is a rather narrow interpretation of what Mine! will enable for vendors… (or an independent realisation of what customer data sharing means for vendors). In your scenario, the relationship seems completely missing, based on this:
Consider any local, independent shop – a greengrocer, for example. Let us imagine that this greengrocer has access to the VRM data of a reasonable cross-section of the local community; this needn’t be more than a few hundred people. In return for providing (suitably anonymised) data about their shopping habits, these customers receive a small discount when shopping at the store in future.
But relationships cannot exist via anonymised data – the whole point of my approach to VRM is to focus on a ‘relationship’ with the vendor, one that is more equal than the current one. The data I voluntarily provide to vendors is a proxy for my relationships with them. The value is not in the data ‘dump’ but in the data flow, which can be cut off at any point the vendor abuses the relationship.
The challenge we are working on under the Mine! project is finding most effective ways vendors can capture and benefit from customers’ (directly shared) data WITHOUT distorting or abusing the relationship that the data signifies. As a customer, there is no way I will share my data with a vendor if I know that the vendor treats it merely as an input for their database or datamining and not as a basis for a mutually benefitial relationship. And I hasten to add that a more targetted marketing is NOT a benefit to me as a customer. Same applies to ‘discounts’ none of which are on my own terms.
That is why Mine! is designed in a manner that allows me to discontinue data flow to any vendor whenever I feel it unnecessary or irrelevant, thereby redressing the balance of power. Vendors will have to respect my data and by extension the person behind it. At least that’s the idea.
I am certain that vendors will try to use and abuse the data once people are able to share it, so the greater challenge is to create an environment in which individuals realise that they call the shots.
cross-posted from VRM Hub
A bit of context for Mine!:
It comes down to whether you prefer context to be provided by:
1. automated algorithms a la Google and the thousands aggreation sites,
2. trusted sources including vendors, manufacturers, even third parties and intermediaries, or
3. your network of friends aka social networkThe answer is obvious.
It depends! We use all three at different points in our information gathering, sharing and exchange and transactions. The challenge for VRM is to understand advantages and disadvantages of all three and encourage development of tools that give me, the individual user or customers, the best of all three.
My bet is on no.3. I want to help individuals to capture both data and context on their own terms. This will give rise to another layer of knowledge that serves both the individual and his network. For example, I want to collect data about my shopping, with my own comments and with sources of information useful to me. I want to have pictures of products I have bought, links to reviews by others and my own, comments by friends in my network, record of interactions with the vendors and third parties etc etc. I want it in a place I can further analyse it and share it based on my privacy requirements.
With time, all this can become a source of better understanding of my own behaviour and preferences, and, with practice, a better negotiating position in future transactions. In other words, I will be the most authoritative source of my own history, with data, information and knowledge about me.
I like the ReST interface, but I am not fundamentalist about it.
Most of the objects in the Mine implementation are “Things” – ie: a series of key=value pairs which are bundled together under a numeric identifier, which have a Class and associated methods that operate on them.
For reasons of security and sheer implementability, “Things” may not be updated under the ReST CRUD scheme; to recap ReST you are allowed four “CRUD” operations against a URL which represents an object:
So for example:
CREATE (key=value …) /api/object.xmlREAD /api/object/42.xmlREAD /api/object/42.jsonDELETE /api/object/42.xml…but the one that gives problems is UPDATE since the presumption is that you will atomically replace an old Thing with a new thing, much as:
mv new.jpg current.jpg
…might work in a filesystem; you are swapping one bunch of bytes for another one; but Things are complex structures with some bits you can poke, and other bits you cannot. Merely splatting them with replacement data would be painful.
Amongst the other problems with this is that “Update” is usually mapped to the HTTP-PUT method, which is badly implemented in web browsers and actually I think is below the tipping point – ie: it’s so badly implemented that ReSTful people work around it rather than get it fixed. Standard Perl::CGI for instance, does not support it.
The way I have gotten around this is slight but elegant piece of doublethink; I have implemented a ReST interface atop each Thing object, to access its key=value pairs:
READ /api/object/42/key/keyName.xmlREAD /api/object/42/key/keyName.jsonDELETE /api/object/42/key/keyName.xml…and then realising that object 42 now must exist for this trick to work at all, and that there is no point in having CREATE “choose” a key name for you – predefined variable names do not fit the ReST-CREATE model – then the key/CREATE and key/UPDATE operations are otherwise functionally identical (ie: they poke the values of keys) and therefore the latter can be dropped. Also key/CREATE is cooler, since it can poke multiple keys at the same time.
Further, that means key/CREATE is functionally identical to Thing/UPDATE so that can be dropped, too.
So all that is necessary is to mentally “rebrand” the key/CREATE operation as the Thing/UPDATE operation, and a whole pile of UPDATE operations go out of the window.
So now there is only 1 ReST-UPDATE operation that remains in the Mine – down from 11 – and that is the “update of auxilliary data”, for example replacing one JPEG that is associated with object 42, with a different JPEG.
To me this is a straight swap of one blog of data for another one, and so should remain as a ReST-UPDATE; but anywhere else that I have a ReST interface onto complex objects, I shall in future consider very carefully before implementing a UPDATE method.
The code is still pre-alpha – there is a lot of functionality going to be added over the next few days – but last night we got the first cut of the Protomine developer kit going.
So if:
…then join the Developer list and help!
Alec
