The Mine! Project

open source project for online data and relationships logistics

West Coast Mine Developer Meeting, Sunday 19th April, 6pm, Mountain View CA

TAGS: None

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.

Mine Developer Meeting – London, 7pm, Tuesday 10th March

TAGS: None

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:

  • what it currently can and cannot do
  • where you can access a running mine
  • how you can run your own
  • how you can get involved in enhancing it, plus adding tools and applications
  • what the software roadmap is

…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. :-)

Anonymised data a relationship doesn’t make

TAGS: None

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

It’s the context, stupid

TAGS: None

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 network

The 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.

A method for massively cutting UPDATE/HTTP-PUT methods in complex Rest APIs

TAGS: None

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:

  • Create (a new object, in a directory, say)
  • Read (an existing object)
  • Update (an existing object)
  • Delete (an existing object)

So for example:

  • CREATE (key=value …) /api/object.xml
    -> new object populated with keys/values, id = 42
  • READ /api/object/42.xml
    -> a bunch of key=value pairs in XML
  • READ /api/object/42.json
    -> a bunch of key=value pairs in JSON
  • DELETE /api/object/42.xml
    -> deletes object 42, status returned in 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.xml
    -> value associated with keyName for object 42, in XML
  • READ /api/object/42/key/keyName.json
    -> value associated with keyName for object 42, in JSON
  • DELETE /api/object/42/key/keyName.xml
    -> unset keyName in object 42, status in 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.

Mine! feeds for Santa

TAGS: None

Why I believe in The Mine! Project

TAGS: None

Protomine Development Kit released!

TAGS: None

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:

  • you are interested in The Mine! Project
  • you have OSX (current development platform, Ubuntu and Solaris next)
  • you know what Subversion, perl, and /usr/bin/make do

…then join the Developer list and help!

Alec

Protomine Development Feed Information

TAGS: None

Hey All,

Protomine development is back on track!

To keep abreast of the latest news, and so that we don’t spam the blog with ‘putback’ messages, check out the Atom feeds on the project information page at GoogleCode.

What Mine! is not

Tags: , ,

The key to getting people understand Mine! is its relevance to them. Though sometimes it helps to say what Mine! is not.

  • Mine! is NOT a Blog or Blogging Tool
  • Mine! is NOT a Personal Data Store
  • Mine! is NOT a Social Networking Tool
  • Mine! is NOT a Photo Gallery etc

Blog is a publishing platform, one-to-many and although Mine! uses blog-based technologies, it is information management platform, for user’s own benefit and with controlled sharing.

Mine! stores more than mere “personal data”, it stores anything. It can contain and manage static and dynamic data, related to the person by the virtue of being in Mine!. On top of that, Mine! enables tagging, analysing, poking, prodding, collating and mashing up data not just “storage”. And it enables sharing via feeds that can be individual generated and targeted.

Mine! is not a social network a la Facebook, MySpace etc etc. It is meant for individual deployment and use. In some sense it is “antisocial’ software – no walls to write on, zombies to poke, vampires to throw. It is designed to bring control to information sharing.

That said, Mine! can provide valuable functionality for e.g. OpenSocial, federated micro-blogging, friends-lists, contacts, FoaF etc. All in addition to what Mine is designed for and enabled because the user has new capability.

Mine! is not a photo gallery, nor is Mine just a wine-lover’s tool or traveller’s companion,
but these examples will be used often when explaining what Mine! can do for users.

Finally, what does the Mine! give you:

  • a home for storing your data
  • a platform for poking your data
  • a means to share your data
  • in, for, and to establish relationships with others, so you are the definitive source of information about you and have absolute control & revocation of access

From my previous writings about Mine!

Store implies passive and static, with some distribution via feeds, whereas one of the major elements of the Mine! is equipping individuals with analytical and other tools to help them understand themselves better and give them an online spring board to relationships with others (in VRM context this includes vendors).

The personal data store implies that there is no other reason to be using it other than to slave yourself to someone’s CRM system [...] it treats people’s Mines! like a back-end to vendors’ CRM systems. It does not capture using the Mine! to manage relationships [...] the customer being in control of their own data.

… The purpose of the Mine! is not only to put the individual in the centre and align the vendors around him. That is a far more gargantuan effort than what the Mine! is designed to do as the vendors have very little motivation to do that in ways that are useful to the individual. The idea behind the Mine! is to give the individual ability to become the authoritative source of information about him by handling the living breathing data as they go about their life. Taking just the feeds and not groking the autonomous space for my data is like looking at a vast landscape through a key hole, not bothering to open the door.

So once more, with feeling – the feeds and the Mine! feed technology are a subset of the Mine!, which has been conceived as an alternative way to provide data logistics for the individual on the web, one with a higher degree of autonomy and control over one’s preferences that is possible now. It originates from the social web, not from the identity space or any other area. It is a platform for the individual, with the aim to shift the balance of power between individual and platoform (or customers and vendors or other types of locked see-saw). It aspires to be an infrastructure for other solutions but it is not and should not be defined in terms of any of those solutions – identity, VRM, authentication, data portability and hopefully many more.

© 2009 The Mine! Project. All Rights Reserved.

This blog is powered by Wordpress and Magatheme by Bryan Helmig.