VRM Hacker Session

VRM Hacker Session in London, November 9th Attendees: Doc Searls, Ben Laurie, Duncan Cragg, Alec Muffett, Alan Patrick, Alan Mitchell, Iain Henderson, Dave Shaw, Adriana Lukas

the minimum requirement - flexible enough to built on top of it

   * structured goop,
   * two way links, and
   * access control

-> that's the infrastructure level

access management

underpinning of vrm is structured goop, two way links, access control

Alec's comments in italics throughout the document:

what is the minimum technical requirement that we can specify to create one or many different VRM tools?

we suspect that we will need:

   an ontology to describe purchases, objects, anything ... (slang: "structured goop",  existing in "blobs" - probably XML)

   a syntax and means to describe bidirectional links between objects (so that B knows it is a child of A, and A knows it is a parent of B)
   access control of some sort

where do you draw line, single ownership objects and then what we will see is a construct made of lots of single ownership objects

there is an open issue of object ownership; whether a data object ("blob of goop") can/should have multiple owners at a given time

what you do – make any progress- ontology

I want wifi on the plane, how do say that – has to be machine readable

does it have to be machine readable from the start?

the ontology challenge could be huge; for instance if you want to describe that a particular airplane journey provided wifi, how are you going to define that in a machine-readable manner? it would seem impractical to expect some committee to create a series of pre-ordained flags to be create which can describe everything the user wishes to describe. can we / should we ignore the issue of machine-readability at the outset, or might it be better to leave the matter of description open, eg: by designing space for a folksonomy of tags, or some other open-ended means of description?

Next question – how do you express what you want? Objects, data

smaller subdivisions – what's in it

structure – tools UI stuff, it has to produce something

make the UI unstructured but the underlying data structured

some data should have meta data – book has ISBN

QR codes – idea

agree piece of structure,

suck this info into my database

support rich data structures – will arrive by consensus, book author, date of publication, ISBN

when it comes to absolute description of objects, or (more concisely) "binding" a blob of goop to a specific object, then the obvious thing to do is leverage ISBN codes, UPC/Barcodes, and other unique identifiers like those which exist in the real world; referencing them either directly, or in some coded format (XRI?) in the blobs of goop.

click on a page of restaurant and see who from my network commented on it – I want a handle on what they are saying, filter - meta data that says stuff about the data, so I can look at it and context

we imagine that VRM tools will be able to draw together the many blobs of goop which reference the same objects, eg: the many reviews (each, a blob) which refer to a specific restaurant; the tools will provide the ability to search and collate, aggregate and present these blobs in an accessible manner.

   * two-way links: protocol for referencing data – http or something – micro web

     highly rigid two ways links to stick, URI vs URL

freenet, mutual pointers between pieces data, common information about things, Doc's fave example travel, hotel - my representation of the hotel links to Adriana's representation of the hotel.

The price we pay for distributed information/data not platforms?

the "blobs of goop" are an atomic data format, they should be able to be exchanged and manipulated without dependency upon other larger data structures; however there will likely still be a need to represent hierarchical relatiopnships between blobs; since the objects are atomic, their parent/child hierarchical relations need to be cited in both objects, ie: bidirecionally; a parent cites its children, and a child knows its parent.

Open APIs don't solve the cross-system links? Duncan's point about presentation at google on 8th November

We are taking data away from the silos but the same issues will be there – distributed access

OpenID – works on multiple sites, profile level,

selective disclosure – trusted entities, two proofs are linked together

   * structured goop: ontology (Dewey decimal system) [is an example of] how we talk about any subject (eg: wine), assuming creation of an agreement, common understanding or framework for the data, less than language, way of dividing and classifying data, so we can communicate – machine readable => we have to agree that how to express data/facts about a thing

cloud of all variables generated by centralised system but by users

in other words there is an easy way to create a "blob of goop" without requiring some committee to create a DTD which describes the comfort of an airline flight; instead the "blob of goop" is just a container that is described by a bunch of tags which evolve under a folksonomy, ie: are neither pre-defined nor bounded. An interesting concept which arose during the meeting was that a blob could - in addition to the tags which describe it - could contain a "payload" of data held in whatever microformat is most convenient and popular to contain the pertinent, object-specific data. "Blobs" would thus become ubiquitous wrappers for exchange of data payloads (in arbitrary formats) whilst tagging them for indexing, retrieval and to cite authorship, etc.

