Jim, serves you right for doing some thinking on this and letting us know…

Re the Mine! and VRM – the Mine! is intended as an infrastructural point of integration for user’s data, relationships and sharing. The method of sharing data from the Mine! is the way in which I try to redress the balance of power in relationships with vendors – I can create as granular a feed as I wish for each recipient including vendors, I can audit the feed and terminate it whenever I wish without disturbing other feeds/relationships.

In fact the first paper, implicitly anticipating the Mine!, talks mainly about the mechanism of such ‘data logistics’.

They can both be found here:
http://themineproject.org/index.php/the-mine-papers/

Actually I think I am already there, but I misapprehended what you were trying to say.

- Mine objects are tagged to allow the user to categorise objects

- Mine relationships are reciprocally tagged to determine which objects appear in the feeds for what relationship.

So far, so familiar…

However, “under the hood” the objects have exactly what you say, a rich set of “key: value” pairs which can be used and extended by plugins, with a bunch of them pre-booked for database administration purposes; but this is all hidden from the user, hence it doesn’t appear in the user documentation:

objectComment: this is a comment about mountains.jpg
objectName: upload from mountains.jpg
objectStatus: draft
objectType: image/jpeg

And yes, there is a concept of “an enumerated type”, eg: objectStatus can only be one of draft/final/public

Once we cut a working beta, I’ll be bugging you to write a plugin for us.

I’m not sure how flinging in inference rules might not complicate matters, but it can be implemented as a plugin layer on top of the basic database, so it doesn’t matter that much, I suppose. People can change it if they don’t like it.

Hm.. in fact, provided you have a very simple base metadata system consisting of key/value pairs and, maybe, a publicly available and extensible list of keys and their meanings (kept on a Wiki or something), then everyone else can write plugins that add more meaning to that.

I still feel like I’m missing some elements of your overall vision though, and I have a suspicion I might be missing the whole thing; but I suppose

“a system which allows ordinary users to own, catalogue, mashup and manage their own data (of any type provided plugins exist) and also the data of other people who provide them with (possibly audited) feeds of their data”

is one way of looking at it. It does unfortunately omit the VRM aspects, though; particularily the idea of providing your personal data as a feed to the companies with whom you have a relationship rather than them getting to keep and manage it. But maybe that’s good from an architectural point of view; the VRM aspects just fall out of the architecture of the Mine! naturally.

Hope I’m not treading on anyone’s toes by playing around with these ideas; they’ve been sitting in my head taking up space and partying since we saw you both in Swansea.

…and then if there is a relationship rule saying Jim is interested in “wine” then you’ll get a feed of winebottle.jpg; unless, of course, your rule says “wine not:merlot” in which case you’ll get the picture of chardonnay.jpg instead…

But limitations? No, there are none. Publication is via ATOM feed. What goes on in the Mine! itself is a matter of user interface and good design…

As a coder, I’m trying to think how you could achieve this – perhaps each datum needs to be input with a raw minimum of the most general metadata we can possibly think of: dates of creation and modification, title, description, some ‘tags’.

But surely there’s more to controlling your data that just labelling it with tags? For example, can we allow the user to create their own metadata fields? Simply by either defining (key,value) pairs for their objects on an ad hoc basis, the same way you add tags only with a value; or providing a UI interface for managing their own keys, to which they would be prompted to add values for the item types they specify (”You’re adding a photo, I’ll prompt you for the ‘PlaceTaken’ or ‘Person’ fields that you created”).

Not sure if I’m making sense here, I’m stumbling around in the dark a bit, but you’ve got to start somewhere.