XRI guys will be at the event in california

extra layer of problem, we are going to define this system of categories, we'll do is pass around tokens and someone else will define it for you – meta data

categories for various objects/data

humans can deal with multiple frames of reference – but computers need a more unified frame of reference

too many things to describe

ontology will emerge? [ie: folksonomy]

Personal RFP? Number – looking it up on the website, I want that

here's a verbal description, clunky

looking for video camera on ebay – different spellings, hyphen

As ever, the challenge to finding what you want on google, ebay, etc, is to work out how someone else will have typed the name of the thing you want - TRV900, TRV/900, TRV-900, TRV900E, ... are all the same video camera, but only if you are a human being who can weave your way through the ambiguity of different naming; some means of disambiguating product lookup would be really beneficial to online purchasers...

something very discrete – looking for something specific, not search query

if a vague search query marketers will crowd in and promise to find you something like this and all your friends will recommend!

Start with specifics – car parts that deal with it, centralise info and email you back

[ie: the story about companies which exist and add value by presenting a single point of contact to a bunch of junkyards; the company will forward your request for (some specific auto-part) to a bunch of junkyards, and let you know who can supply it for you; the junkyards benefit because they get specific queries phrased in terms they can understand, the buyers benefit from saving time; this also happens in the secondhand book market ]

Harvard business schools – MBA students who came back to school – remake the car industry from customers side

social web thing – I don't want to enter what I know about hotels, cross-silo standardisation

no federation across silos

point of integration, the patient is the best side

at the dispersal side – multiple providers, any personal information, that needs to be formalised

is it pull or push?

Define VRM as a social network?

Creator of Jabber – Jeremy, approach to search – distributed way

DTD – template, name, location, price, tagged

CRM it's minimisation of information

high speed internet or not in hotels – tags that orbitz can pick up

four airlines got together – competed with travelocity and expedia

every hotel has its own CRM system – communications are very screwy

different things about connectivity

turn obsessives into search – architect a data system

in long run we need is a common practice, community of practice – mini-communities

how we do routinise, the activities of individuals coalescing about specific activities

first order is you contributing to order and find the hotel I want, how that finds its way into a formal system, that's big enough to call market place and how to change CRM systems to give you more granular information

Open social – trying to do the same thing, sneak that stuff into VRM

the architecture – I belong to many things or want to relate, doesn't have to be linkedIn, Facebook or MySpace but it can be Doc's space or Adriana space

Facebook is evil, facebook mark up language – the old silo, lock-in trick

Proof-Of-Concept Thought-Experiment: create a human-readable microformat to describe a (for instance) hotel stay; get lots of people to post their review (using this microformat) to their existing blogs as standalone articles (blobs of goop) ensuring they tag the postings appropriately, including the tag HOTELVRM. Use Technorati/Google to access, aggregate and search all HOTELVRM postings in the entire world, and a custom AJAX application to present the microformat data in a more attractive manner. Object interrelationships would be implemented via "trackbacks" and comments could be added to the original posting. You would never want to /do/ it like this, of course, but the above gedanken demonstrates the some of the desirable traits - sharing, syndication, aggregation, search, tagging folksonomy (SHERATON, HILTON, SMELLYROOM, BADFOOD, GOODSERVICE) etc... You are mostly missing access control.

the moment you control your personal data – how you get the data shared, how to get ben and alec excited, we have to talk about how to stop it from being shared

the best way to predict the future is to prevent it [Doc quoting someone else]

we are not codifying beer or wine or car part, we won't see wars like around RSS

what are we going to talk about – if the market is going to do that, what's the easier way to do that

answer – reuse shit

Micro Web

P2P, microformats, people, reviews, calendars

user at the centre of the whole thing

if you want to leave it to the market?

Bottom up, people know stuff already you are getting them try to describe it

how about using micro-format for a car part website

nuggets of informations, micro-formats?

Don't sit down with OASIS

viable conversation between Alec, Alan P and Duncan – ask about later!!!

encoded blobs – can you stop that working?

blobelicious

Alec: I think there are three major ways to address the matter of "blobs" ontology - what they should look like, and what they contain:

   1) throw the whole thing over to committee, to come up with new DTDs to describe each and every thing VRM might ever want to describe. <object class=teaspoon metal=silver style=baroque,ornate />
   2) create a "container" format which exists mostly to provide structure to tags which are created by the users, pure folksonomy (<tag>spoon teaspoon silver pretty spooooon baroquespoon</tag>)

   3) as for 2) but make space to employ pertinent microformats.

   <blob>

   <email>adriana@bigblog.net</email>

   <comment>i really like this spoon, i am heartbroken to sell it</comment>

   <payload format="uSpoon(Antique)1.0" encoding=raw>

   =spoon,value/1000,baroque/47,metal/silver,tarnish+coefficent=42,TZ/UTC+1=

   </payload>

   </blob>

...my personal bet is that the answer lies between numbers 2 and 3, and that number 1 is impractical. If microformats exist, then reusing them makes sense as the communities of interest will see VRM as a way of querying, swapping and discussing their favourite things.

Doc likes the fact that "long get" is involved in Micro Web – two stage transaction

medical records – form I get as a copy, scan it, card that points to a database

trusted places, surgery, hospital – health authority – custody

disclosure – allow not for profit social enterprises

nobody will trust a profit company

standardised or common way of gather data – this is what you bring to the hospital

product IB – patient needs to be the point of integration for multiple treatments, devices and product

they are siloed in diabetes – take a disease

create the receiving end of VRM organisation – couple of employees tasked with creating with interface

integration – reasonable set of variables facing a patients, list of all things that are JNJ and that are not JNJ

helping the patient formalise to be at the centre

inclusive of doctor-patient relationship

geriatric medicine some VRM mechanism that makes it easier for patient and his doctors to integrate all that records and data

having the patient at the point of integration – from one department to another without any communication – that's happens all the time

triangulation of multiple specialities

they clicked and somebody said, that might be something or other

patients cross fertilise different communities of practice

House series – interesting show because you have doctor who can puzzle things because he is a cross-specialist

can turn every doctor into a House guy

from J&J perspective: 1. look for areas of business where customer data and shared access to it would make a difference to the business itself and its operations, product development, distribution etc 2. look for areas of business where there already is access to data and how it can be enhanced by VRM, what business benefits that would have 3. look for communities related to 1. & 2. 4. familiarise yourself with new approaches and the net dynamics - open source, long tail, attention economy, identity, VRM etc 5.

Doctors might hate the idea – response might be there is too much info to patients, self-diagnoses

you can only help by informing them

Security requirements for VRM include the standard model

   1) authentication: the ability to establish an 'identity' for each user of the system
   2) authoristion: the ability to establish capabilities/privileges which are strongly bound to an each identity, eg: ability to read, write, or delete blobs...
   3) integrity: the ability to protect blobs against modification/forgery/amendments, eg: by use of digital signatures bound to identities
   4) secrecy/privacy: the implementation of access controls of data at rest or in motion, so that blobs cannot be read by those without authorisation

Two architectures for implementation of the security model were suggested:

   a 'fortress' model, where those who desire access to data must successfully authenticate themselves to the data repository before retrieval.
   a 'broadcast' model, where data is broadcast, unicast or published but under encryption, where only those with authorisation possess keys for access

distributed just coz it's sexy? It's a necessary because it's more resilient

Alec: basically the discussion was about: should we consider making a VRM pilot and simplify our lives by making the assumption that the database would be wholly centralised; the answer to that was an emphatic NO; the reason being that working from a perspective of "the data is centralised in a fortress" will lead to thinking that will never be able to accommodate a distributed architecture; whereas there is nothing to prevent an architecture which is capable of distribution in a wholly or partly centralised matter, as a convenience. In short: the web-browser would never have been invented had someone elected to ignore the distributed nature of the Web; instead, they would have merely yet again reinvented the file-browser. So: DESIGN IT DISTRIBUTED, TEST IT DISTRIBUTED, BUT IMPLEMENT IT HOWEVER YOU CHOOSE.

personal data stores – data objects

design it around one big machine everyone will talk to – you are predetermining design

if you design breakable because then it doesn't matter because there are enough distributed machines, VRM lifestyle – approach – embracing distributed model will save a lot of pain in the long run

client- server? Duncan's reminder

P2P solution?

Virgin not trusted because private company, social enterprises trusted more

regulated

trusted storage – telcos, banks, private, public?

QUANGO

where do you stick the data?

credit boom started – CRM was started by financial industry handling a number of customers due to increased demand

flacking – helping to sell something via third party – use and abuse of trust

who would you trust as a company to held your keys?

the whole trusted third party debate – clipper 1994 or 1996?